All of lore.kernel.org
 help / color / mirror / Atom feed
From: Allison Randal <allison@lohutok.net>
To: "Bradley M. Kuhn" <bkuhn@ebb.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Richard Fontana <rfontana@redhat.com>,
	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 10:59:18 -0400	[thread overview]
Message-ID: <a9429d78-db06-7754-1d19-8c87b430bfcd@lohutok.net> (raw)
In-Reply-To: <YqCsfqgO07BITgfU@ebb.org>

On 6/8/22 10:04, Bradley M. Kuhn wrote:
> 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.

I'm making an explicit point that the exact text of the notice isn't 
actually all that useful. Those aren't red herrings, they're just 
specific examples where the exact text is actively unhelpful. To the 
extent that the exact text of the notice is a jumbled but equivalent 
paraphrase of the terms of the GPL it isn't actively unhelpful, but it 
also doesn't add any legal or informational value, does add confusion 
around the licensing, and means that every individual who encounters the 
file has to carefully check to make sure that the text doesn't deviate 
from the terms of the GPL. (Many of those people don't know the GPL as 
well as Fontanta, and won't actually make that judgement accurately.)

Where the exact text of the notice does deviate from the terms of the 
GPL, that's a different problem, and we aren't changing those files for now.

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

As you probably know, I've been negotiating compromises with lawyers 
around free software for decades, and I'm very good at it. That doesn't 
necessarily mean I believe the compromise is the best answer, only that 
it's the best I'm able to achieve at the time. Progress takes time, and 
I accept that. (I've negotiated a series of compromises with lawyers 
around contributor agreements over the decades down from "every 
contributor", to "only the most significant/prolific contributors", to 
"only corporate contributors", to "actually DCO and signed-off-by is fine".)

If an automatically generated file (outside of git) recording the 
historical full notice text for each changed file is as far as I can get 
the lawyers to agree at the moment, I accept that as good progress in 
the right direction.

But, in the long term, I predict that common legal practice will evolve 
to recognize that SPDX identifiers are legally equivalent to full text 
notices (as long as those full text notices don't deviate from the terms 
of the license). You can actively work toward that future or actively 
work against it, it really doesn't matter to me. Time will tell, and no 
one person will make that decision, it will be made for us by the 
collective actions of a massive number of people.

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

Publishing a legal text like the GPL doesn't make it true either. At 
some point we put a legal stake in the ground on what *should be* true 
for free software, and then take action over time to defend and prove it 
to be true. That's how the law works and evolves over time.

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

Scan all historical commits since we started this clean up project for 
the ones that add SPDX identifiers (that's an easy machine pattern to 
match), and check if those patches also deleted any lines. Thomas has 
also been good about noting the exact rule that was applied in the 
commit message, so that gives us even more metadata for the generated 
output of the tool.

Allison

  reply	other threads:[~2022-06-08 15:10 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 [this message]
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
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=a9429d78-db06-7754-1d19-8c87b430bfcd@lohutok.net \
    --to=allison@lohutok.net \
    --cc=bkuhn@ebb.org \
    --cc=linux-spdx@vger.kernel.org \
    --cc=rfontana@redhat.com \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.