1. Messages
  2. Combined version of LGPL + GPL 3.0

Re: Combined version of LGPL + GPL 3.0

J Lovejoy
 

Hi all,

Sorry for the delay in responding, I got busy with other things and needed some time to fully re-read this thread and absorb everything.  Thanks to Max, Matija, and Sebastian for your combined collection of catching us up to how we got here. I fully believe there were only good intentions here, just not the ideal order of events or modes of comms (a point which needs not be dwelled on further). 

In any case, this thread raises several separate (even if related) issues, which I think would be best if separated out a bit. Sorry this got kind of long, but please read to the bottom. :)

1) LGPL-3.0 as a standalone short identifier: Let's just all acknowledge (once and for all) that the LGPL-3.0 (unlike 2.0 or 2.1) is NOT written as a standalone license, but it IS an additional permission (aka, exception) to GPL-3.0. The FSF, as the license steward states it as so on this page https://www.gnu.org/licenses/lgpl-3.0.en.html, where it says, "This license is a set of additional permissions added to version 3 of the GNU General Public License." Thus, we can all agree that in strictly applied SPDX license expressions, it should be on the exceptions list and denoted as: GPL-3.0* WITH LGPL-3.0*.

However, when we implemented 2.0 of the SPDX License List with the license expressions in 2015, this was discussed and given industry practice and understanding, we did not put LGPL-3.0 on the exceptions list. Is this sort of breaking the mold, in terms of how other licenses/exceptions are treated on the SPDX License List? Yes. (Is it also somewhat "consistent" in terms of treating all of the GNU licenses in a special way, especially given later changes? Yes.) It is what it is, that shipped has sailed, there is no reason to cause further confusion (and disruption to SPDX users) by changing identifiers/expression now especially when the FSF has seemingly confirmed this special case scenario. (We might consider putting a Note acknowledging this to some degree, to avoid further discussion or questions in the future.)

2) How the text of GPL/LGPL-3.0 is displayed as per the FSF: The FSF has always had the advice to put a COPYING file with the GPL and add a COPYING.LESSER file with the LGPL if using that, as per https://www.gnu.org/licenses/gpl-howto.html That is pretty clear instructions (and is what I've observed people to mostly do).

From my/a legal perspective, if someone only provided the text of the LGPL, I don't think this causes some great problem or license non-compliance. The LGPL-3.0 clearly states that it "incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below." Sure, I link to GPL-3.0 would be nice, but I don't think the lack of a link causes any failure. It's pretty clear.

As far as I can tell, the only thing the FSF has done is add a specific page with the combination of the GPL-3.0 and LGPL-3.0 text, which one would only find (by navigation) on this page https://www.gnu.org/licenses/lgpl-3.0.en.html - the advice on their "How to use GNU licenses" page remains the same.

Certainly for tooling (license scanners) matching on the text of both the GPL-3.0 and LGPL-3.0 as per the FSF's instructions is not enough to let you know specifically what code is licensed under what license. Having both texts in one file doesn't really change this situation. But this is no different than any of the GNU licenses: if a project has just COPYING file with the text of the GPL-3.0, you don't know if the code is meant to be under GPL-3.0-or-later or GPL-3.0-only; the way you know that is via the notice on the source files - be that the standard header that the GNU licenses include or an SPDX identifier/expression.

Thus, I don't see how the FSF adding a somewhat hard-to-find new webpage with the plain text of both the GPL-3.0 and LGPL-3.0 changes anything.

3) FSF endorsing SPDX identifiers: On a related note: What WOULD be helpful here is if the FSF could explicitly endorse and document on the appropriate pages the use of "SPDX-License-Identifier: " in each source file. I have copied John Sullivan (who is already on the SPDX-legal list) and Donald (who is not) here again. A response would be nice.

4) Using SPDX data to pull the text of the license for use elsewhere (be it, REUSE or other places that we aware also do this): While this may not be an explicit goal of SPDX, we have long known that the database that comprises the totality of the SPDX License List is quite useful and used by many people and organizations in a variety of ways. That is a success of the project, for sure. I do not agree at all that the plain text versions that are stored in the repo for the SPDX License List are not appropriate for this use. However, I think this is a larger topic that goes beyond this specific scenario and suggest we have a separate thread on that (I'll start that off later this week)

5) Compliance with REUSE: it seems the the real issue that started this lies with some strict requirement for compliance with the REUSE specification to have one text file per one license identifier (as opposed to a license expression) with all the necessary text of the license;  and that LGPL-3.0, by way of its inclusion of GPL-3.0 and the FSF's recommendation for two files kind of breaks that. I am certainly not a programmer, but couldn't this be solved with a bit of coding to make an exception (ha ha ha) for the special circumstance of LGPL-3.0?  Going to the extent of adding the full text of the GPL-3.0 as optional to the LGPL-3.0 files in the SPDX License List database still seems backwards to me.

I think the key thing that needs further discussion is #4 - as mentioned above, I'll start a separate email thread with some thoughts on that and we can go from there.

I don't think there's much to discuss as to #1 and #2 and we will have to wait for a response from the FSF on the tangent issue of #3.

#5 can probably be continued, as need be on the mailing list, at least for now?

Given the above, the late hour now, and that we have a meeting tomorrow, we we will focus on closing out the 3.14 release, some other projects that need attending to.

Thanks again,
Jilayne

On 7/30/21 9:25 AM, Matija Šuklje wrote:

On Wednesday 28 July 2021 17:22:21 CEST J Lovejoy wrote:

I meant to add: our next legal call is Thursday, Aug 5th at 10am
mountain time.
Happy to dedicate some time then to this topic, if a
live-discussion would help and all interested parties can
attend.

I have a clashing obligation that I can’t move then, but will try 
to shed as much light on how this came about …esp. seeing as this 
snowballed from my original comment about LGPL-3.0 being an 
exception.

{0) whether you need to include GPL-3.0 text with LGPL-3.0 text is 
not a new discussion.
FSF’s HowTo asks for GPL(-3.0) or AGPL(-3.0) in `COPYING` _and_ 
LGPL(-3.0) in `COPYING.LESSER`}

1) Germano Gabbianelli opens a ticket in REUSE pointing out that 
the LGPL-3.0 requires GPL-3.0 text as well:
<https://github.com/fsfe/reuse-tool/issues/86>

2) In connection to the above issue, I publicly point out that 
LGPL-3.0 reads and behaves as an exception:
<https://github.com/spdx/license-list-XML/issues/956>
Before me Sam Ellis pointed this out back in 2015, as Jilayne 
noted in her reply in the issue:
<https://lists.spdx.org/g/Spdx-legal/topic/22080579#1092>
Then (2015 and in 2020) SPDX Legal decided that while LGPL-3.0 
does indeed look like an exception, they will continue treating it 
as a full license essentially for legacy’s sake; and that they 
would change that only if the FSF would say that it is an 
exception.

3) FSFE reaches (Max and I) out to FSF regarding the question 
whether LGPL-3.0 is an exception or not. This question was not 
directly tied to SPDX and part of it was also whether LGPL-3.0 
could then be applied to AGPL-3.0, which I have heard (in my 
previous life as FSFE’s Legal Coordinator) the community request 
an ALGPL as back as at least 2011. FSF said that they always saw 
LGPL as a license and they do not want to cause confusion for 
people changing from LGPL-2.x to LGPL-3.0, for – again – legacy’s 
sake. We also pointed out that people often do not include GPL-3.0 
text with the LGPL-3.0.

4) After some time FSF decides that instead they would release a 
version of the LGPL-3.0 license as

5) Since this solves the immediate problem in 1) and 0) above, Max 
and Sebastian posted it to SPDX (continuation of 2) and this e-
mail thread)

… and here we are now. No ill will as intended, and I hope this 
explains how this all came to be.

My own thoughts on this are:

• LGPL-3.0 still _is_ an exception, and if it was treated as such 
(by FSF, SPDX, REUSE, etc. etc.) things would be much more clearer

• a better solution than simply concatenating GPL-3.0 and LGPL-3.0 
texts would be to actually write a LGPL-3.1 (ha, history repeats 
itself!) which would be a stand-alone version – just as AGPL-3.0 
is, even though it differs less from GPL-3.0 than LGPL-3.0 does

• failing that, I honestly didn’t see – apart from tooling, as 
Philippe pointed out and I missed – why the GPL-3.0 part couldn’t 
be an optional part in the LGPL-3.0 template. And if that’s the 
issue, then tooling would be misfiring in any case, if someone 
using LGPL-3.0 would be following official FSF guidelines as is.

• this brings an important question what is the intend of the SPDX 
License List’s templates – only for SPDX ID’s and scanners, or 
also as a reference text – the website simply states:


The purpose of the SPDX License List is to enable efficient and 
reliable identification of such licenses and exceptions in an 
SPDX document, in source files or elsewhere. 

• an alternative could be that the (canonical) LGPL-3.0 text 
includes a URL to the canonical GPL-3.0 text in its preamble, 
e.g.:


This version of the GNU Lesser General Public License 
incorporates the terms and conditions of version 3 of the GNU 
General Public License <https://www.gnu.org/licenses/gpl-3.0>, 
supplemented by the additional permissions listed below.

And I want to reiterate again, no-one wanted to circumvent any 
stakeholder – this thread is proof of this! –, but for things to 
move forward at all, discussions happened on different ends and 
now it’s time to see how we can tie the ends. And if we cannot, 
whether there is any way we can at least improve on the status 
quo.


cheers,
Matija Šuklje

Join {Spdx-legal@lists.spdx.org to automatically receive all group messages.