From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9663 Path: news.gmane.org!not-for-mail From: Petr Hosek Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl licensing Date: Thu, 17 Mar 2016 21:25:32 +0000 Message-ID: References: <20160316201358.GN9349@brightrain.aerifal.cx> <20160316211943.ed54cf246e0020872e15eb6a@frign.de> <20160316203428.GO9349@brightrain.aerifal.cx> <20160317031924.GC21636@brightrain.aerifal.cx> <20160317191640.GA32582@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11373502c58a01052e4545b0 X-Trace: ger.gmane.org 1458249967 18664 80.91.229.3 (17 Mar 2016 21:26:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Mar 2016 21:26:07 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9676-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 17 22:26:03 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1agfQb-0004El-H4 for gllmg-musl@m.gmane.org; Thu, 17 Mar 2016 22:25:57 +0100 Original-Received: (qmail 16345 invoked by uid 550); 17 Mar 2016 21:25:55 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 16321 invoked from network); 17 Mar 2016 21:25:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=5pAwD++rPJWMYHKqtCuB+HGeT/oGcE9oEClkOGOfS2Y=; b=UpO4WCZaMRm8uEoJFOxzs26O8zYUTg/XObKG9C4o8E5F3LR656AS58aMkv3Eu/d/TE AYonKBVEfXcBvdM3Zmam7w1QPxA8l7Vqz7/Pdt+KFQ6nfBi6cFM3H7TL5Q4KATOAb5hY 4Mj7p68f3YxYYXW5GGBe95pn3dI4OYaQ9GjUE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=5pAwD++rPJWMYHKqtCuB+HGeT/oGcE9oEClkOGOfS2Y=; b=IYvKJqwhS7kbyZAZ3E4EZDyoXQFJ4j2cKkuS09ldLO86awgTbQBEXd7S82deuwCTaF 2KILVee6TxNDCeuffU9XHAqSRu/wasry6MxGZ1O8KciDlNDJxHD3JRJgcZZQK+qX2MXe 32DcNAkUoNzmrTTsFrh8YnVwsClwaZRFgaJPd3FN6yep1jvCspyvt5hYaqMubVmwVqo6 mAiq19c3GB9e6CNYSNFcWwJtq/XRI3EJjoEo/DK6t+sjkccec/4ss0i8NhCSuuR8prOK BayH9bK8w74SjXPPV6VCXxeB51qAeIHl9dJ4UuBwf5nQ62tD3Q19ZPQKUeG0cdI1NlSH XNhA== X-Gm-Message-State: AD7BkJLaJYjhz7qRV5OjoXYOeEz4NgR7cTI8ppI6L97eFLDkRXCnfu9Ue77xmFNVCof70N228ZJ6Gtf2HH6/FulY X-Received: by 10.140.217.202 with SMTP id n193mr18641977qhb.101.1458249941727; Thu, 17 Mar 2016 14:25:41 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:9663 Archived-At: --001a11373502c58a01052e4545b0 Content-Type: text/plain; charset=UTF-8 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 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 wrote: > > On Thu, Mar 17, 2016 at 02:49:55PM -0400, Ed Maste wrote: > >> On 16 March 2016 at 23:19, Rich Felker 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 > --001a11373502c58a01052e4545b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In Chromium and all related projects, which are licensed u= nder 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<= br> (https://andr= oid.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" BASI= S,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.<= br> * 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 impor= t
>> musl into our contrib/ tree and build it as a standalone entity th= e
>> current form (with no individual file statements) would be just fi= ne.
>>
>> 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 th= e
> 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 do= n'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 need= ing 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
--001a11373502c58a01052e4545b0--