Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160317191640.GA32582@brightrain.aerifal.cx>
Date: Thu, 17 Mar 2016 15:16:40 -0400
From: Rich Felker <dalias@...c.org>
To: Ed Maste <emaste@...ebsd.org>
Cc: musl@...ts.openwall.com
Subject: Re: musl licensing

On Thu, Mar 17, 2016 at 02:49:55PM -0400, Ed Maste wrote:
> On 16 March 2016 at 23:19, Rich Felker <dalias@...c.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

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.