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
next prev parent 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).