From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9641 Path: news.gmane.org!not-for-mail From: Christopher Lane Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl licensing Date: Wed, 16 Mar 2016 14:38:28 -0700 Message-ID: References: <20160316201358.GN9349@brightrain.aerifal.cx> <20160316211943.ed54cf246e0020872e15eb6a@frign.de> <20160316203428.GO9349@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11405fc0a2949b052e31556d X-Trace: ger.gmane.org 1458164328 30929 80.91.229.3 (16 Mar 2016 21:38:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Mar 2016 21:38:48 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9654-gllmg-musl=m.gmane.org@lists.openwall.com Wed Mar 16 22:38:43 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1agJ9O-0007aW-R3 for gllmg-musl@m.gmane.org; Wed, 16 Mar 2016 22:38:43 +0100 Original-Received: (qmail 30431 invoked by uid 550); 16 Mar 2016 21:38:40 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 30413 invoked from network); 16 Mar 2016 21:38:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=xxcSS+NTjUfw82dspQxjgKkqJNbfEM1Hnu8xqzzVwBw=; b=Z5jsoAxkOQkx6hseAjE4NAIKkvrVhcEPG+OCU33TbzxdgPxyktAe5HyUY1fnjjQx+l tQjSpgAgTgoJirjv5oM41NCr3lM0ypVon+rpakarzHkA7KCtyqUq4/n05ZkBaaSge5RP YQHmPpUxtLtCP5DrwQXJsdGB1oN5ylSNf0aBSKCq+N2UASm7T676EW6F9NJiQCG51aSb 8Fs7Ta7njl/ujhRGW9/hxvm75V+7hFea3GvUb2fIEKQYEur65azgiuLSCmGaeBuF/Vq9 E+IRc/Wb6zzAruW1Tv6GJQE+L7gou2zRgElzj/Un8F+E7TlKqkXVTPakuB8evn8CQ3hX QtHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=xxcSS+NTjUfw82dspQxjgKkqJNbfEM1Hnu8xqzzVwBw=; b=OQ0up8KOys0PBRR1eQBgnqGUXuBuxFJZbftyUR2sGuN5NXb/Fsu6m8vtrh0FTBZ4UA O6dtGJ+eLB690wgFpEmi8aQdpT5ZiGkdOzmjMwfDrl0W4CoJnkzDyiliAqFxy1f5XSzF qytdPkpQ0fC1AE7AJ8ZvCP47onyJ9ubWzI+n8DZctaHcJPahsUyA+JYQUR2UvA5RBMqf GWn5yQ+CEgbVbxjVl/qvxi74Wq7KPJQr9W2sub9HZsXnS8YyhHOBU5jmeFshvsl09QGo 3fWfz8+4QyyRhcQWEKeMwb7GO0uHcVclP4EQaw8ng4QXyI+k4iJBQaUYxvQ3LRGMlels v1HQ== X-Gm-Message-State: AD7BkJLim9woV/Uuqm3cfuhZTBas0sgt+GR/eZOnk5ex1xM+xbf6Vt6ZzgObYCpbHZ/htdpg89cMaOeUXu4rBQ== X-Received: by 10.107.35.16 with SMTP id j16mr6088028ioj.10.1458164308544; Wed, 16 Mar 2016 14:38:28 -0700 (PDT) In-Reply-To: <20160316203428.GO9349@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:9641 Archived-At: --001a11405fc0a2949b052e31556d Content-Type: text/plain; charset=UTF-8 On Wed, Mar 16, 2016 at 1:34 PM, Rich Felker wrote: > On Wed, Mar 16, 2016 at 09:19:43PM +0100, FRIGN wrote: > > On Wed, 16 Mar 2016 16:13:58 -0400 > > Rich Felker 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 --001a11405fc0a2949b052e31556d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 16, 2016 at 1:34 PM, Rich Felker <dalias@libc.org> wro= te:
On Wed, Mar 16, 2016 at 09:19:43PM= +0100, FRIGN wrote:
> On Wed, 16 Mar 2016 16:13:58 -0400
> Rich Felker <dalias@libc.org= > wrote:
>
> Hey Rich,
>
> > 1. Staying on topic. The topic at hand is not "relicensing&q= uot; or
> > anything crazy, just figuring out what's not sufficiently cle= ar 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 the= ir
> > needs and perhaps also improve the ease with which other users wh= o
> > 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<= br> 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.=C2=A0= 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 ma= jority of software developers.=C2=A0 But unfortunately, neither your opinio= n, mine, or Google's matters much when the courts have said otherwise.= =C2=A0 That said, I don't want you (or anyone else who is passionate ab= out this) to misrepresent your position on this.=C2=A0 I suggest you DO rec= ord your opinion that the public headers/APIs are "public domain"= and not copyrightable, but please don't do it in the LICENSE file sinc= e it defeats the purpose of providing a clear license.

Also, in case you're wondering who I am:
Hi, I'm= Chris.=C2=A0 I work on the same team as Petr.=C2=A0 Nice to meet you :)
=C2=A0

> > 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 clu= tter,
> > avoiding diff hunks to update copyright years, etc. But it also h= as
> > disadvantages such as making it easy to forget to update and argu= ably
> > being hard to interpret. I think this is an area where it would b= e
> > useful to discuss pros and cons and whether there are in-between<= br> > > 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 necessa= ry
> 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
--001a11405fc0a2949b052e31556d--