[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160315224126.GA5402@brightrain.aerifal.cx>
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.
