From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9694 Path: news.gmane.org!not-for-mail From: Christopher Lane Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl licensing Date: Fri, 18 Mar 2016 11:16:49 -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> <20160318042158.GN21636@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b3a93d22aa42d052e56c0b3 X-Trace: ger.gmane.org 1458325027 26619 80.91.229.3 (18 Mar 2016 18:17:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 18 Mar 2016 18:17:07 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-9707-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 18 19:17:06 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 1agyxM-00069D-Td for gllmg-musl@m.gmane.org; Fri, 18 Mar 2016 19:17:05 +0100 Original-Received: (qmail 3679 invoked by uid 550); 18 Mar 2016 18:17:02 -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 3651 invoked from network); 18 Mar 2016 18:17:01 -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=04rrOL68YUxuqfGbTen2Pi5Y/As0gjpqSuvgrgYO1I4=; b=ZtaO4eG7yzkHhfEeTv+TO9Ie4z0ohoWB4ylgErCRULDqNDKbwQZTD8MmGI8NXf065Y tN/8Z3mafK+XhddtqQi1Y4VkSo98OpjKCBXw49xJWhI8uxqdjk+ienPvftT5t2Zd//bA U3xLkO/VDfcCJLqJQyTGXBpFvoUH8KKeQVZGT/YCIMlEiSS+JkcsjdPv9FWXN+e4ODCu GHKqXlilLTFYa9QOMupplGNgLQsdum0OLbLkgEopTtZyb1rDKzYOzWmP/BkOgxejIjWO QDwyIjuzPC7d3PHtD/imDlrLCAVGKXZKLLpn8UTzwVeosk2XP4NgYVti/mCGL3A+/kuc Lv9g== 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=04rrOL68YUxuqfGbTen2Pi5Y/As0gjpqSuvgrgYO1I4=; b=Ctc+hNFTUDxVaq3uxyTdHeqQeKYed25lB3OBGcM9hI4BDHhAM8tP9mFUHITk/ALSEc l1LMRrZbSlS89ITES/L2+6aIxQu51uVZHFcpM1wBnQiL39/ShxjSj06yI0DKf7vq+uW3 LCpzkF59ZtQZu+4s6cTdYE34ZfGDz5oPsvFHk3Tjw9Ct9N2eXN3zArBD6oOjcQs8Uoq/ htUR7zur56L5zz/37fh9Xn1vaSr8ZKZ+9Va6t4sD3pitrOGzlRoo0hA5Cdfu9P0QZe04 HuRa/+Ypc/F1PwlB5Smq/wh7shGgf1+QQ3ADKXRRJOWW1A7eJf2VXRcMmW1Nm6og8ruZ xl1Q== X-Gm-Message-State: AD7BkJJVn0LLd4Wqdo7wk27/PkQTNZ1uv1B9p3Go5tfn+yRfbEdpueT74cwbhOityRxCbd6yD7F6Nd/PRPzJCw== X-Received: by 10.50.65.35 with SMTP id u3mr841787igs.3.1458325009636; Fri, 18 Mar 2016 11:16:49 -0700 (PDT) In-Reply-To: <20160318042158.GN21636@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:9694 Archived-At: --047d7b3a93d22aa42d052e56c0b3 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 17, 2016 at 9:21 PM, Rich Felker wrote: > On Thu, Mar 17, 2016 at 04:32:03PM -0700, Christopher Lane wrote: > > I've returned from the land of lawyers with answers. Please pardon the > > length of this email. > > Great! No problem, detail is good. > > > 1. Why doesn't the MIT license apply in the case where PD one doesn't? > > I disagree with your lawyers' interpretation here, but that doesn't > mean I'm not going to work on a solution they'll like anyway, so don't > worry. For the sake of our audience/community I'd like to explain. I'm > with them up to the point of: > > > 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. > > If the whole project is licensed under the MIT license, and by > convention files in certain directories also come with an additional > permission grant/release (essentially a dual license, especially if > you don't accept the PD statement as actually putting something in the > PD but just as a vague imprecise license), then "contributed under the > license the open source project itself is released under" at least > includes the license of the whole project, and possibly this "dual > license". It doesn't magically become something more restrictive than > the whole-project license. However since the whole "implicitly > contributed under the license" theory lacks strong legal formalities > to begin with, I understand how lawyers could be scared here. So... > > > 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. > > ...here's what I propose to do: > > I'll contact all significant contributors to crt files and public > headers (this will mostly be port contributors, for the arch/bits/*.h > files, but does Google even want/need these for their use or will they > be providing their own?) and: > > 1. Explain that, due to musl's statement in the COPYRIGHT file that we > believe these files to be in the public domain, Google's lawyers > are unclear whether they actually granted permissions for them. > > 2. Ask them to clarify that their intent actually was to contribute > these files under musl's standard whole-project (MIT) license. > > 3. Ask for an additional exception to the requirements of the MIT > license for these files, that attribution not be required. > (Alternatively a BSD0 could be used, but I think the exception > "sounds like" less of a change despite being equivalent and matches > the existing intent just fine anyway.) > > Some version of the PD text can remain in place but I can clarify that > it's my/our belief about these files and does not negate the fact that > we're licensing the whole project, including these files as part of > it, under the MIT license. Assuming we get a suitable response for #3 > above, I can also add the text that the following contributors > (listed) all grant the attribution exception for these files. And for > future port contributors I can ask them to do the same at the time of > contribution. > > Is this acceptable? If it sounds like it may be but there are > questions about the specific language I can prepare a proposed diff > for the COPYRIGHT file for review. > So yeah, this is a good idea. Please send the diff and I'll get their comments on the specific language. > > > 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. > > That language was taken almost verbatim from CC0. :-P > > > 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). > > Yes, as mentioned above I'll have contributors of these files clarify > that they accept licensing under the more permissive terms at the time > of contribution. I don't think we need to make a CLA-like formality > out of it though; just a license statement alongside the patch > submission is fine. > > > 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. > > At that point musl had exactly one contributor other than myself who > hadn't already explicitly MIT'd their contributions, so there was > essentially nothing to do. :-) > > Rich > -- kthxbai :wq --047d7b3a93d22aa42d052e56c0b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Mar 17, 2016 at 9:21 PM, Rich Felker <dalias@libc.org> wrote:
On Thu, Mar 17,= 2016 at 04:32:03PM -0700, Christopher Lane wrote:
> I've returned from the land of lawyers with answers.=C2=A0 Please = pardon the
> length of this email.

Great! No problem, detail is good.

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

I disagree with your lawyers' interpretation here, but that does= n't
mean I'm not going to work on a solution they'll like anyway, so do= n't
worry. For the sake of our audience/community I'd like to explain. I= 9;m
with them up to the point of:

> Essentially, because 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 convention that the work is being contributed und= er
> the license the open source project itself is released under.

If the whole project is licensed under the MIT license, and by
convention files in certain directories also come with an additional
permission grant/release (essentially a dual license, especially if
you don't accept the PD statement as actually putting something in the<= br> PD but just as a vague imprecise license), then "contributed under the=
license the open source project itself is released under" at least
includes the license of the whole project, and possibly this "dual
license". It doesn't magically become something more restrictive t= han
the whole-project license. However since the whole "implicitly
contributed under the license" theory lacks strong legal formalities to begin with, I understand how lawyers could be scared here. So...

> Anyway, applying the open source convention above to the case of musl,= if
> work is contributed to the include/*, arch/*/bits/* or crt/* directori= es,
> 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 as= sumed to
> have been contributed under MIT.=C2=A0 Instead, that work is considere= d to have
> been contributed without a license.=C2=A0 We could argue over whether = this would
> _actually_ happen, but it doesn't matter -- that chain of events i= s
> plausible enough for it to be a problem.

...here's what I propose to do:

I'll contact all significant contributors to crt files and public
headers (this will mostly be port contributors, for the arch/bits/*.h
files, but does Google even want/need these for their use or will they
be providing their own?) and:

1. Explain that, due to musl's statement in the COPYRIGHT file that we<= br> =C2=A0 =C2=A0believe these files to be in the public domain, Google's l= awyers
=C2=A0 =C2=A0are unclear whether they actually granted permissions for them= .

2. Ask them to clarify that their intent actually was to contribute
=C2=A0 =C2=A0these files under musl's standard whole-project (MIT) lice= nse.

3. Ask for an additional exception to the requirements of the MIT
=C2=A0 =C2=A0license for these files, that attribution not be required.
=C2=A0 =C2=A0(Alternatively a BSD0 could be used, but I think the exception=
=C2=A0 =C2=A0"sounds like" less of a change despite being equival= ent and matches
=C2=A0 =C2=A0the existing intent just fine anyway.)

Some version of the PD text can remain in place but I can clarify that
it's my/our belief about these files and does not negate the fact that<= br> we're licensing the whole project, including these files as part of
it, under the MIT license. Assuming we get a suitable response for #3
above, I can also add the text that the following contributors
(listed) all grant the attribution exception for these files. And for
future port contributors I can ask them to do the same at the time of
contribution.

Is this acceptable? If it sounds like it may be but there are
questions about the specific language I can prepare a proposed diff
for the COPYRIGHT file for review.

So y= eah, this is a good idea.=C2=A0 Please send the diff and I'll get their= comments on the specific language.
=C2=A0

> 2. Is it sufficient to add the language you wrote earlier? ("Shou= ld the
> release of these files into the Public Domain be judged legally invali= d or
> ineffective ... [Redistribution and use] with or without modification,= are
> permitted.")
>
> No.=C2=A0 Why?=C2=A0 Well, because here's what would happen.=C2=A0= Let's say this claim is
> tested - the phrase "judged legally 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.

That language was taken almost verbatim from CC0. :-P

> 3. Is adding a musl CLA a requirement, a suggestion, or what?
>
> If you assume the validity of the whole "open source licensing co= nvention"
> I mentioned earlier, it's not required for future contributions.= =C2=A0 I mean,
> obviously right, because there are plenty of open source projects with= out
> them.
>
> But if you do end up removing the public domain claim from the COPYRIG= HT
> file (which we seriously recommend) you should at least collect agreem= ents
> from folks who contributed work that might be affected (to make sure t= hey
> agree to contributing that work under e.g. BSD-0).

Yes, as mentioned above I'll have contributors of these files cl= arify
that they accept licensing under the more permissive terms at the time
of contribution. I don't think we need to make a CLA-like formality
out of it though; just a license statement alongside the patch
submission is fine.

> I believe musl went
> through a relicense of the whole project at some point, so I'm sur= e you're
> familiar with this concept already.=C2=A0 We're definitely not sug= gesting a
> relicense of the whole project -- we're suggesting explicitly lice= nsing the
> stuff that is today claimed to be PD.

At that point musl had exactly one contributor other than myself who=
hadn't already explicitly MIT'd their contributions, so there was essentially nothing to do. :-)

Rich



--
kthxbai
:wq
--047d7b3a93d22aa42d052e56c0b3--