Bradley,
On Tue, Jun 07 2022 at 11:12, Bradley M. Kuhn wrote:
> 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.
What we have done so far is:
1) Add SPDX license identifiers to files which have no license
reference/notice/... at all
2) Replace bog standard boilerplates
Quite some of these replacements have been reviewed by Richard as
documented in the changelogs and the mailing list archive.
So far I haven't seen any complaint from more conservative
interpreters or from copyrights holders which disagreed with that
approach and requested any of those changes to be reverted.
All I have seen so far is handwaving worryguts.
We did _not_ remove/replace any of the oddball GPLv2 plus magic
disclaimer parts or any other non-standard license boilerplate yet.
The fact that I resent some of those match patterns now does not change
that. The whole purpose of this exercise is to have enough eyeballs on
these patches to catch those cases, sort them out and decide how to deal
with them.
> 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.
Note that the full consensus of all these prominent lawyers becomes only
useful when they agree on something pragmatic which is actually
resolving the situation. Having full consensus on unactionable solutions
is a pointless exercise.
There was also full consensus many years before 2019 that the licensing
situation has to be cleaned up along with the conclusion that this needs
to be done with the help of those companies and their respective lawyers
who inflicted the mess in the first place. This has been discussed and
concluded to death with no outcome.
I surely can count the number of lawyers who actually helped with this
effort on _one_ hand. The number of corporate developers who were
involved in cleaning this up is not impressive either.
I've got promised access to a full audited license database for the
kernel way before 2019 from the very same crowd attending the legal
workshop in Barcelona. That still has not materialized as of today.
What I've got are a couple of private mails from corporate lawyers
asking why the SPDX efforts have been stalled since summer 2019. When I
told them that I ran out of copious spare time they never answered back.
I'm pretty confident that some of those lawyers were part of the full
consensus you mentioned.
> 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?
Greg was not the only objector. There was no need to repeat the obvious
and the resulting discussion clearly showed that.
> 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).
That's not a problem the Linux kernel introduced.
U-Boot did a wholesale SPDX conversion back in 2013 which removed every
boilerplate including non-standard disclaimers and obscure license
notices/references.
As a matter of fact, none of these changes in the U-Boot tree has been
reverted or challenged since 2013.
How is the industry dealing with that?
1) Not having noticed within 9 years?
2) Simply ignoring the problem?
3) Shipping the git repository?
4) Using the magic tool which nobody is willing to write?
Whatever the answer is, it's going to be very conclusive and I'm really
looking forward to it.
> 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.
We all discussed options for solving this, but that does not mean that
the task to create such a tool has been assigned to anyone or that
anyone volunteered to take it on.
There was plenty of time for all involved parties, especially those who
are complaining most to sit down themself or pay someone to get it done.
> 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.
What's the point? Richards objections were expected.
As I said above: This is the purpose of this list. I'm just providing
coarse filtered data to analyse. If problems are detected and pointed
out the changes are put aside and have to be dealt with seperately.
We've been very consistent with this since this effort started as can
be seen from the list archives and git history.
> 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.
Duly noted.
Thanks,
tglx
