linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Philippe Ombredanne <pombredanne@nexb.com>
To: Theodore Ts'o <tytso@mit.edu>, Joe Perches <joe@perches.com>,
	Philippe Ombredanne <pombredanne@nexb.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linuxfoundation.org>,
	Andrew Morton <akpm@linuxfoundation.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Christoph Hellwig <hch@lst.de>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	Rob Herring <rob.herring@linaro.org>,
	Jonas Oberg <jonas@fsfe.org>, xfs <linux-xfs@vger.kernel.org>,
	Charlemagne Lasse <charlemagnelasse@gmail.com>,
	Carmen Bianca Bakker <carmenbianca@fsfe.org>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>
Subject: Re: [patch V5 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses
Date: Fri, 29 Dec 2017 23:17:54 +0100	[thread overview]
Message-ID: <CAOFm3uHm5ye7VdbVYcu+a_-3paO7phazNSGzhRL3wzGFcx-MkQ@mail.gmail.com> (raw)
In-Reply-To: <20171229185404.GD11757@thunk.org>

On Fri, Dec 29, 2017 at 7:54 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Fri, Dec 29, 2017 at 08:19:59AM -0800, Joe Perches wrote:
>>
>> Has it been legally reviewed and accepted that removal
>> of the BSD license text from individual source files is
>> appropriate and meets the legal requirements of
>> following the BSD license on a per-file basis?
>>
>> And if so, who did this review?
>>
>> Is there any license that does not allow removal of the
>> license text and does not allow simple substitution of
>> the SPDX license identifier in each individual file?
>
> The work to use SPDX lines instead of individual licenses was done by
> Greg K-H in close consultation with Linux Foundation counsels, so I
> would assume that they did look at that particular issue.

This is correct. And this is in addition to the discussion in the SPDX
group  at the LF (that includes several FOSS-savvy and prominent FOSS
lawyers) that did design the SPDX spec.

> IANAL, but I've talked to lawyers about this issue, and in my
> experience if you talk to three lawyers you will easily get six
> opinions.

And that's on a good day: you may get more than six on a bad one. But
on the other hand, they tend also to defer to standards, and
established community norms.

> As far as I know, none of the licenses explicitly say
> copyright license must be on each file.  Just that the distribution of
> source must include the copyright and license statement.  Exactly how
> that is done is not explicitly specified.

This is also my take. What is done here is not much different than
refactoring duplicated code so it leaves in a single place:

- by "value" at the root in COPYING and in the Documentation.
- by "reference" in the code proper as SPDX ids.

Therefore essential and common requirements to include the license
text is fulfilled in the kernel.

Note that there are a few offenders that will need to clean up their
acts as they came up will both long and "un-removable and
un-alterable" crazy legalese blurbs [1] prefix this:

"DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER"

These will have to be taken care on a case by case basis. These are
pretty stupid and IMHO should have never been allowed to be added to
the kernel in the first place and are ugly warts. It could very well
be that these are not really GPL-compliant notices FWIW: keeping
notices and copyrights is quite different from a restriction of
altering things by moving them around which is exactly what is
happening with the SPDX-ification here.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/lustre/include/linux/libcfs/libcfs.h?h=v4.15-rc5#n5

-- 
Cordially
Philippe Ombredanne

  reply	other threads:[~2017-12-29 22:18 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-28 15:27 [patch V5 00/11] LICENSES: Add documentation and initial License files Thomas Gleixner
2017-12-28 15:27 ` [patch V5 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses Thomas Gleixner
2017-12-28 22:17   ` Thomas Gleixner
2017-12-29 13:21     ` Philippe Ombredanne
2017-12-29 16:19       ` Joe Perches
2017-12-29 18:54         ` Theodore Ts'o
2017-12-29 22:17           ` Philippe Ombredanne [this message]
2017-12-30  4:15             ` Theodore Ts'o
2018-01-02  2:35               ` Andreas Dilger
2017-12-30 11:02           ` Thomas Gleixner
2018-06-12 19:03     ` Yang Li
2018-06-12 19:27       ` Thomas Gleixner
2018-06-15 16:55         ` Yang Li
2018-01-02 20:24   ` Darrick J. Wong
2017-12-28 15:27 ` [patch V5 02/11] LICENSES: Add the GPL 2.0 license Thomas Gleixner
2017-12-29 13:24   ` Philippe Ombredanne
2018-01-04 16:25   ` Carmen Bianca Bakker
2018-01-04 20:50     ` Philippe Ombredanne
2017-12-28 15:27 ` [patch V5 03/11] LICENSES: Add the LGPL " Thomas Gleixner
2017-12-28 15:27 ` [patch V5 04/11] LICENSES: Add the LGPL-2.1 license Thomas Gleixner
2017-12-28 15:27 ` [patch V5 05/11] LICENSES: Add the BSD 2-clause "Simplified" license Thomas Gleixner
2017-12-28 15:27 ` [patch V5 06/11] LICENSES: Add the BSD 3-clause "New" or "Revised" License Thomas Gleixner
2017-12-28 15:27 ` [patch V5 07/11] LICENSES: Add the BSD-3-clause "Clear" license Thomas Gleixner
2017-12-28 15:27 ` [patch V5 08/11] LICENSES: Add the MIT license Thomas Gleixner
2017-12-28 15:27 ` [patch V5 09/11] LICENSES: Add Linux syscall note exception Thomas Gleixner
2017-12-28 15:27 ` [patch V5 10/11] LICENSES: Add the GPL 1.0 license Thomas Gleixner
2017-12-28 15:27 ` [patch V5 11/11] LICENSES: Add MPL-1.1 license Thomas Gleixner
2017-12-29 13:42 ` [patch V5 00/11] LICENSES: Add documentation and initial License files Philippe Ombredanne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOFm3uHm5ye7VdbVYcu+a_-3paO7phazNSGzhRL3wzGFcx-MkQ@mail.gmail.com \
    --to=pombredanne@nexb.com \
    --cc=akpm@linuxfoundation.org \
    --cc=carmenbianca@fsfe.org \
    --cc=charlemagnelasse@gmail.com \
    --cc=corbet@lwn.net \
    --cc=darrick.wong@oracle.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=heiko.carstens@de.ibm.com \
    --cc=joe@perches.com \
    --cc=jonas@fsfe.org \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=rob.herring@linaro.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linuxfoundation.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).