From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, NORMAL_HTTP_TO_IP,NUMERIC_HTTP_ADDR,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AC9FBC43613 for ; Mon, 24 Jun 2019 01:40:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 27CFD22CEB for ; Mon, 24 Jun 2019 01:40:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=jilayne.com header.i=@jilayne.com header.b="Fq+IY7P/" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726312AbfFXBkq (ORCPT ); Sun, 23 Jun 2019 21:40:46 -0400 Received: from mx1-c1.supremebox.com ([198.23.53.215]:40775 "EHLO mx1.supremebox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726304AbfFXBkq (ORCPT ); Sun, 23 Jun 2019 21:40:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=jilayne.com ; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=KOGsA01O5TcutxQ5hb6P98bPtH7EkELq1YPLXDBV1Jk=; b=Fq+IY7P/R6tGwbLs1teYyebSUh TB4hiFEjC2CfGLqJ+0KZ6ji8oxOfZt/irWqPiVCtWPx1x4E/re+QZ/Nza3T4raYL5qFSVlzZgEX91 nU1rDWbHU3DiUtsBqKcSirFJcXS0iidl0P5kyYcPKt70as+ussTfyK3kTuq0AJqI1aNQ=; Received: from [166.137.104.218] (helo=[172.20.10.4]) by mx1.supremebox.com with esmtpa (Exim 4.89) (envelope-from ) id 1hfDT1-0000Kh-NV; Mon, 24 Jun 2019 01:08:21 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: some ideas on guidelines From: J Lovejoy In-Reply-To: Date: Sun, 23 Jun 2019 19:08:16 -0600 Cc: linux-spdx@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <9F486ED2-70CB-402C-BA63-429D24E111BD@jilayne.com> References: To: Richard Fontana X-Mailer: Apple Mail (2.3445.104.11) X-Sender-Ident-agJab5osgicCis: opensource@jilayne.com Sender: linux-spdx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spdx@vger.kernel.org and now my belated response to Richard=E2=80=99s comments as well :) Thanks, Jilayne > On Jun 14, 2019, at 8:25 AM, Richard Fontana = wrote: >=20 > (Hoping I am responding in a way that conforms sufficiently to > Jilayne's as well as Greg K-H's expectations :) >=20 > On Wed, Jun 12, 2019 at 1:25 AM J Lovejoy = wrote: >>=20 >> Hi all, >>=20 >> Sorry to be a bit MIA, been busy with some other things, but still = watching the progress here. >>=20 >> I have been thinking a lot about some of the patterns discussed here = and various issues logged for =E2=80=9Cfurther 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. >=20 > 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=E2=80=99s helpful! >=20 >=20 >> 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. >>=20 >> 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. >>=20 >> #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 =E2=80=94> then REPLACE the = standard license notice with the SPDX identifier for the relevant = license. >>=20 >> #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 =E2=80= =94> then REPLACE the standard license notice with the SPDX identifier = for the relevant license. >>=20 >> #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 =E2=80=94> then REPLACE the standard license = notice with the SPDX identifier for the relevant license. >>=20 >> 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. >>=20 >> 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] >=20 > I don't find this convincing enough as to the basic GPL compliance > objection here, which should not be lost sight of. GPLv2 says: >=20 > "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 . . . . " >=20 > 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=E2=80=99s 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 =E2=80=9Ckeep intact=E2=80=9D clause. First of all, how = is Acme non-compliant - they kept every notice as they found it intact, = Acme didn=E2=80=99t remove/replace anything. Then what? I also would = think that a judge wouldn=E2=80=99t 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 =E2=80=9Ckeep intact=E2=80=9D = argument is sort of a side show (and see previous point) Now I=E2=80=99m 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=E2=80=99s 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. >=20 > 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=E2=80=A6 not familiar with this and not sure I=E2=80=99m = following=E2=80=A6 but if you think that=E2=80=99s helpful, then would = be good to understand better! >=20 >> * 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. >>=20 >> [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, =E2=80=9CThis program is released = under license FOO=E2=80=9D. 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 >>=20 >> #4 Where the file contains a license notice that clearly states the = file is licensed under =E2=80=9CGPL=E2=80=9D with no indication of = version number and no other license information whatsoever =E2=80=94> = ADD SPDX identifier for GPL-2.0-or-later >> Rationale: This is consistent with the text of the license which = states, =E2=80=9CIf the Program does not specify a version number of = this License, you may choose any version ever published by the Free = Software Foundation.=E2=80=9D 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. >>=20 >> #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 =E2=80=94> 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/CO= PYING, 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=3D1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 >=20 > I'm not sure I agree with this, but one could argue it's not = super-important. >=20 > 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=E2=80=A6 = there=E2=80=99s too many, =E2=80=98well, it depends=E2=80=99 scenarios. = But if I put that much detail into this guideline, then it probably = wouldn=E2=80=99t 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. >=20 >> #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: >>=20 >> #6a An existing known additional license or exception = for which there is an SPDX identifier >> =E2=80=94> ADD appropriate SPDX license = expression (use of AND, OR, WITH), where person making change is does = not represent copyright holders for file >> =E2=80=94> REPLACE with appropriate SPDX = license expression, where person(s) making or signing-off on changes = represent copyright holders >>=20 >> #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=E2=80=99s 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 >=20 > 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 :) >=20 >> #6c An additional or different disclaimer or = warranty text: >> =E2=80=94 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 >=20 > 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. >=20 > 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=E2=80=99t really = explain why. Can you provide a bit more of your thinking here? >=20 >> =E2=80=94 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: >> =E2=80=94> if additional disclaimer = text adds no additional substantive aspects to the standard GPL = disclaimer, REPLACE with appropriate SPDX license identifier for GPL-2.0 >> =E2=80=94> If additional disclaimer = text adds additional substantive aspects to the standard GPL disclaimer, = ADD the appropriate SPDX license identifier for GPL-2.0 >=20 > 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. >=20 > Richard