From: Rich Felker <dalias@libc.org>
To: Ed Maste <emaste@freebsd.org>
Cc: musl@lists.openwall.com
Subject: Re: musl licensing
Date: Thu, 17 Mar 2016 15:16:40 -0400 [thread overview]
Message-ID: <20160317191640.GA32582@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAPyFy2BsFqZAO79uzz4O2XgsZrHAQTW-DKb4mWnzfE3ShpmtFw@mail.gmail.com>
On Thu, Mar 17, 2016 at 02:49:55PM -0400, Ed Maste wrote:
> On 16 March 2016 at 23:19, Rich Felker <dalias@libc.org> wrote:
> >
> > What would be the minimal requirement for you not to need to modify
> > the files? Full license text? Or would something like having the
> > copyright holders named and "licensed under standard MIT license" or
> > similar (possibly with a reference of some sort) suffice?
>
> I think it depends on context. For example, If we planned to import
> musl into our contrib/ tree and build it as a standalone entity the
> current form (with no individual file statements) would be just fine.
>
> But in this case, where I hope to combine a few files into our
> existing libc I'll want the license text in the file as it's
> consistent with the rest of our libc, and it avoids adding a
> MIT-LICENSE.txt, MUSL-LICENSE.txt or similar file to the tree.
Indeed, I was thinking more along the lines of whether we're to the
point that standard licenses could be referenced by name/identifier
without an in-tree copy.
> > I'm trying to gauge if we should try to make it so you don't need to
> > modify the files, or if that's not a practical goal while avoiding
> > massive comment-spam in source files.
>
> I don't think it's a practical goal to entirely avoid needing to
> modify files; I had to do so for a minor header variations or some
> such anyhow. From my perspective, my order of preference is full
> authorship + license, authorship + license statement, status quo. I do
> understand wanting to avoid the full license text though. Do other
> potential downstream consumers of musl have a preference?
I think our community tends to dislike files which are 20+ lines of
copyright/license comments followed by <10 lines of code. Whether
there are situations where the file size makes a practical difference,
I don't know. One observation: on a standard-size terminal it's likely
you wouldn't seen _any_ code on the first page with a full-license
comment header.
Rich
next prev parent reply other threads:[~2016-03-17 19:16 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
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 [this message]
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=20160317191640.GA32582@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=emaste@freebsd.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).