From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9669 Path: news.gmane.org!not-for-mail From: Christopher Lane Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl licensing Date: Thu, 17 Mar 2016 16:32:03 -0700 Message-ID: References: <20160315221757.GA3522@openwall.com> <56E98AB1.9030309@openwall.com> <20160316234656.GQ9349@brightrain.aerifal.cx> <20160317081748.GF13856@example.net> <20160317160131.GE21636@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11337236b202d5052e4709a7 X-Trace: ger.gmane.org 1458257551 6413 80.91.229.3 (17 Mar 2016 23:32:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Mar 2016 23:32:31 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-9682-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 18 00:32:22 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aghOs-0005O9-Lw for gllmg-musl@m.gmane.org; Fri, 18 Mar 2016 00:32:19 +0100 Original-Received: (qmail 32513 invoked by uid 550); 17 Mar 2016 23:32:16 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 32486 invoked from network); 17 Mar 2016 23:32:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=28dV7HiV3cM/41D0AYLnNMAvcc7yji5FJU0J2MbfQ9A=; b=U1gag2bmiOlhDC5g0hifMGOsYXKT47N3+5ePbYBNC6RkOmQ7e4DDFJwRQ0JUFznlyO 5ZruNA73hYGouvlPD2TqjMXxp16kiPXzUE0b+xsl88JtReWFWVbinT/SReW+Ykcl2frC 5c/8EetTpk1J1ii7xzwRK1/7DmhJ2rfrKb6TafYyNqXVO+ak3VLoE5PDV7C8XnjCuwYN TLjqY9eaPLLF65QoLF2UoVNEDaE1e7G8Uehnjt6U+4mK20miDGd/xQXjzCVzXTc5FVSd EvdPRTlRPqGTNHcNb71y4YeWxusfK/hTsxh1BkiEaBOBLDBedOlH4oujRYQqDqvA7qVH 0cHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=28dV7HiV3cM/41D0AYLnNMAvcc7yji5FJU0J2MbfQ9A=; b=Xdd98NW2S32PYD2cgW99tD/gyD2JJAaoXo2hMVj9vu5qxIyI0M6nUYRQR7e4SLARfp YeWAXRbd8ff1jB+2gjnon14Luph1wXz0VAenGyRmAxvcdn8LcWAoLj909AxFvEsF+Rdm lHYVdgHb0ovwWNLS3+Ztebzvk/TzKHZUFosf8hDscCPkRCBKTFivF5xuoWEiPXuO5yt+ GnKU+w6jr1kBb6fFfiBdrgg0EBYdo5JX1liJCvS+M0HY0tgvsWxz/N40Sby6iAen3gri 6BSKRM1k1qOAwyLrRT1I1IzlaT37XsINf0eBNx0Cn164AQ+kzg95lfwFdXRCJ/jmooa4 +Hrg== X-Gm-Message-State: AD7BkJIguMUYBpJV+ZW/RTu/qDgoQzOfm66MeFSP4GTEfE1kcehaCZ1CbgBw/Zp8bWjIL3PbaRD7gjETlk4mmw== X-Received: by 10.50.150.36 with SMTP id uf4mr38216782igb.1.1458257523768; Thu, 17 Mar 2016 16:32:03 -0700 (PDT) In-Reply-To: <20160317160131.GE21636@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:9669 Archived-At: --001a11337236b202d5052e4709a7 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 17, 2016 at 9:01 AM, Rich Felker wrote: > On Thu, Mar 17, 2016 at 08:14:04AM -0700, Christopher Lane wrote: > > On Mar 17, 2016 1:18 AM, wrote: > > > > > > On Wed, Mar 16, 2016 at 07:06:25PM -0700, Christopher Lane wrote: > > > > ... if releasing under e.g. BSD0 is OK when PD isn't > > > > valid, why isn't it OK for all situations. > > > > > > I expect that it is illegal in certain jurisdictions to claim > > > copyright on a public domain matter. > > > > > > This is not a problem for the musl user (Google) but potentially > endangers > > > the developer who wrote the questionable copyright statement. > > > > > > This may explain why Google explicitly mentions "non-copyrightable" in > a > > case > > > when it represents the developer party: > > > > > > On Wed, Mar 16, 2016 at 11:31:25AM +0100, Szabolcs Nagy wrote: > > > > bionic actually generates its kernel interface headers from (gpl) > code > > > > and each file has the comment: > > > > > > > > *** This header was automatically generated from a Linux kernel > > header > > > > *** of the same name, to make information necessary for userspace > to > > > > *** call into the kernel available to libc. It contains only > > constants, > > > > *** structures, and macros generated from the original header, and > > thus, > > > > *** contains no copyrightable information. > > > > > > So this is actually all about which party shall take the risks, > > > musl or Google. Isn't it? > > > > This isn't about shoveling risk from Google to musl. We want musl to be > a > > clear and unambiguously licensable product so we can use it. > Incidentally, > > figuring out the licensing stuff here is a large distraction for our team > > (and we knew it would be), but we're willing to put in the time and > effort > > because we think it's beneficial for the open source community overall, > and > > because it's ethically correct. This isn't just CYA, and it's not some > > nefarious scheme. > > > > WRT bionic, I don't know what they're doing and I don't have any insight > > into what went into that decision. I only know what our team has been > told > > about using musl. > > > > If it comes down to it, it might be possible for us to avoid using any of > > the public domain parts of musl - maybe in a fashion similar to what > bionic > > did, I don't know yet. If that's good enough for our lawyers, it'll get > > our team unblocked and that's good enough I guess. Though, I'd prefer we > > solve this without such a workaround so others can benefit. > > I understand that's a possibility, but I'd like to work with you to > make sure that's not one you have to take, since using these parts is > actually one of the best aspects of using musl. > > Rich > I've returned from the land of lawyers with answers. Please pardon the length of this email. 1. Why doesn't the MIT license apply in the case where PD one doesn't? Essentially, because the relevant decision point is at time of contribution. When work is contributed to an open source project, it's taken as wide spread convention that the work is being contributed under the license the open source project itself is released under. As an aside, this has apparently never been litigated and therefore is not necessarily true, but it's taken as fact in the vast majority of the open source community. Google won't accept contributions to its open source projects under a mere convention, so it requires CLA (that isn't directly applicable here, I just thought it was an interesting fact.) Anyway, applying the open source convention above to the case of musl, if work is contributed to the include/*, arch/*/bits/* or crt/* directories, that work is assumed to be contributed as public domain. In the event that public domain doesn't hold, that work is not then retroactively assumed to have been contributed under MIT. Instead, that work is considered to have been contributed without a license. We could argue over whether this would _actually_ happen, but it doesn't matter -- that chain of events is plausible enough for it to be a problem. 2. Is it sufficient to add the language you wrote earlier? ("Should the release of these files into the Public Domain be judged legally invalid or ineffective ... [Redistribution and use] with or without modification, are permitted.") No. Why? Well, because here's what would happen. Let's say this claim is tested - the phrase "judged legally invalid or ineffective" comes under attack. Judged by whom? What is legally invalid exactly? This is ambiguous enough that it can still result in a lawsuit. Also, just adding the language doesn't address the first point - that the (presumed) relevant text of the COPYRIGHT file is the text when the files were contributed. 3. Is adding a musl CLA a requirement, a suggestion, or what? If you assume the validity of the whole "open source licensing convention" I mentioned earlier, it's not required for future contributions. I mean, obviously right, because there are plenty of open source projects without them. But if you do end up removing the public domain claim from the COPYRIGHT file (which we seriously recommend) you should at least collect agreements from folks who contributed work that might be affected (to make sure they agree to contributing that work under e.g. BSD-0). I believe musl went through a relicense of the whole project at some point, so I'm sure you're familiar with this concept already. We're definitely not suggesting a relicense of the whole project -- we're suggesting explicitly licensing the stuff that is today claimed to be PD. [end of q/a] OK, so where does that leave us? One invariant exists: as a team that works for Google, we can't use anything that was contributed to musl as PD. Others probably shouldn't, but we strictly *can't*. We can approach this from different angles: Practically: By claiming that things are public domain, you're having the inverse effect of what you want -- fewer people can actually use the work. Just because you claim something is PD doesn't make it so - it sucks, but that's the current legal situation. If you really want something to be as widely usable as possible, not only now but years from now, license it BSD-0. Ideologically: Sure, things like numbers or APIs aren't (or shouldn't be) copyrightable, but that's not all there is here. The musl headers don't look exactly like any other libc's headers. Work has gone into them over the years. They're ordered differently. Variable names are different. Look at include/alltypes.h.in or math.h for more differences. You may consider this work to be trivial, but it IS original. We can't (and shouldn't) use it without a license. Our suggestion: please get permission from the relevant people to release their work as BSD-0, remove the public domain text from COPYRIGHT, license the headers and crt, etc. files as BSD-0. In a separate file, register your opinions and intent that the public headers, etc. should be freely usable and unowned by anyone but the current state of affairs WRT software and copyright is complete shit (which it so totally is). --001a11337236b202d5052e4709a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 17, 2016 at 9:01 AM, Rich Felker <dalias@libc.org> wro= te:
On Thu, Mar 17, 2= 016 at 08:14:04AM -0700, Christopher Lane wrote:
> On Mar 17, 2016 1:18 AM, <u-uy74= @aetey.se> wrote:
> >
> > On Wed, Mar 16, 2016 at 07:06:25PM -0700, Christopher Lane wrote:=
> > > ... if releasing under e.g. BSD0 is OK when PD isn't
> > > valid, why isn't it OK for all situations.
> >
> > I expect that it is illegal in certain jurisdictions to claim
> > copyright on a public domain matter.
> >
> > This is not a problem for the musl user (Google) but potentially = endangers
> > the developer who wrote the questionable copyright statement.
> >
> > This may explain why Google explicitly mentions "non-copyrig= htable" in a
> case
> > when it represents the developer party:
> >
> > On Wed, Mar 16, 2016 at 11:31:25AM +0100, Szabolcs Nagy wrote: > > > bionic actually generates its kernel interface headers from = (gpl) code
> > > and each file has the comment:
> > >
> > >=C2=A0 ***=C2=A0 =C2=A0This header was automatically generate= d from a Linux kernel
> header
> > >=C2=A0 ***=C2=A0 =C2=A0of the same name, to make information = necessary for userspace to
> > >=C2=A0 ***=C2=A0 =C2=A0call into the kernel available to libc= .=C2=A0 It contains only
> constants,
> > >=C2=A0 ***=C2=A0 =C2=A0structures, and macros generated from = the original header, and
> thus,
> > >=C2=A0 ***=C2=A0 =C2=A0contains no copyrightable information.=
> >
> > So this is actually all about which party shall take the risks, > > musl or Google. Isn't it?
>
> This isn't about shoveling risk from Google to musl.=C2=A0 We want= musl to be a
> clear and unambiguously licensable product so we can use it.=C2=A0 Inc= identally,
> figuring out the licensing stuff here is a large distraction for our t= eam
> (and we knew it would be), but we're willing to put in the time an= d effort
> because we think it's beneficial for the open source community ove= rall, and
> because it's ethically correct. This isn't just CYA, and it= 9;s not some
> nefarious scheme.
>
> WRT bionic, I don't know what they're doing and I don't ha= ve any insight
> into what went into that decision.=C2=A0 I only know what our team has= been told
> about using musl.
>
> If it comes down to it, it might be possible for us to avoid using any= of
> the public domain parts of musl - maybe in a fashion similar to what b= ionic
> did, I don't know yet.=C2=A0 If that's good enough for our law= yers, it'll get
> our team unblocked and that's good enough I guess.=C2=A0 Though, I= 'd prefer we
> solve this without such a workaround so others can benefit.

I understand that's a possibility, but I'd like to work= with you to
make sure that's not one you have to take, since using these parts is actually one of the best aspects of using musl.

Rich

I've returned from the land of law= yers with answers.=C2=A0 Please pardon the length of this email.

1. Why doesn'= ;t the MIT license apply in the case where PD one doesn't?

Essentially, becau= se the relevant decision point is at time of contribution.=C2=A0 When work = is contributed to an open source project, it's taken as wide spread con= vention that the work is being contributed under the license the open sourc= e project itself is released under.

As an aside, this has apparently never been l= itigated and therefore is not necessarily true, but it's taken as fact = in the vast majority of the open source community.=C2=A0 Google won't a= ccept contributions to its open source projects under a mere convention, so= it requires CLA (that isn't directly applicable here, I just thought i= t was an interesting fact.)

Anyway, applying the open source convention above to = the case of musl, if work is contributed to the include/*, arch/*/bits/* or= crt/* directories, that work is assumed to be contributed as public domain= .=C2=A0 In the event that public domain doesn't hold, that work is not = then retroactively assumed to have been contributed under MIT.=C2=A0 Instea= d, that work is considered to have been contributed without a license.=C2= =A0 We could argue over whether this would _actually_ happen, but it doesn&= #39;t matter -- that chain of events is plausible enough for it to be a pro= blem.

= 2. Is it sufficient to add the language you wrote earlier? ("Should th= e release of these files into the Public Domain be judged legally invalid o= r ineffective ... [Redistribution and use] with or without modification, ar= e permitted.")

No.=C2=A0 Why?=C2=A0 Well, because here's what would happ= en.=C2=A0 Let's say this claim is tested - the phrase "judged lega= lly invalid or ineffective" comes under attack.=C2=A0 Judged by whom?= =C2=A0 What is legally invalid exactly?=C2=A0 This is ambiguous enough that= it can still result in a lawsuit.

Also, just adding the language doesn't add= ress the first point - that the (presumed) relevant text of the COPYRIGHT f= ile is the text when the files were contributed.

3. Is adding a musl CLA a requir= ement, a suggestion, or what?

If you assume the validity of the whole "open = source licensing convention" I mentioned earlier, it's not require= d for future contributions.=C2=A0 I mean, obviously right, because there ar= e plenty of open source projects without them.

But if you do end up removing the = public domain claim from the COPYRIGHT file (which we seriously recommend) = you should at least collect agreements from folks who contributed work that= might be affected (to make sure they agree to contributing that work under= e.g. BSD-0).=C2=A0 I believe musl went through a relicense of the whole pr= oject at some point, so I'm sure you're familiar with this concept = already.=C2=A0 We're definitely not suggesting a relicense of the whole= project -- we're suggesting explicitly licensing the stuff that is tod= ay claimed to be PD.

[end of q/a]

OK, so where does that leave us?=C2=A0 One invarian= t exists: as a team that works for Google, we can't use anything that w= as contributed to musl as PD.=C2=A0 Others probably shouldn't, but we s= trictly *can't*.=C2=A0 We can approach this from different angles:

Practicall= y: By claiming that things are public domain, you're having the inverse= effect of what you want -- fewer people can actually use the work.=C2=A0 J= ust because you claim something is PD doesn't make it so - it sucks, bu= t that's the current legal situation.=C2=A0 If you really want somethin= g to be as widely usable as possible, not only now but years from now, lice= nse it BSD-0.

Ideologically: Sure, things like numbers or APIs aren't (or sho= uldn't be) copyrightable, but that's not all there is here.=C2=A0 T= he musl headers don't look exactly like any other libc's headers.= =C2=A0 Work has gone into them over the years.=C2=A0 They're ordered di= fferently.=C2=A0 Variable names are different.=C2=A0 Look at include/alltypes.h.in or math.h for more differences= .=C2=A0 You may consider this work to be trivial, but it IS original.=C2=A0= We can't (and shouldn't) use it without a license.

Our suggestion: pleas= e get permission from the relevant people to release their work as BSD-0, r= emove the public domain text from COPYRIGHT, license the headers and crt, e= tc. files as BSD-0.=C2=A0 In a separate file, register your opinions and in= tent that the public headers, etc. should be freely usable and unowned by a= nyone but the current state of affairs WRT software and copyright is comple= te shit (which it so totally is).
--001a11337236b202d5052e4709a7--