[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160316045453.GB22033@newbook>
Date: Tue, 15 Mar 2016 21:54:54 -0700
From: Isaac Dunham <ibid.ag@...il.com>
To: musl@...ts.openwall.com
Subject: Re: musl licensing
On Tue, Mar 15, 2016 at 06:41:26PM -0400, Rich Felker wrote:
> On Tue, Mar 15, 2016 at 02:59:24PM -0700, Petr Hosek wrote:
> > 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.
That's OK with me.
I do note that src/misc/fmtmsg.c, written by myself, does not fall
under the "no copyrightable original content" rule.
It was my intent that it should be available to use as widely as
possible.
Since the main license of musl is MIT, which is a rough approximation of
that, I'm fine with it being marked as MIT.
0BSD is also perfectly acceptable to me.
Additionally, some of the code in src/crypt/* is marked as public domain;
as far as I can tell, this was from nsz (commit 88bf5a8a).
> > 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
(See the statement above.)
> > 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.
Agreed.
Thanks,
Isaac Dunham
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.
