Linux-SPDX Archive on lore.kernel.org
 help / color / Atom feed
From: J Lovejoy <opensource@jilayne.com>
To: Richard Fontana <rfontana@redhat.com>
Cc: linux-spdx@vger.kernel.org
Subject: Re: some ideas on guidelines 
Date: Sun, 16 Jun 2019 22:44:48 -0600
Message-ID: <A296F1A4-C9B6-4031-9E1E-C78FF0B1DE6D@jilayne.com> (raw)
In-Reply-To: <CAC1cPGz1KWNfHgrZoQRkscmN-rU8yCS8wed1jR_VwniYJ13f4g@mail.gmail.com>

HI all,

John , Richard - thanks for the input. Sorry I haven’t had a chance to respond yet - may not have time until later this week, but didn’t want you to think I was ignoring you intentionally! (and am mulling over meaningful replies in the in between moments)

One quick clarification regarding my “abomination” comment - that is born out of my task of looking at the really messy files. You haven’t seen the patches for these yet, as it’s going to take a bit of un-winding to figure out the best route. But, yes, Richard, you are right, I should try to be a bit less emphatic ;) 

Thanks and be back soon,
Jilayne

> On Jun 14, 2019, at 8:25 AM, Richard Fontana <rfontana@redhat.com> 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 <opensource@jilayne.com> 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.
>> 
>> NOTES RELATED TO #1-3:
>> 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 https://www.gnu.org/licenses/gpl-howto.html which provides the standard license notice, but then also goes on to https://www.gnu.org/licenses/gpl-faq.en.html#LicenseCopyOnlysuggest one clear and explicit statement such as, “This program is released under license FOO”. FAQ questions and https://www.gnu.org/licenses/gpl-faq.en.html#NoticeInSourceFile also stress the general need for clarity without mandating use of the specific standard license notice.
>> [2] See https://www.gnu.org/licenses/identify-licenses-clearly.html
>> 
>> #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 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPYING, and refers to GPL-2.0-only. The (earlier) version of the COPYING file also had Linus expressing GPL-2.0-only: see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/COPYING?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
> 
> 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 http://13.57.134.254/app/submit_new_license/
>>                        -- 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.
> 
> Richard


  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 [this message]
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:
  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=A296F1A4-C9B6-4031-9E1E-C78FF0B1DE6D@jilayne.com \
    --to=opensource@jilayne.com \
    --cc=linux-spdx@vger.kernel.org \
    --cc=rfontana@redhat.com \
    /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

Linux-SPDX Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-spdx/0 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/ https://lore.kernel.org/linux-spdx \
		linux-spdx@vger.kernel.org
	public-inbox-index linux-spdx

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-spdx


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git