Re: musl licensing

[Christopher Lane <lanechr@gmail.com>]

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

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.  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

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