Re: [Batch 1 - patch 12/25] treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_208.RULE

["Bradley M. Kuhn" <bkuhn@ebb.org>]

Thomas Gleixner wrote:
> 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.

Obviously they should fund the tool to make the proper notice file.  If you
want to introduce me and Fontana to the corporate lawyers asking why
linux-spdx is stalled, while I can't speak for Fontana, I think he'd be glad
to join me in talking to them about what needs to be funded to make the
replacement legally acceptable.

> I'm pretty confident that some of those lawyers were part of the full
> consensus you mentioned.

Note that it wasn't just lawyers at that meeting, and also, many of the
people there represented well-funded pro-SPDX budgets.

(As a side note, this is a good example of why CHR-governed meetings are a
bad place to make decisions.  It removes all accountability from those who
had input into the decision.)

> U-Boot did a wholesale SPDX conversion back in 2013 which removed every
> boilerplate including non-standard disclaimers and obscure license
> notices/references.

Another project making a questionable decision doesn't provide useful
evidence for Linux to make the same questionable decision.

> How is the industry dealing with that?
>    1) Not having noticed within 9 years?
>    2) Simply ignoring the problem?
>    3) Shipping the git repository?

When a compliance matter comes up — and it will — demanding (3) will be the
outcome.  I suspect the U-Boot project is probably ok with that.

> 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.

I understand.  The lawyers (and their wealthy allies) who want SPDX
identifiers in every file *should* be funding the tool that's needed for GPL
compliance (lest they face a situation where the Git repositories become part
of the CCS — but *maybe* they actually want that?).  Meanwhile, it's
definitely ironic that an effort like this (to ostensibly make license
compliance easier) is introducing license violations.

Allison Randal also replied:
>> With that context in mind: One reasonable interpretation of “keep intact
>> all the notices that refer to this License and to the absence of any
>> warranty” could be to say that the exact text must be preserved, exactly
>> as it was typed at the dawn of time, including any typos, inaccurate
>> street addresses, etc.

Just to be clear: the concerns Fontana raised weren't about preserving typos
or inaccurate street addresses.  Thus, I think that point is probably a red
herring here.  No one has said that preserving typos or inaccurate postal
addresses is important.

>> Another reasonable interpretation is that the notices serve to link a
>> license to the file, and declare that the legal terms of the entire GPL
>> license govern that file, and so what must be preserved is the link.

I think a link to the proper notice (as it originally appeared) was a good
proposal back in 2019 and just as good now.  We had consensus that it was a
way to go.  It was your idea, Allison, and I think it was useful and solves
the problem.

>> Current practice is closer to the second, people feel free to throw in
>> whatever garbled variant of the notice text FSF recommends,

If folks have changed the warranty disclaimer in a legally significant way —
which Fontana already noted is happening here — then it absolutely matters.

>> If the full text notice and SPDX identifier are legally equivalent, then
>> can they legally be substituted in an existing file?

I realize that many people *want* the "if" part of that statement to be true.
No one actually knows if it is true.  The fact that the SPDX project (which
has an obvious self-promotional interest here), declared it to be true
doesn't make it true, either.

>> When Thomas and I say that the changes are all in git history, we aren't
>> saying that we expect everyone to read the entire history. What we're
>> saying is that it's easy to write a tool to scan the entire history,

This part does concern me.  Are these patches going upstream in a way that
they can easily be found?  Is it easy to extract the specific notice that was
removed programatically?  At the very least, linux-spdx should make sure
that's true.

In the meantime, there is no actual harm, from my point of view, that the Git
repository is now part of the CCS for Linux.  In some ways, that's an upside
outcome from *my* perspective.   But, I realize that company's legal
departments might not fully understand that's a side-effect of the current
effort.

Indeed, I think *many* people will find that a surprising outcome, and it
will lead to more (infractional) violations.

  -- bkuhn