Re: License text for LGPL-3.0

Richard Fontana

On Tue, Jan 11, 2022 at 10:48 AM Till Jaeger via
<> wrote:

Dear Steve and list members,

In my opinion it is a good idea to add the license text of the GPL-3.0 to the SPDX license information.

The simple reason is that the text that pretends to be the LGPL-3.0 license text isn't complete : "This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License". Hence, the GPL-3.0 license text is integral part of the LGPL-3.0 rather than just a reference.

Furthermore, I have seen many license violations because people just refer to a file with the (incomplete) license text. SPDX could improve the situation. In particular, some scanning tools copy the license text from SPDX.
I am not sure SPDX should get involved in influencing norms around
license text inclusion, as I think it should be responding to the
world as it is rather than (as REUSE does) trying to reform the world
into what it would want to see. But if the FSF is now encouraging use
of a license file that contains LGPL version 3 followed by GPL version
3, it seems to make sense for SPDX to reflect that change by adding
the GPL version 3 (I don't think we should say "GPL-3.0" in this case,
but that's a philosophical discussion for another time :) text.

I know that FSF traditionally used two license files (e. g. GPL-2.0 and LGPL-2.1) in its projects. Perhaps, the reason is that sec. 3 LGPL-2.1 provides a dual licensing scheme. Version 3 is different and I strongly recommend to always add the GPL-3.0 license text to the LGPL-3.0 license text (in the same file).
I don't think so, if we are thinking of the same thing. Rather, a very
common pattern seen in old GNU projects (and indeed similarly old
non-GNU projects using *GPL licensing) is that some portions of code
are deliberately maintained under LGPL and some portions under GPL. A
library might be under LGPL while a utility or daemon might be under
GPL, or at least the project would attempt to implement such a policy.


-------- Ursprüngliche Nachricht --------
Von: Steve Winslow <swinslow@...>
Datum: 11.01.22 08:41 (GMT-06:00)
An: Alexios Zavras <alexios.zavras@...>
Cc: Spdx-legal@...
Betreff: Re: License text for LGPL-3.0

Thanks Alan, Max and Alexios for your thoughts. A couple of responses inline below:

On Tue, Jan 11, 2022 at 5:55 AM Alexios Zavras <alexios.zavras@...> wrote:

. . .

Therefore I am not confident we should do a change to such a well-known text as LGPLv3 to support “use [a single] plain text license file as a source for obtaining and reproducing the [complete] license's text” (I’ve added clarifications to the original phrase by Steve).

Even setting aside the use case that REUSE has raised here (reproducing license texts), there's another good reason to make this change which I maybe didn't highlight.

The primary purpose of the SPDX License List templates is to enable matching to license texts. This combined LGPL+GPL text file [1] is now an option from the FSF for expressing the LGPL-3.0 license, and given that, it makes sense for the LGPL-3.0 template to match to it. The proposal here would enable that, by matching to this file because of including the GPL-3.0 text as <optional>.

I’m more than happy to extend the data in license-list-XML and add information attributes like “extra-files-needed” or something similar, which might help us address somehow the one-license-one-file limitation.

This is an interesting thought, and may be worth looking at more closely in the longer term. I can think of others that arguably fall into the category of typically-uses-more-than-one-file. For instance, Golang uses a BSD-3-Clause license [2] together with an additional patent license grant [3] which is expressed in a separate file. I don't want to derail us into a discussion of whether this would be an exception vs. a modification [4] so just noting that as another one that is somewhat complicated by appearing in two separate files.

That said, I think this would be a much more complex and longer-term consideration to think through (with implications for tooling and the tech team side of things). So I'd be inclined to add the <optional> text to LGPL-3.0 now, in parallel to whatever might be considered in the future for this.

[4] if you're really bored

-- zvr

From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Steve Winslow
Sent: Monday, 10 January, 2022 23:33
To: Spdx-legal@...
Subject: License text for LGPL-3.0

Hi all,

This is a follow-up from the discussion last summer at [1], based on the conversation during the Legal Team call this past week.

Folks may want to re-read the (long) thread there, which has links to the (long) discussion [2] in 2019-2020 and the (long) original conversation in 2015.

Assuming you don't want to, here's the gist of last week's conversation followed by the concrete proposal that was discussed.

(Note: all of the following applies to both the "-only" and "-or-later" variants of LGPL-3.0 and GPL-3.0, as well as the deprecated IDs that don't use either suffix.)


* The license-list-XML repo includes plain text versions of each license [4] which are primarily used to test whether the license's XML template matches the expected text.

* Some downstream projects, organizations and individuals, including REUSE [5], use these plain text license files as a source for obtaining and reproducing the license's text, e.g. to insert into a repo's license documentation. Although this wasn't an original design goal for the License List, some folks are doing it and finding value in it.

* For most licenses this approach works well, but for LGPL-3.0 it causes issues. LGPL-3.0 incorporates the text of GPL-3.0 by reference, but the LGPL-3.0 XML template [6] and text file [7] only contain the LGPL's own text, not the GPL's. So someone using this approach would only end up with LGPL's text.

* Traditionally the FSF has recommended that the LGPL and GPL text both be included in a repo, but in separate files. [8] SPDX doesn't have a way to represent that contents of multiple files should correspond to a single license.

* More recently (I believe following discussions with REUSE project participants), the FSF has subsequently published a version with the LGPL-3.0 text immediately followed by the GPL-3.0 text in a single file. [9], see [10]


REUSE would like to see the combined LGPL-3.0 + GPL-3.0 text used as the plain text file for LGPL-3.0 on the License List. That way, anyone pulling from the plain text licenses will (correctly) include both the LGPL and GPL texts.

To implement this, the XML template for LGPL-3.0 would also be updated, to add the GPL-3.0 text with <optional> tags following the non-optional LGPL-3.0 text.

Personally, I'm +1 to make these changes:

* It solves the problem REUSE has identified for their use case

* It means that the LGPL-3.0-* templates will continue to match standalone files with only the LGPL text, as well as matching files that contain the combined LGPL+GPL texts.

* It doesn't resolve all possible ambiguities about "did you mean everything in this repo is LGPL, or that some things are LGPL and some are GPL?" But neither does the current state of affairs. Using SPDX short-form license IDs and/or standard license headers solves this. So I don't see this as particularly significant to this specific proposal.

Please discuss.

Things that are off-topic for this thread:

* whether LGPL-3.0 should have been an "exception" rather than a "license" (see [1], [2] and [3])

* whether this was an ideal way for LGPL-3.0 to have been drafted (see the same threads)

Final side note:

I'd like to recognize Jilayne for accurately predicting that we'd be having this conversation right now, give or take a couple of months. [11]




[4]; in license-list-data repo at








Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0,
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Join to automatically receive all group messages.