[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 17 Mar 2016 21:47:09 -0700
From: Christopher Lane <lanechr@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: musl licensing
On Mar 17, 2016 9:21 PM, "Rich Felker" <dalias@...c.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:
There are some architectures we don't need, so we can prune the list a bit
for sure. Tomorrow we can send you a list of all the files we care about
that are claimed to be PD.
>
> 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.
>
I THINK this is acceptable. I've read it through 4 or 5 times and it makes
sense to me and seems to cover everyone's needs. I'll verify for sure
though.
> > 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
Hah, yes. One of the lawyers did make an off-hand comment of "CC0 has the
same problem, it's one of the issues with that..."
>
> > 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.
SGTM. I know our lawyers would suggest some kind of electronic signature
(and have), but I've been trying to suss out the minimum requirements from
the recommendations. IDK if they're particularly passionate about some
kind of additional formality, but that's a 1:1 thing for just a handful of
people, so I think we can probably handle the implementation details off
list.
>
> > 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
Overall I'm pleased with your proposal. I'm optimistic that'll work, but I
should be able to find out for sure tomorrow.
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.
