All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Bradley M. Kuhn" <bkuhn@ebb.org>
To: Thomas Gleixner <tglx@linutronix.de>,
	Richard Fontana <rfontana@redhat.com>,
	Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Subject: Re: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE
Date: Tue, 07 Jun 2022 11:12:18 -0700	[thread overview]
Message-ID: <87y1y8xrzx.fsf@ebb.org> (raw)
In-Reply-To: <87bkv55yxh.ffs@tglx> (Thomas Gleixner's message of "Mon, 06 Jun 2022 22:17:46 +0200")

On Mon, Jun 06 2022 at 16:11, Richard Fontana wrote:
> > I forget how we dealt with things like this in the initial large batch
> > some years ago but I remember raising the concern that some bespoke
> > license notices contained disclaimer language that was arguably
> > materially different in some way from what is found in GPLv2 itself.

Thomas Gleixner replied last night:
>>>> IIRC, there was no real conclusion aside of dealing with this later :)

A solution was found, and agreed to in Barcelona in April 2019, but then
wasn't implemented.  Then, you (Thomas) and Allison suggested a useful
alternative, but AFAIK that too was tabled.  That leaves most Linux
distributions out of compliance with GPLv2 in the meantime.  Details below:

 * * *

Fontana started a linux-spdx thread on 2019-05-19 with the subject line of
“Meta-question on GPL compliance of this activity”, saying:
>> I was at the LLW event in Barcelona last month but unfortunately did not
>> attend the workshop relating to this activity …
>> GPLv2 section 1 says: "… keep intact all the notices that refer to this
>> License and to the absence of any warranty; and give any other recipients
>> of the Program a copy of this License along with the Program."… 

>> I have recently heard the argument that replacing a more or less standard
>> old-school GNU license notice … with an SPDX license identifier string,
>> without explicit permission from the copyright holder, complies with this
>> condition …  However, more conservative interpreters of GPLv2, including
>> some copyright holders, might argue otherwise.

>> The discovery of GPL notices juxtaposed with warranty disclaimers
>> imported from non-GPL licenses, or warranty disclaimers that otherwise go
>> beyond what is called out in GPLv2 and the traditional GNU license
>> notice, also raises the question of whether this list's work is strictly
>> compliant with the quoted language from GPLv2 section 1.

On 2019-05-21, I replied summarizing the decision from the 2019-04 meeting:
> There was consensus at the meeting in Barcelona that moving all the notices
> to a single file to live inside the Linux tree "somewhere" with entries
> like:
>    Filenames: a.c, b.c, c.c contained this notice:
>             NOTICE
>       which was replaced with SPDX_IDENTIFIER on DATE.
> and that such was a fine and acceptable way to address even the most
> disagreeable and litigious conservative interpreters, and that such was a
> necessary step to avoid compliance infractions on this issue.

Note that was a full consensus — and it included the opinion of many
prominent FOSS lawyers (who were attending under the Chatham House Rule
imposed on that meeting) — that keeping the notices intact somewhere in the
tree (not just in the Git repository) was essential.

Greg KH was the only objector to the solution, replying on 2019-05-22:
>>> So that's just not going to be possible … 
>>> Just use git history, we have it, why ignore it?

Given that linux-spdx now uses that approach (i.e., the Git history is the
only place that these notices can be found), under GPLv2§1, it now means
that all downstream redistributors of Linux must include the entire Git
repository as part of the complete, corresponding source (CCS).  That seems
like it is actually more inconvenient to more people than writing the tool
to generate the notice file (see below).

In response to Greg's concerns, Thomas made this excellent suggestion:
>>>> That's what tools are for. We can generate that list when generating the
>>>> tarball.. 
(… and Allison Randal endorsed this idea in on 2019-05-24)

The thread continued on, with Greg raising concerns that putting the notices
in the release tarball would still be difficult, and Thomas and Allison made
a counter-proposal that the list of notices (as described above) could go on
a stable kernel.org URL for each release, and that just the URL is noted as
the place to find full notices in the tarball itself.

*But*, until (a) that tool exists to auto-generate the notices, and (b) the
tarballs contain that URL in them, the Git repository as a whole *is now
required* as part of the CCS for Linux per GPLv2§1.

Fontana followed up later in the 2019 thread, (after work began) to say:
>> I believe this group needs to address [this notice issue] head-on and
>> openly, …  The fact that I'm participating in these reviews should not be
>> taken to mean that I am 100% comfortable with this activity. Part of why
>> I'm doing so is to identify problems that might otherwise get overlooked.

I'm glad Fontana is doing the latter, and that he brought up this issue
again now.  As can be seen from the list archives and Git history, neither I
nor anyone from Software Freedom Conservancy has signed-off any linux-spdx
patches.  We can't in good conscience sign-off on patches that currently
cause *more* GPLv2 violations (even if they are minor infractions).  This
problem needs attention for linux-spdx to achieve its goals.


    -- bkuhn

  reply	other threads:[~2022-06-07 19:34 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-06 19:58 [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE Thomas Gleixner
2019-05-21 17:58 ` Meta-question on GPL compliance of this activity Richard Fontana
2019-05-21 18:59   ` J Lovejoy
2019-05-21 21:08   ` Bradley M. Kuhn
2019-05-22  9:40     ` Thomas Gleixner
2019-05-22 13:30     ` Greg KH
2019-05-23  4:41       ` Bradley M. Kuhn
2019-05-23  5:42         ` Thomas Gleixner
2019-05-22 16:14     ` J Lovejoy
2019-05-22 21:10       ` John Sullivan
2019-05-23  1:19         ` J Lovejoy
2019-05-23  6:06           ` Thomas Gleixner
2019-05-29 20:57           ` John Sullivan
2019-05-29 21:30             ` Greg KH
2019-06-01  3:22               ` John Sullivan
2019-06-01  9:31                 ` Greg KH
2019-06-01  4:21               ` Richard Fontana
2019-05-24  4:33       ` Richard Fontana
2019-05-24  5:20         ` Greg KH
2019-05-24 20:24           ` Allison Randal
2019-05-25  1:07             ` Richard Fontana
2019-05-27 21:23               ` Allison Randal
2019-05-25 16:56             ` Greg KH
2019-05-27 21:54               ` Allison Randal
2019-05-28  7:21                 ` Dominik Brodowski
2019-05-22 13:27   ` Greg KH
2019-05-22 14:16     ` Thomas Gleixner
2019-05-22 16:33       ` J Lovejoy
2019-05-22 16:52         ` Thomas Gleixner
2019-05-22 17:00           ` J Lovejoy
2022-06-06 20:11 ` [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE Richard Fontana
2022-06-06 20:17   ` Thomas Gleixner
2022-06-07 18:12     ` Bradley M. Kuhn [this message]
2022-06-07 23:05       ` Thomas Gleixner
2022-06-08  8:33         ` Allison Randal
2022-06-08 14:04           ` Bradley M. Kuhn
2022-06-08 14:59             ` Allison Randal
2022-06-08 17:18               ` Bradley M. Kuhn
2022-06-08 18:54                 ` Richard Fontana
2022-06-08 19:29                   ` Bradley M. Kuhn
     [not found]                     ` <02f4021f-63a5-4796-d790-2bacd37b90d2@jilayne.com>
2022-06-09  0:31                       ` Bradley M. Kuhn
2022-06-09  4:51                         ` J Lovejoy
2022-06-09 15:03                           ` Bradley M. Kuhn
2022-06-09  2:35                       ` Richard Fontana
2022-06-06 20:31   ` Bradley M. Kuhn

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=87y1y8xrzx.fsf@ebb.org \
    --to=bkuhn@ebb.org \
    --cc=allison@lohutok.net \
    --cc=linux-spdx@vger.kernel.org \
    --cc=rfontana@redhat.com \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.