[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160318042158.GN21636@brightrain.aerifal.cx>
Date: Fri, 18 Mar 2016 00:21:58 -0400
From: Rich Felker <dalias@...c.org>
To: Christopher Lane <lanechr@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: musl licensing
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.
> 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
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.
