[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 16 Mar 2016 14:38:28 -0700
From: Christopher Lane <lanechr@...il.com>
To: musl@...ts.openwall.com
Subject: Re: musl licensing
On Wed, Mar 16, 2016 at 1:34 PM, Rich Felker <dalias@...c.org> wrote:
> 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.
>
WRT conditional licensing along the lines of "this is public domain if you
think that's a thing, otherwise this is BSD0," that's legally ambiguous
enough that it doesn't actually help that much. If you ("you" in the
collective musl project sense) are willing to license under BSD0 in some
set of circumstances, it's clearer if you just do that without the public
domain condition.
I agree that APIs aren't copyrightable, and I believe so do the majority of
software developers. But unfortunately, neither your opinion, mine, or
Google's matters much when the courts have said otherwise. That said, I
don't want you (or anyone else who is passionate about this) to
misrepresent your position on this. I suggest you DO record your opinion
that the public headers/APIs are "public domain" and not copyrightable, but
please don't do it in the LICENSE file since it defeats the purpose of
providing a clear license.
Also, in case you're wondering who I am:
Hi, I'm Chris. I work on the same team as Petr. Nice to meet you :)
>
> > > 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
>
--
kthxbai
:wq
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.
