Linux-SPDX Archive on
 help / color / Atom feed
From: Richard Fontana <>
To: J Lovejoy <>
Subject: Re: some ideas on guidelines
Date: Fri, 14 Jun 2019 10:25:50 -0400
Message-ID: <> (raw)
In-Reply-To: <>

(Hoping I am responding in a way that conforms sufficiently to
Jilayne's as well as Greg K-H's expectations :)

On Wed, Jun 12, 2019 at 1:25 AM J Lovejoy <> wrote:
> Hi all,
> Sorry to be a bit MIA, been busy with some other things, but still watching the progress here.
> I have been thinking a lot about some of the patterns discussed here and various issues logged for “further review".  I was trying to come up with some guidelines of what to do in various situations. Part of my reason for thinking through this was to address some of the issues raised here, but also to log some guidelines to ensure consistency.

This is exactly the sort of writeup I was hoping someone would produce
in connection with this effort, so I am pleased to see it. :)

> GUIDANCE: The following is meant to provide some high-level guidance for how to handle common scenarios and triage the approaches to reach the stated goal.
> The following is not intended to be legal advice. Rather, it is meant to reflect the intention of the participating individuals to improve the quality and machine-readability of the applicable license information in Linux kernel files. The approach described below has been developed with the Linux kernel in mind and might not be appropriate for other projects or communities.
> #1   Where a file contains the standard license notice as stated in the GPL-2.0 license text for GPL-2.0-only or GPL-2.0-or-later and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
> #2   Where a file contains a non-substantive variation on the standard GPL-2.0 license notice, but still provides clear distinction as to GPL-2.0-only or GPL-or-later consistent with the intent of the standard license notice and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
> #3   Where a file contains a license notice that is non-standard as compared to that stated in the GPL-2.0 license text but is nonetheless clear as to GPL-2.0-only or GPL-2.0-or-later and no other license information whatsoever —> then REPLACE the standard license notice with the SPDX identifier for the relevant license.
> The SPDX identifier is simply a more concise way to express the same intention regarding what license applies to the file as the standard license notice, but does so in a reliably, machine-readable way that meets the needs of modern software supply chain use and efforts to automate detection of license information in order to facilitate more complete license information and license compliance. One consideration is whether replacing existing license notices with more concise, machine-readable expression of the same information could run afoul of a strict reading of GPL-2.0, section 1.
> Such a strict reading applied to the scenarios described in #1-3 is unconvincing for the following reasons:
> *  Although the license text itself recommends the use of the standard license notice, it is not a hard requirement of the license. The definitive text, as always, is the full text of the license itself. Notably, the license author/steward, the Free Software Foundation (FSF), encourages use of the standard header, but more broadly recommends clear communication of the license variant chosen for the given work as seen in various pages on their site.[1] Furthermore, Richard Stallman endorsed the use of the revised SPDX identifiers for helping provide clarity as to whether a licensor has chosen the license-version-only or any-later-version option.[2]

I don't find this convincing enough as to the basic GPL compliance
objection here, which should not be lost sight of. GPLv2 says:

"You may copy and distribute verbatim copies of the Program's source
code as you receive it, in any medium, provided that you conspicuously
and appropriately publish on each copy an appropriate copyright notice
and disclaimer of warranty; keep intact all the notices that refer to
this License and to the absence of any warranty . . . . "

The license seems to have a "hard requirement" that existing license
notices be "kept intact". So I think a stronger response to this
objection needs to be developed (and the approach this group takes
towards recommending removal or alteration of legal notices should be
influenced by consideration of the "keep intact" requirement of
GPLv2). One thing that just occurred to me is that the nominal
requirement to "conspicuously and appropriately publish on each copy
an appropriate copyright notice and disclaimer of warranty", which I
believe does not give rise to an affirmative obligation to do
*anything* (despite what it seems to say), may nonetheless add
legitimacy to the selective removal or alteration of source file
license notices and warranty disclaimers.

You could also consider mentioning the precedent set by BusyBox in
~2006, though I'm not sure how well documented this is. Bruce Perens
argued, IIRC, that BusyBox could not change GPLv2-or-later notices to
GPLv2-only, citing the "keep intact" requirement (effectively arguing
that a project with conventional license notices could never
distribute GPLv2-or-later code as GPLv2-only), but I believe the FSF
agreed with the position of the BusyBox maintainers at that time, and
a hint of this resolution crept into GPLv3. It just supports the idea
that the "keep intact" requirement shouldn't be read ultra-literally.

> *  This project to improve license information in the Linux kernel files has been discussed among kernel developers, on kernel mailing lists, and documented in public files and documentation beginning in mid-20173 to which many kernel copyright holders past and present have access and would be likely to see and which has received positive response and encouragement.
> [1] See which provides the standard license notice, but then also goes on to one clear and explicit statement such as, “This program is released under license FOO”. FAQ questions and also stress the general need for clarity without mandating use of the specific standard license notice.
> [2] See
> #4   Where the file contains a license notice that clearly states the file is licensed under “GPL” with no indication of version number and no other license information whatsoever —> ADD SPDX identifier for GPL-2.0-or-later
>     Rationale: This is consistent with the text of the license which states, “If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.” Because the Linux kernel is well-known to be licensed under GPL-2.0-only and use of GPL-1.0 is generally sparse, it within the options given in the license text to choose GPL-2.0-or-later in this case. Doing so more easily enables use of such files beyond the Linux kernel.
> #5   Where the file contains a license notice that: a) refers to the COPYING file or another specific file (or references GPL and the COPYING or another specific file) with no other information as to the specific license whatsoever; and b) the COPYING or other specific file can be located and is clearly a copy of GPL-2.0  —> ADD SPDX identifier for GPL-2.0-only
>     Rationale: This is similar to #4, but the combination of a clear reference to a specific license file and the fact that the Linux kernel is clearly intended to be GPL-2.0-only leads to the intent that this is also GPL-2.0-only. The COPYING file currently in the kernel is at, and refers to GPL-2.0-only. The (earlier) version of the COPYING file also had Linus expressing GPL-2.0-only: see

I'm not sure I agree with this, but one could argue it's not super-important.

I've taken issue with a few cases I've seen where the consensus of
this group is that "GPL-2.0-only" accurately describes the intent of a
license notice that references a copy of GPLv2 outside the context of
the kernel source code. In the notices I'm thinking of, the reference
to the GPLv2 text is sufficiently decoupled from a version-neutral or
version-ambiguous statement about the applicable license that I
believe an "or-later" permission is justifiably read into the notice.

> #6   Where a file contains a license notice that is non-standard as compared to that stated in the GPL-2.0 license text but in nonetheless clear as to GPL-2.0-only or GPL-2.0-or-later and there is other license information, and that license information contains the following:
>                 #6a  An existing known additional license or exception for which there is an SPDX identifier
>                          —> ADD appropriate SPDX license expression (use of AND, OR, WITH), where person making change is does not represent copyright holders for file
>                          —> REPLACE with appropriate SPDX license expression, where person(s) making or signing-off on changes represent copyright holders
>                 #6b   An additional license or exception for which there is no SPDX identifier as per the existing SPDX License List Matching Guidelines:
>                         --  If clearly a different license and use is more than one or two files, then submit for addition to SPDX License List at
>                         -- If close to an existing license/exception on the SPDX License List such that the SPDX license’s matching markup might be extended to accommodate as a match, submit to SPDX legal team for review of such.
>                         -- If some mess of a license that is unclear, an abomination, contains non-free elements, or otherwise poses some kind of challenge, then attempt to contact copyright holders to change license with recommendation

I found the use of "mess of a license" and "abomination" a little
unnecessarily disturbing there, and it called to my mind Thomas's
strong emotional reaction to the old Red Hat "GPL'd" license notices.
:) I think this guidance should try to be dispassionate.

>                 #6c   An additional or different disclaimer or warranty text:
>                         — Where the copyright holders of the file in questions can be contacted, then ask them to remove this and use the appropriate SPDX identifier for GPL

Who are the "copyright holders" though? This could mean:
* The nominal copyright holders (in copyright notices juxaposed with
the license/disclaimer notices)
* The set of all discernible contributors to the file following the
inclusion of the legal notice at issue, including those not reflected
explicitly in copyright notices in the file (and/or their employers at
the time which in most cases would have had ownership interest in
copyright on those contributions from those authors)

I believe a good case could be made that the only copyright holders
you should have to contact are the ones in the first category, but
this may be controversial. In any case I think it ought to be
addressed in these guidelines.

>                         —  Where copyright holders of the file in question cannot be easily contacted or found, then analyze differences between additional disclaimer text and standard disclaimer included in GPL, then:
>                                 —> if additional disclaimer text adds no additional substantive aspects to the standard GPL disclaimer, REPLACE with appropriate SPDX license identifier for GPL-2.0
>                                 —> If additional disclaimer text adds additional substantive aspects to the standard GPL disclaimer, ADD the appropriate SPDX license identifier for GPL-2.0

So I agree with this at a high level, but we've seen that this is
potentially challenging in practice (or at least I think so), because
what "additional substantive aspects" are requires (in part) some
degree of legal analysis, or at least one could argue that. For a
simple example, is the addition of "as-is" substantive? Allison argues
no because "as-is" is used in the GPLv2 text itself. I am not so sure.
I have changed my view of this a couple of times. And again let's not
forget the compliance issue here: GPLv2 says you have to keep intact
all notices that refer to the absence of warranty.


  parent reply index

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-12  5:25 J Lovejoy
2019-06-12 10:26 ` Philippe Ombredanne
2019-06-24  0:57   ` J Lovejoy
2019-06-12 16:04 ` John Sullivan
2019-06-24  1:01   ` J Lovejoy
2019-06-13 17:44 ` Richard Fontana
2019-06-14 14:25 ` Richard Fontana [this message]
2019-06-17  4:44   ` J Lovejoy
2019-06-24  1:08   ` J Lovejoy
2019-08-17 19:55 ` J Lovejoy
2019-08-18  5:08   ` Greg KH
2019-08-18 22:08     ` Richard Fontana
2019-08-19  4:30       ` Christoph Hellwig
2019-08-19  5:06       ` Greg KH

Reply instructions:

You may reply publically 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:

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

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-SPDX Archive on

Archives are clonable:
	git clone --mirror linux-spdx/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-spdx linux-spdx/ \
	public-inbox-index linux-spdx

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone