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