-----Original Message-----
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of Max Mehl
Sent: Wednesday, 28 July, 2021 12:35
To: Spdx-legal@...
Cc: SPDX-legal <spdx-legal@...>; spdx-tech@...
Subject: Re: [spdx-tech] Combined version of LGPL + GPL 3.0

Hi Philippe,

(I mistyped the spdx-tech address, fixed here)

~ Philippe Ombredanne [2021-07-28 12:04 +0200]:

On Wed, Jul 28, 2021 at 11:01 AM Max Mehl <max.mehl@...> wrote:

In the scope of REUSE we've noticed [^1] that just providing
LPGL-3.0* – as downloaded from SPDX – in a repo does not suffice as
it requires its mother license, GPL-3.0*. LGPL could be seen as an
exception to GPL, but it's not treated as such by the FSF.

Matija and I discussed that with FSF and the different options we
have to suit SPDX, REUSE and other downstreams. We found a
compromise: there is now an officially acknowledged license text that
contains both
LGPL-3.0 and GPL-3.0:

https://www.gnu.org/licenses/lgpl+gpl.txt

Has this been discussed publicly?

The ticket in the reuse-tool is public, the discussions with FSF were private with John Sullivan and Donald Robertson.

Now my request: can we get this combined version into SPDX' license
list data, e.g. [^2]?
[^1]: https://github.com/fsfe/reuse-tool/issues/86
[^2]:
https://github.com/spdx/license-list-data/blob/master/text/LGPL-3.0-o
r-later.txt

I think that you stated explicitly this is not a new license, just a
clarification (optional one?) that providing both texts when
referencing LGPL-3* is better.
How could one ever handle this sanely in practice? If this is not a
new license, why would you need a new license identifier? If this is a
new license, or a new previsously unstated requirement of the LGPL 3
it would need some wide open and public discussion IMHO.

Sorry if this has been unclear. I do not request a new license identifier but an amendment of the full text version. LGPL-3.0* requires the GPL-3.0 text, and FSF has officially provided a concatenated version.

For SPDX and other downstreams it would just make sense to use the "complete" version IMHO, as it meets users expectations.

Some examples of the new and updated clarity issues this brings:

Say I stumbled on the text at
https://www.gnu.org/licenses/lgpl+gpl.txt in some project... is this
project using the LGPL only or the LGPL and the GPL that apply? It is
impossible to disambiguate which one applies short of a statement by
the authors that they mean the GPL not to apply but that only the LGPL
should be considered there and that the GPL text is there only for
reference.

The top of the file quite clearly states that this is about the LGPL.

But of course, just from this text it's unclear how the actual code is licensed, but that's a common problem in repos using multiple licenses.
That's why SPDX license identifiers make a lot of sense, and also why the REUSE way of storing license texts is so useful.

It's very clear if you store the above license text under `LICENSES/LGPL-3.0-or-later.txt` and mark the files with
`SPDX-License-Identifier: LGPL-3.0-or-later`.

What if a project contains both GPL3 and LGPL 3-licensed code? They
could use the exact same text as above and I would still not be able
to disambiguate short of extra statements.

Well, in the example above, that wouldn't be any problem. You can have both GPL and LGPL licensed code in your repo, and by using SPDX expressions you can even dual-license selected files if you wanted.
Again, just by having a LICENSE file things are ambiguous anyway.

And what's the alternative for LGPL-3.0? Just using the text that SPDX provides currently is not compliant as the license requires the GPL-3.0 to be present. What changed now is that there is an official upstream combined version, so SPDX should use it.

Now say the author added a license identifier in the code saying that
this is "LGPL-3.0-only"... did they forget to reference the GPL text
in the combined text above? Or is this really just LGPL? Or is some
part of the code GPL-licensed but not marked as such? I cannot say for
sure either and I would not trust that. I still need some more
explicit statements to get clarity.

IMHO the status of the LGPL as a self standing text or whether it
needs to be accompanied by the GPL text has been a jolly mess of
ambiguity since the release of the L/GPL3*.

I cannot see how the FSF releasing a text that combines two texts
makes it any better, to the contrary: it just adds even more ambiguity
and confusion. Even more so if there has been no public discussion on
the topic.

I cannot fathom how this kind of confusion, uncertainty and doubt is
helpful to anyone producing or consuming LGPL-licensed code.

I get your point, and it's also not the most ideal outcome, but as written above I think the situation improved.

And of course we need explicit statements, and thanks to the combination of SPDX and REUSE that's a common best practice.

Best,
Max

--
Max Mehl - Programme Manager - Free Software Foundation Europe Contact and information: https://fsfe.org/about/mehl | @mxmehl Become a supporter of software freedom: https://fsfe.org/join





Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
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