linux-spdx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Allison Randal <allison@lohutok.net>
To: Thomas Gleixner <tglx@linutronix.de>,
	"Bradley M. Kuhn" <bkuhn@ebb.org>,
	Richard Fontana <rfontana@redhat.com>
Cc: 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 04:33:32 -0400	[thread overview]
Message-ID: <7c5e1900-7a9b-ac6a-87ab-bf0d38f70f26@lohutok.net> (raw)
In-Reply-To: <87a6ao3wij.ffs@tglx>

On 6/7/22 19:05, Thomas Gleixner wrote:
> On Tue, Jun 07 2022 at 11:12, Bradley M. Kuhn wrote:
>>
>> 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.

My perspective here is shaped by my experiences with lawyers and 
contributor agreements. In the early 2000s, as a leader of a free 
software foundation, I was explicitly told by a number of lawyers that 
unless we had a signed contributor agreement from every contributor, the 
free software project had no right to distribute those contributions. 
Part of a lawyer's job is to advise their clients based on their best 
understanding of the law and common practice, and those lawyers were 
doing exactly that, based on their experience in corporate law, so to a 
certain extent I can't fault them for doing their job to the best of 
their ability. But, while they were giving their best assessment of what 
*could be* true at the time, what they weren't doing was thinking about 
what *should be* true, in the context of free software. Both the law and 
common practice evolve over time, and we need to be intelligent about 
evaluating both what *could be* true at the moment, and what *should be* 
true in the long term. The concepts of inbound=outbound, DCO, and 
signed-off-by are now common practice, but getting there required some 
clever insight by some lawyers who really understoond free software, and 
also consistent practice by projects over time.

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. 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. Current practice is closer to the second, people 
feel free to throw in whatever garbled variant of the notice text FSF 
recommends, because they know that what really matters is the text of 
the GPL, which is invariant and has been carefully reviewed by lawyers. 
We absolutely want to make sure that people don't strip off the link to 
the GPL license, and use the file or its contents under terms other than 
the GPL, that is the legal purpose we're trying to achieve.

For a new file, adding the FSF notice, or adding some garbled version 
that still has the same terms as the GPL and FSF notice, or adding the 
SPDX license identifier are all legally equivalent ways of declaring 
that the file is subject to the terms of the GPL license. In terms of 
common practice, the SPDX identifier is actually superior because it's 
clear, consistent, machine readable, and limits the scope of garbled 
variations introduced by humans. (Humans actually manage to garble even 
those few characters of the SPDX identifier, but since it's machine 
readable, it's also machine checkable, so easy to kick back an error and 
say "that's not a valid SPDX identifier, did you mean X or Y?")

If the full text notice and SPDX identifier are legally equivalent, then 
can they legally be substituted in an existing file? There is a 
reasonable interpretation to say that *could be* allowed, but a more 
important question here is whether that *should be* allowed. Allowing it 
does no harm, the full terms of the GPL apply to the file with either 
the full text notice or the SPDX identifier. Allowing it is good for the 
cause of free software and for GPL enforcement, because it cleans up 
confusing cruft from historical human inconsistencies, and clearly 
declares the legal terms that apply to the file. So, I would argue that 
substituting SPDX identifiers for text notices should be allowed (as 
long as the text notice has the same terms as the GPL itself). While 
substituting SPDX identifiers might not be common practice yet, the way 
we make it common practice is by practicing it repeatedly until it 
becomes common.

It's also worth noting that there's isn't any risk of a "point of no 
return" here. 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, and generate a file that lists every file that had an 
SPDX identifier substituted under every match rule, if we decide that's 
actually necessary at some point. It really, really shouldn't be 
necessary (any more than contributor agreements are necessary), but it's 
reassuring to know have options.

Allison

  reply	other threads:[~2022-06-08  9:15 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 [this message]
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
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=7c5e1900-7a9b-ac6a-87ab-bf0d38f70f26@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 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).