Re: musl licensing

[Christopher Lane <lanechr@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5177 bytes --]

On Tue, Mar 22, 2016 at 7:32 PM, Rich Felker <dalias@libc.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@libc.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

[-- Attachment #2: Type: text/html, Size: 7147 bytes --]