Date: Thu, 17 Mar 2016 21:25:32 +0000 From: Petr Hosek <phosek@...omium.org> To: musl@...ts.openwall.com Subject: Re: musl licensing In Chromium and all related projects, which are licensed under the BSD license, we use a much shorter header: // Copyright 2016 The Chromium Authors. All rights reserved. // Use of this source code is governed by a BSD-style license that can be // found in the LICENSE file. On Thu, Mar 17, 2016 at 2:17 PM Wink Saville <wink@...ille.com> wrote: > 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 > Content of type "text/html" skipped
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.