Re: musl licensing

[Petr Hosek <phosek@chromium.org>]

[-- Attachment #1: Type: text/plain, Size: 3405 bytes --]

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@saville.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@libc.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@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
>

[-- Attachment #2: Type: text/html, Size: 4518 bytes --]