Date: Tue, 15 Mar 2016 18:41:26 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: musl licensing A quick note to clarify -- I was first contacted by Google off-list and suggested taking this discussion on-list since I felt like discussing these kind of licensing things myself in private would be going behind the community's back. I'm excited about Google's interest in using musl but also want to be open with the community, and I hope we can discuss these things in a constructive way. A few of the ideas below come as a surprise to me and I'll try to address them: On Tue, Mar 15, 2016 at 02:59:24PM -0700, Petr Hosek wrote: > We work on Chromium project at Google. Our team, as well as several > other teams here at Google, would like to start using musl in various > open-source projects. This includes shipping musl as a part of SDKs > and toolchains. However, after performing a standard license review, > our open-source lawyers told us that there are two obstacles to us > being able to use musl. > > The first issue is the lack of clarity around per-file licensing and > copyright attribution. It's always been my intent to be document copyright status of the various parts of musl in detail in the COPYRIGHT file. If adding one-line notices to non-trivial source files would help gain acceptence by lawyers, I don't think that would be terribly controversial. However I do think it may be controversial to start claiming copyright on utterly trivial source files that could have been mechanically generated and that could not possibly be written in any way other than how they're currently written without adding gratuitous stuff. > The other issue is the claim that some files > (in particular, the public headers and C runtime) are in the public > domain. While this might be technically correct, it's not legally > sound and we would be legally unable to use these files without them > being placed under copyright and an open source license. The most > appropriate way of addressing both issues would be to include a > copyright notice in individual source and header files. As far as the public headers, it's my view that the vast majority do not contain any copyrightable original content. For the standard interfaces they all just match the interface requirements of ISO C and POSIX; only some specific type definitions and numeric constants are implementation-specific, and these are just minimal factual definitions matching ABIs/kernel. Some places have a very small amount of what you might call 'code' in public headers, but they're all the obvious/only way to express what they're doing, not anything creative. What I think might be a reasonable solution is to explicitly state, preferably just in the COPYRIGHT file alongside the current statement that these files are in the public domain, that in the event a court should determine that the authors hold copyright on these files (despite expressing clearly that they don't want to and don't believe they can :), permission to use them under a BSD0 license is granted. > Rather than working around these issues by reimplementing parts of > musl, we would like to work with the musl community to directly > address these issues. We believe that our company's interpretation of > the copyright and authorship is the same across the entire industry > and resolving these issues would benefit both musl as well as projects > which already do or plan to use musl. > > To address both issues, authors of all files in musl that are "public > domain" or any other non-license will have to agree with relicensing > their work under the MIT license (or any other compatible open-source > license). Furthermore, all past and future contributors will have to > to sign the Contributor License Agreement (CLA). Since the majority of > musl authors are present in this forum, we're reaching out to you to > ask whether this is something you would agree with and also to start > the discussion within the wider musl community. I don't think anything CLA-like is acceptable to our community. All the evidence points to it being a huge barrier to entry for new contributors. There is plenty of documentation of development process in the git log and on the mailing list to show that our contributors are submitting code with the intent that it be used in musl under the project's license. 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.