Date: Thu, 17 Mar 2016 16:32:03 -0700 From: Christopher Lane <lanechr@...il.com> To: Rich Felker <dalias@...c.org> Cc: musl@...ts.openwall.com Subject: Re: musl licensing On Thu, Mar 17, 2016 at 9:01 AM, Rich Felker <dalias@...c.org> wrote: > On Thu, Mar 17, 2016 at 08:14:04AM -0700, Christopher Lane wrote: > > On Mar 17, 2016 1:18 AM, <u-uy74@...ey.se> wrote: > > > > > > On Wed, Mar 16, 2016 at 07:06:25PM -0700, Christopher Lane wrote: > > > > ... if releasing under e.g. BSD0 is OK when PD isn't > > > > valid, why isn't it OK for all situations. > > > > > > I expect that it is illegal in certain jurisdictions to claim > > > copyright on a public domain matter. > > > > > > This is not a problem for the musl user (Google) but potentially > endangers > > > the developer who wrote the questionable copyright statement. > > > > > > This may explain why Google explicitly mentions "non-copyrightable" in > a > > case > > > when it represents the developer party: > > > > > > On Wed, Mar 16, 2016 at 11:31:25AM +0100, Szabolcs Nagy wrote: > > > > bionic actually generates its kernel interface headers from (gpl) > code > > > > and each file has the comment: > > > > > > > > *** This header was automatically generated from a Linux kernel > > header > > > > *** of the same name, to make information necessary for userspace > to > > > > *** call into the kernel available to libc. It contains only > > constants, > > > > *** structures, and macros generated from the original header, and > > thus, > > > > *** contains no copyrightable information. > > > > > > So this is actually all about which party shall take the risks, > > > musl or Google. Isn't it? > > > > This isn't about shoveling risk from Google to musl. We want musl to be > a > > clear and unambiguously licensable product so we can use it. > Incidentally, > > figuring out the licensing stuff here is a large distraction for our team > > (and we knew it would be), but we're willing to put in the time and > effort > > because we think it's beneficial for the open source community overall, > and > > because it's ethically correct. This isn't just CYA, and it's not some > > nefarious scheme. > > > > WRT bionic, I don't know what they're doing and I don't have any insight > > into what went into that decision. I only know what our team has been > told > > about using musl. > > > > If it comes down to it, it might be possible for us to avoid using any of > > the public domain parts of musl - maybe in a fashion similar to what > bionic > > did, I don't know yet. If that's good enough for our lawyers, it'll get > > our team unblocked and that's good enough I guess. Though, I'd prefer we > > solve this without such a workaround so others can benefit. > > I understand that's a possibility, but I'd like to work with you to > make sure that's not one you have to take, since using these parts is > actually one of the best aspects of using musl. > > Rich > I've returned from the land of lawyers with answers. Please pardon the length of this email. 1. Why doesn't the MIT license apply in the case where PD one doesn't? 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. As an aside, this has apparently never been litigated and therefore is not necessarily true, but it's taken as fact in the vast majority of the open source community. Google won't accept contributions to its open source projects under a mere convention, so it requires CLA (that isn't directly applicable here, I just thought it was an interesting fact.) 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. 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. Also, just adding the language doesn't address the first point - that the (presumed) relevant text of the COPYRIGHT file is the text when the files were contributed. 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). 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. [end of q/a] OK, so where does that leave us? One invariant exists: as a team that works for Google, we can't use anything that was contributed to musl as PD. Others probably shouldn't, but we strictly *can't*. We can approach this from different angles: Practically: By claiming that things are public domain, you're having the inverse effect of what you want -- fewer people can actually use the work. Just because you claim something is PD doesn't make it so - it sucks, but that's the current legal situation. If you really want something to be as widely usable as possible, not only now but years from now, license it BSD-0. Ideologically: Sure, things like numbers or APIs aren't (or shouldn't be) copyrightable, but that's not all there is here. The musl headers don't look exactly like any other libc's headers. Work has gone into them over the years. They're ordered differently. Variable names are different. Look at include/alltypes.h.in or math.h for more differences. You may consider this work to be trivial, but it IS original. We can't (and shouldn't) use it without a license. Our suggestion: please get permission from the relevant people to release their work as BSD-0, remove the public domain text from COPYRIGHT, license the headers and crt, etc. files as BSD-0. In a separate file, register your opinions and intent that the public headers, etc. should be freely usable and unowned by anyone but the current state of affairs WRT software and copyright is complete shit (which it so totally is). 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.