Linux-SPDX Archive on
 help / color / Atom feed
From: J Lovejoy <>
To: Richard Fontana <>
Subject: Re: some ideas on guidelines 
Date: Sun, 23 Jun 2019 19:08:16 -0600
Message-ID: <> (raw)
In-Reply-To: <>

and now my belated response to Richard’s comments as well :)


> On Jun 14, 2019, at 8:25 AM, Richard Fontana <> wrote:
> (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. :)

yeah! glad it’s helpful!

>> 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.

well, yeah, a stronger argument here would be helpful. I just thought that if we could get some explicit support from the FSF  that SPDX identifiers are just as fine to use as the standard header in the license appendix, then that would be one helpful point. Of course, the FSF is not the copyright holder of all GPL code, but they are influential.

At a more practical level, I was trying to think through how an action for non-compliance based on this would play out. Here’s some thoughts on that:
- the license notices are replaced with SPDX identifiers in a bunch of kernel files by various kernel maintainers and other copyright holders
- AcmeCo redistributes the kernel and is in FULL compliance with the kernel licenses
- NastyPlaintiff brings a license non-compliance action against AcmeCo based on the replacement of the license notices, claiming its a violation of the “keep intact” clause. First of all, how is Acme non-compliant - they kept every notice as they found it intact, Acme didn’t remove/replace anything. Then what?  I also would think that a judge wouldn’t be very pleased with such a frivolous suit.
- Now if AcmeCo was non-compliant with GPL in other ways (not providing source code, for example), then the “keep intact” argument is sort of a side show (and see previous point)

Now I’m not a litigator and I know we have a sort of people-can-sue-for-almost-anything, but you have to have a cause of action, and there usually has to be some harm. There’s certainly no harm in improving the state of the license notice. Full-on removing it would be a different scenario and I suspect that part of the license was written with the latter case in mind.

> 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.

hmmm… not familiar with this and not sure I’m following… but if you think that’s helpful, then would be good to understand better!

>> *  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.

And this is the challenge with trying to come up with guidelines… there’s too many, ‘well, it depends’ scenarios. But if I put that much detail into this guideline, then it probably wouldn’t be a guideline, but simply specific advice!  But for this one, maybe we need to look at the various examples and there may be a couple sub-guidelines here.

>> #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 it is messy, unclear, 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.

I revised the text above :)

>>                #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)

My assumption was the first set you mention + any significant subsequent contributors where such contributions is arguably copyright-able. I make that latter qualification (which is not easy, I know) because having looked at the Credit data for some of the files, there are times where one person wrote a file and then a bunch of people made really minor changes, I have a hard time thinking that one word changes or updating a reference equates to that person having copyright in that file. But, of course, there is no clear cut line on this.

> 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.

I had an inclination in this direction too, but I can’t really explain why. Can you provide a bit more of your thinking here?

>>                        —  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.
> Richard

  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
2019-06-17  4:44   ` J Lovejoy
2019-06-24  1:08   ` J Lovejoy [this message]
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