From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: musl licensing
Date: Wed, 16 Mar 2016 16:34:28 -0400 [thread overview]
Message-ID: <20160316203428.GO9349@brightrain.aerifal.cx> (raw)
In-Reply-To: <20160316211943.ed54cf246e0020872e15eb6a@frign.de>
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" 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
next prev parent reply other threads:[~2016-03-16 20:34 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-15 21:59 Petr Hosek
2016-03-15 22:17 ` croco
2016-03-16 16:32 ` Alexander Cherepanov
2016-03-16 22:50 ` Petr Hosek
2016-03-16 22:55 ` Josiah Worcester
2016-03-16 23:46 ` Rich Felker
2016-03-17 2:06 ` Christopher Lane
2016-03-17 3:04 ` Rich Felker
2016-03-17 8:17 ` u-uy74
2016-03-17 15:14 ` Christopher Lane
2016-03-17 15:28 ` FRIGN
2016-03-17 15:49 ` Hugues Bruant
2016-03-17 15:57 ` Rich Felker
2016-03-17 16:01 ` Rich Felker
2016-03-17 23:32 ` Christopher Lane
2016-03-18 4:21 ` Rich Felker
2016-03-18 4:47 ` Christopher Lane
2016-03-18 18:07 ` Rich Felker
2016-03-18 18:16 ` Christopher Lane
2016-03-18 19:12 ` Rich Felker
2016-03-18 19:47 ` George Kulakowski
2016-03-19 4:35 ` Rich Felker
2016-03-21 22:46 ` Christopher Lane
2016-03-23 2:32 ` Rich Felker
2016-03-23 20:35 ` Christopher Lane
2016-03-23 22:53 ` Rob Landley
2016-03-29 17:18 ` Christopher Lane
2016-03-29 17:21 ` Christopher Lane
2016-03-29 20:03 ` Rich Felker
2016-03-29 20:21 ` Christopher Lane
2016-03-30 6:56 ` u-uy74
2016-03-30 14:11 ` Christopher Lane
2016-03-30 14:43 ` u-uy74
2016-03-18 8:31 ` u-uy74
2016-03-17 1:26 ` Alexander Cherepanov
2016-03-17 2:20 ` Christopher Lane
2016-03-15 22:20 ` Kurt H Maier
2016-03-15 22:20 ` Josiah Worcester
2016-03-15 22:41 ` Rich Felker
2016-03-15 22:49 ` Shiz
2016-03-16 4:54 ` Isaac Dunham
2016-03-16 8:00 ` u-uy74
2016-03-16 10:31 ` Szabolcs Nagy
2016-03-16 10:55 ` FRIGN
2016-03-16 12:34 ` Szabolcs Nagy
2016-03-16 12:46 ` Anthony J. Bentley
2016-03-16 13:49 ` u-uy74
2016-03-16 14:07 ` FRIGN
2016-03-16 14:01 ` FRIGN
2016-03-16 14:47 ` Szabolcs Nagy
2016-03-16 10:22 ` FRIGN
2016-03-16 20:13 ` Rich Felker
2016-03-16 20:19 ` FRIGN
2016-03-16 20:34 ` Rich Felker [this message]
2016-03-16 21:11 ` Jens Gustedt
2016-03-16 21:15 ` FRIGN
2016-03-16 21:35 ` Rich Felker
2016-03-16 21:50 ` FRIGN
2016-03-16 21:34 ` John Levine
2016-03-16 21:38 ` Christopher Lane
2016-03-17 2:01 ` Ed Maste
2016-03-17 3:19 ` Rich Felker
2016-03-17 18:49 ` Ed Maste
2016-03-17 19:16 ` Rich Felker
2016-03-17 21:16 ` Wink Saville
2016-03-17 21:25 ` Petr Hosek
2016-03-17 22:56 ` Ruediger Meier
2016-03-17 23:07 ` Anthony J. Bentley
2016-03-17 23:19 ` Kurt H Maier
2016-03-17 23:31 ` Anthony J. Bentley
2016-03-17 23:46 ` Ruediger Meier
2016-03-18 3:30 ` Kurt H Maier
2016-03-18 3:41 ` Rich Felker
2016-03-18 3:55 ` Christopher Lane
2016-03-17 21:42 ` Ed Maste
2016-03-17 23:37 ` Luca Barbato
2016-03-18 8:01 ` u-uy74
2016-03-18 12:35 ` chromium with musl libc (was: [musl] musl licensing) Natanael Copa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160316203428.GO9349@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).