Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160316203428.GO9349@brightrain.aerifal.cx>
Date: Wed, 16 Mar 2016 16:34:28 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: musl licensing

On Wed, Mar 16, 2016 at 09:19:43PM +0100, FRIGN wrote:
> On Wed, 16 Mar 2016 16:13:58 -0400
> Rich Felker <dalias@...c.org> wrote:
> 
> Hey Rich,
> 
> > 1. Staying on topic. The topic at hand is not "relicensing" or
> > anything crazy, just figuring out what's not sufficiently clear to
> > Google's lawyers about our current licensing or documentation of
> > copyright status, and whether there are "non-functional" (clarifying)
> > changes that could be made to the source tree that would meet their
> > needs and perhaps also improve the ease with which other users who
> > have to deal with legal deparements can use musl.
> 
> I think the biggest concern on behalf of Google is the code licensed
> under public domain. There needs to be a decision for that.

Yes, what I'm waiting for on this is whether a "conditional license"
("if this code is deemed to be covered by copyright, then we license
it as BSD0/CC0/whatever") will satisfy them. This makes no difference
in jurisdictions where public domain is recognized but may make them
happy.

I very much do not want to actually _claim_ copyright on these files,
because it's my position (and I believe also Google's position vs
Oracle) that pure facts of API interfaces without any additional
expressive content are not copyrightable.

> > 2. In-line vs out-of-line copyright/license info. The out-of-line form
> > we have now has some benefits, mainly in avoiding source file clutter,
> > avoiding diff hunks to update copyright years, etc. But it also has
> > disadvantages such as making it easy to forget to update and arguably
> > being hard to interpret. I think this is an area where it would be
> > useful to discuss pros and cons and whether there are in-between
> > solutions that get the best properties of both.
> 
> As I promoted in my previous mails, I favor an out-of-line
> copyright/license info with a small one-line remark in each
> source file. This actually makes it easy to update years (only necessary
> in the COPYRIGHT file) and makes it easier for people to find out what
> license code is under.

What about authorship/copyright holders per-file?

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.