From: "Bradley M. Kuhn" <bkuhn@ebb.org>
To: 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: Wed, 8 Jun 2022 17:31:36 -0700 [thread overview]
Message-ID: <YqE/aNK+YXH1Bs5n@ebb.org> (raw)
In-Reply-To: <02f4021f-63a5-4796-d790-2bacd37b90d2@jilayne.com>
J Lovejoy wrote today:
> a second question of: and then how does "capturing it in some way" get
> practically implemented?)
> We are NOT answering the second question at this point in time.
Nor did I expect you to have an answer for that question this quickly! (But,
hopefully we agree it's a really important question!)
I think Fontana and I just for the first time stated clearly the root cause —
namely: the inability for SPDX identifiers to capture non-standard
disclaimers. (I suspect this is something that no one noticed when this
issue was debated previously [0].)
Nevertheless, the flaw is big enough that it calls into question whether one
*can* effectively use SPDX identifiers *alone* to mark licensing information
for anything other than a brand-new project that has no license notices yet.
> SPDX makes clear that if there is a standard license notice (which GPL is one
> of the few license that has one), then the matching guidelines apply there too.
> That is not really helpful here, though, where we are talking about
> non-standard license notices.
Indeed — not only that, but if, as you say, the presentation of an SPDX
identifier at the top of a copyrighted work always means “the license with
its standard and recommended permission notice as recommended by the license
steward”, then *any* replacement of a notice that deviates in any way (even
trivially) from the standard is pretty clearly an infraction of the “keep
notices in tact” requirement of GPLv2§1.
> #1 QUESTION: How much deviation from the language in the text of the
> standard header for GPL rises to the level of being legally significant to
> warrant capturing it in some way?
If anyone but the copyright holder and/or original placer of the warranty
disclaimer makes this determination, there is increased risk of McHardy-style
lawsuit. So, while I agree with your other point that it's a risk
assessment, the stakes are presumably rather high here.
OTOH, if everyone is cool with the idea of the Git repository being part of
the CCS, I think that's a fine solution from my perspective.
-- bkuhn
[0] Historically, as John Sullivan pointed out in the 2019 thread on this
list, the SPDX project (from its inception until recently) discouraged
replacing license notices with SPDX identifiers. (As some on this list
know, the SPDX project changed its position to be silent on that topic
recently.) Here's the context from this list on that:
John Sullivan <johns@fsf.org> wrote on Wed, 22 May 2019:
>> On https://spdx.org/ids-how it currently says:
[ Which can be confirmed with
https://web.archive.org/web/20191019153514/https://spdx.org/ids-how ]
>>>> [W]hen a file already contains a standard header or other license
>>>> notice, the SPDX project recommends that those existing notices
>>>> *should not* be removed. The SPDX ID is recommended to be used to
>>>> supplement, not replace, existing notices in files. …
>>>> [E]xisting license texts and notices should be retained, not
>>>> replaced ‐ especially a third party's license notices.
That text has since been removed from the URL in question. IIUC SPDX has
no recommendation on how to solve the problem we have at hand, which is
certainly consistent with their position, since SPDX now officially stays
neutral on the question of whether one should or should not replace
existing license notices with merely SPDX identifiers.
next prev parent reply other threads:[~2022-06-09 0:32 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
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 [this message]
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=YqE/aNK+YXH1Bs5n@ebb.org \
--to=bkuhn@ebb.org \
--cc=linux-spdx@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).