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.