[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 17 Mar 2016 14:16:29 -0700
From: Wink Saville <wink@...ille.com>
To: musl@...ts.openwall.com
Cc: Ed Maste <emaste@...ebsd.org>
Subject: Re: musl licensing
As a data point, in android the file copyright header
(https://android.googlesource.com/platform/bionic/+/master/benchmarks/math_benchmark.cpp)
is 13-15 lines long depending on how you want to count it:
/*
* Copyright (C) 2013 The Android Open Source Project
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
On Thu, Mar 17, 2016 at 12:16 PM, Rich Felker <dalias@...c.org> wrote:
> 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.
