Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LGPL also requires GPL #86

Closed
tyrion opened this issue Sep 2, 2019 · 17 comments
Closed

LGPL also requires GPL #86

tyrion opened this issue Sep 2, 2019 · 17 comments
Labels
bug Something isn't working upstream It's someone else's problem
Milestone

Comments

@tyrion
Copy link

tyrion commented Sep 2, 2019

Hello,

I was wondering how to properly license software with LGPL. On the GNU website ( https://www.gnu.org/licenses/gpl-howto.html ) I read that I should include both the GNU GPL plus the content of the LGPL:

Please note that, since the LGPL is a set of additional permissions on top of the GPL, it's crucial to include both licenses so users have all the materials they need to understand their rights

However the REUSE tool seems to be downloading only the text of the LGPL. Is that ok even if it contradicts the official guidelines?

Thanks :)

@carmenbianca
Copy link
Member

@silverhook Do you know a good answer to this question? I was under the impression that the LGPL contained a full copy of the GPL itself, and simply added some sections. But apparently it's just the added sections.

@carmenbianca
Copy link
Member

carmenbianca commented Sep 3, 2019

@tyrion As a temporary solution if you want to have the licence texts for both the GPL and LGPL, and make sure that the tool doesn't complain, you could do something like the following two options:

  • Dual-license at least a single file under both GPL-3.0-or-later and LGPL-3.0-or-later.

  • Create a file README.gpl.md (or any other name) in the root of your project that is licensed under GPL-3.0-or-later with a short explanation of why.

In the meantime I'm still trying to figure out how other people do this, what the sanest way to do is, and how to elegantly implement any of it.

@alandtse
Copy link

alandtse commented Oct 7, 2019

I think it's probably best to download both licenses and have the tool recognize LGPL also requires the GPL license text.

@carmenbianca carmenbianca changed the title How to properly license under LGPL LGPL also requires GPL Oct 24, 2019
@carmenbianca carmenbianca added the bug Something isn't working label Oct 24, 2019
@silverhook
Copy link
Contributor

I agree with @alandtse, on how things are right now.

But I also think (and I’ve argued this before) that SPDX should list LGPL-3.0 as an exception to GPL-3.0 instead of a stand-alone license – as this is what it in practice really is.

I’ve opened up a ticket about it here: spdx/license-list-XML#956

I would suggest to keep this issue open (or forked into a new one) until the SPDX issue above is addressed.

@mxmehl
Copy link
Member

mxmehl commented Mar 16, 2021

We've been discussing that with the FSF. They are considering generating a document containing both LGPL-3.0 and GPL-3.0. That would solve the issue REUSE/SPDX-wise.

@silverhook
Copy link
Contributor

It’s a good ’nuff solution.

@seabass-labrax
Copy link
Contributor

I wonder if this could be resolved in the SPDX License List by adding the entire GPL-3.0 license text as an 'optional' section in the LGPL-3.0 XML files. Programs that create license files (such as the REUSE tool) would thus include the full GPL as part of the LGPL file.

Indeed, if the FSF released a document combining the GPL and LGPL texts, the optional section would allow for this to be properly matched to the LGPL as well!

@mxmehl, I'd be really interested to hear what you think about this :)

@silverhook
Copy link
Contributor

@seabass-labrax, that is an interesting work-around.

I suspect (and nothing more then that!) that SPDX would be reluctant to do that, unless FSF would create such a text themselves or if the concatenated versions of GPL-3.0 and LGPL-3.0 would prove to be common enough in the wild.

@mxmehl
Copy link
Member

mxmehl commented Jul 26, 2021

@seabass-labrax That'd be a wonderful solution for this problem. If SPDX could do that, REUSE would make use of that.

I did not hear much more from FSF that what I've written on 16 March, but will send a reminder today.

@mxmehl mxmehl added the upstream It's someone else's problem label Jul 26, 2021
@mxmehl
Copy link
Member

mxmehl commented Jul 27, 2021

Update: the FSF will add a concatenated version on https://www.gnu.org/licenses/lgpl-3.0.en.html soon!

@silverhook
Copy link
Contributor

Great! Will you update also SDPX on this, @mxmehl ?

@seabass-labrax
Copy link
Contributor

That's great news, @mxmehl! This shall certainly streamline compliance for people using the LGPL and REUSE.

@silverhook, I'm more than happy to make the modifications to the SPDX License List's XML. Assuming the other members of the SPDX Legal Team concur on the suitability of the addition, I think this could well make it into the 3.15 release in October :)

@silverhook
Copy link
Contributor

It’s got my vote ;)

@mxmehl
Copy link
Member

mxmehl commented Jul 28, 2021

Great! Will you update also SDPX on this, @mxmehl ?

Sure, just wanted to wait until the link is online, which happened now: https://www.gnu.org/licenses/lgpl+gpl.txt

I will ping SPDX-legal about this, OK?

@pombredanne
Copy link

Update: the FSF will add a concatenated version on https://www.gnu.org/licenses/lgpl-3.0.en.html soon!

@mxmehl I am not sure I agree this is a good idea.
I posted a reply at https://lists.spdx.org/g/Spdx-legal/message/2951 which I am reproducing here for reference.

Hey Max,
You wrote:

On Wed, Jul 28, 2021 at 11:01 AM Max Mehl max.mehl@fsfe.org 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?

Now my request: can we get this combined version into SPDX' license list
data, e.g. [^2]?
[^1]: #86
[^2]: https://github.com/spdx/license-list-data/blob/master/text/LGPL-3.0-or-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.

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.

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.

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.

@ferdnyc
Copy link
Contributor

ferdnyc commented Jan 2, 2022

Continuing from the duplicate issue I'd opened in #452...

One thing I don't understand from @pombredanne's comments:

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.

It's hardly "previously unstated", the LGPL explicitly depends on the GPL as its basis; the text of the license itself defines it in terms of "GPL-with-the-following-adjustments" — always has. In fact, it's required to be accompanied by a copy of the GPL itself.

Selections from the text (emphasis added):

This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below.

  1. Additional Definitions.

As used herein, "this License" refers to version 3 of the GNU Lesser General Public License, and the "GNU GPL" refers to version 3 of the GNU General Public License.

  1. Exception to Section 3 of the GNU GPL.
    You may convey a covered work under sections 3 and 4 of this License without being bound by section 3 of the GNU GPL.

The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following:

a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License.

b) Accompany the object code with a copy of the GNU GPL and this license document.

The ambiguities you raise are valid ones, but that's why I actually think the combined text is a good solution. My original thought was to just add GPL-3.0-or-later.txt to the LICENSES/ directory (which causes reuse lint to fail, currently), but that would create confusion over whether the GPL applies to the repo or not.

If the GPL text is included within LGPL-3.0-or-later.txt, then the LGPL is pretty unambiguously the applicable license. Having two separate files for a single license would be the source of greater confusion.

Not to mention, as you say it would make repos that contain both GPL software, and LGPL software, indistinguishable from repos entirely covered under the LGPL.

(...At a glance, anyway. Ultimately, a project's licensing "universe" is defined by the combined set of license tags across each individual source file and/or the .reuse/dep5 configuration, not the license texts collected in the LICENSES/ directory. Those are simply referential.)

More from @pombredanne:

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.

That's a definitional impossibility, the GPL can't "not apply" to any LGPL-licensed project, since it explicitly defines itself as a set of additional permissions that extend the GPL. The question is whether the broader permissions of the GPL as expanded by the LGPL apply, which is the case for anything licensed LGPL-3.0-or-later.

But having them both in the same file, instead of separate documents, I would argue makes it unambiguously clear that the LGPL with all of its additional permissions is intended.

@mxmehl
Copy link
Member

mxmehl commented May 6, 2022

This issue is fixed with spdx/license-list-XML#1425 being merged and the updated text being incorporated in the license-list-data repo 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working upstream It's someone else's problem
Projects
None yet
Development

No branches or pull requests

8 participants