[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKFiscfc3AYZ2_i0LvJmnv1pJmAFzt0y5zN2ruNFU=nPBpKupg@mail.gmail.com>
Date: Tue, 29 Mar 2016 10:21:25 -0700
From: Christopher Lane <lanechr@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: musl licensing
On Wed, Mar 23, 2016 at 1:35 PM, Christopher Lane <lanechr@...il.com> wrote:
> 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?
>
>
Short answer: not really, no.
Long answer: every time I mention this to them, I get the same answer. If
the license file includes any ambiguity by including things like
speculation on the copyrightability of the work, it's safer for us to just
avoid it. The potential penalties for copyright infringement are
astronomical.
I understand (and agree) that the COPYRIGHT file is the most natural place
to put comments on whether content should be copyrighted, but these are not
merely inert comments. Like code, a license file needs to be correct
before it can be convenient. Introducing text like "It is our belief and
intent that these files ... would not be subject to copyright" is
equivalent to introducing undefined behavior because we just don't know how
a court might interpret it. You wouldn't be satisfied with that ambiguity
in your code; I'm asking you to treat your license the same way.
Listen, if we're asking you for too much, I get it. This is not our
project. We didn't pour years into it, you did, and you have to do what
you think is right. If it's beyond your personal ethics to claim copyright
over the trivial files and public headers you wrote, then that's the way it
is. I'll be sad, but we'll deal with it.
Or, if you want, I can set up a chat with one of our lawyers for you. I've
been so far unable to convince them to bend on this, but maybe you'll have
better luck. You're certainly welcome to try, anyway.
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.
