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
