Date: Tue, 22 Mar 2016 22:32:21 -0400 From: Rich Felker <dalias@...c.org> To: Christopher Lane <lanechr@...il.com> Cc: musl@...ts.openwall.com Subject: Re: musl licensing 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. > 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? 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.) > 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? Rich
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.