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

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

On Wed, Jun 8, 2022 at 1:24 PM Bradley M. Kuhn <bkuhn@ebb.org> wrote:
> > Without this external file, how is anyone to know without digging through
> > Git logs *whether* a warranty disclaimer used to be there or not?  …
> > Part of the reason we're struggling with this is that SPDX *should have*
> > provided identifiers for the items that GPLv2 allows to vary in
> > presentation and terms of the licenses!
>
Richard Fontana replied later that day:
> This is an interesting point. SPDX identifiers were I think originally
> meant to refer to license texts, not license notices, except for the
> "or-later" vs. "only" issue found in the GPL family.

Thanks, Fontana, you've stated the problem clearly and succinctly.  IOW (if
I'm following you correctly), the fundamental issue here is that linux-spdx
project is using license *text* monikers to replace license *notices*, but
GPLv2 permits variance in license *notices* that *are* legally significant.
(And, GPLv2 compliance requires keeping such notices in tact.)

 * * *

Meanwhile, if you at Red Hat were (at least at one time) encouraging a
legally different warranty disclaimer notice for employees to use upstream …

> To be a little clearer about why this bothers me a little bit. I know that
> in the past the FSF gave public guidance to companies that it was okay to
> tack on materially different warranty and liability disclaimer language to
> GPL notices (or, say, in global product license agreements). (GPLv3
> codifies this in its section 7.) Also, earlier in my time at Red Hat I went
> through a period where I was recommending to developers to include some
> disclaimer language that differed from what you have in the traditional GPL
> boilerplate. The point is that there are cases where the materially
> different language is deliberate and reflected the legal preferences of the
> contributor (or contributor's employer) in question

… then, odds are, other companies did (or even still do) as well.

   -- bkuhn