Date: Wed, 23 Mar 2016 13:35:23 -0700 From: Christopher Lane <lanechr@...il.com> To: Rich Felker <dalias@...c.org> Cc: musl@...ts.openwall.com Subject: Re: musl licensing On Tue, Mar 22, 2016 at 7:32 PM, Rich Felker <dalias@...c.org> wrote: > On Mon, Mar 21, 2016 at 03:46:18PM -0700, Christopher Lane wrote: > > On Fri, Mar 18, 2016 at 9:35 PM, Rich Felker <dalias@...c.org> wrote: > > > > > On Fri, Mar 18, 2016 at 07:47:21PM +0000, George Kulakowski wrote: > > > > I wanted to mention another small thing, which is simply to update > the > > > > names of some files specifically mentioned in COPYRIGHT. I've > attached a > > > > diff. > > > > > > Thanks. Applied. > > > > > > Rich > > > > > > > Some comments on the proposed COPYRIGHT text... > > > > """ > > The implementation of blowfish crypt (src/misc/crypt_blowfish.c) was > > originally written by Solar Designer and placed into the public > > domain. The code also comes with a fallback permissive license for use > > in jurisdictions that may not recognize the public domain. > > """ > > > > """ > > The x86_64 port was written by Nicholas J. Kain. Several files (crt) > > were released into the public domain; others are licensed under the > > standard MIT license terms at the top of this file. See individual > > files for their copyright status. > > """ > > > > Those paragraphs still reference public domain. We can't use the things > > mentioned there. WRT the blowfish impl, there are other implementations > we > > can pull if we want / need that - though I'm not sure we even do want > > that. > > Did they miss the part about the fallback permissive license? I'm > pretty sure Solar's implementation of bcrypt (albeit the original, not > the one he modified for musl) is used in plenty of other places with > no problem. Complaining about copyright status on this is like > complaining about fdlibm. If it's really a problem I suspect he would > be willing to clarify its status for you. > I forwarded the comments without delving into this like I should have. I doubt our lawyers _like_ the copyright status of Solar's implementation of bcrypt, but it's not a problem to be solved here. And like you said, it's used in many other places already -- so many, in fact, the status is probably impossible to clear up at this point. It's also a single file, so let's not dwell on this any further. Aside: the path has apparently changed at some point from src/misc to src/crypt. > > > The x86_64 crt files can be cleanroom'ed here (and we'd release > > those BSD0 when we're done). > > I don't understand why they're making a meal of this again. This is > covered under the code I already said I would contact the contributors > for clarification on, which I'm happy to do once I get feedback that > the changes will meet your needs. Is the problem just that I forgot to > remove this text and replace it with a statement that the port was > contributed by Nicholas J. Kain under the project's license terms? Ah, I see the misunderstanding. It was just an oversight. OK, no worries. > I > can certainly do that assuming I get the clarification we discussed. > > In any case the only original crt files left from this contribution > are crti/crtn which are literally _single instruction_ functions. The > idea that they could be subject to copyright (even if some of the > other things we claimed were PD were more iffy) is utterly absurd. > (All crt1.s were removed a while back and replaced by the unified C > version; the new crt_arch.h files they used are mostly original works > by me.) > Now that you've mentioned this, I'm actually looking through git blame trying to find a file that might fall under this paragraph and I can't. crt/x86_64/* appears to be wholly contributed by you. arch/x86_64/crt_arch.h, like you said, was as well. At this point, I don't know what files the phrase "Several files (crt) were released into the public domain;" would even refer to. Though I suppose it doesn't matter since you're replacing the claim anyway. > > > The new text is almost OK. The biggest problem is, you shouldn't comment > > or speculate on the copyrightability of work inside the license file. > > Doing so could unintentionally alter or restrict the scope of the license > > you're attempting to apply. Comments should go in the readme file or > > another separate file. In the words of one of the lawyers here, "the > > license file should say X is MIT, Y is BSD, Z is BSD-2, goodbye." > > This really seems like the most natural place for this content so that > interested readers have access to it. I'm really trying to work with > you guys here, and it's frustrating when your lawyers come back with > complaints about statements of opinion/belief that are clearly > disjoint from license terms and that explicity state that they are not > to be interpreted as affecting the license. Other well-known licenses > (especially the GPL and LGPL) contain statements of belief and similar > that are not legally binding, even statements of legal theories like > "You are not required to accept this License..." > > If this is still bothering them, would it make them happy to put some > "end of legal text" marking above that paragraph? > I sent them a query this morning; still waiting on a reply. I think this is the only issue left. > > Rich Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.