License text for LGPL-3.0
|
Steve Winslow
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.) Background * 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] Proposal: 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] https://github.com/spdx/license-list-XML/tree/master/test/simpleTestForGenerator; in license-list-data repo at https://github.com/spdx/license-list-data/tree/master/text [8] https://www.gnu.org/licenses/gpl-howto.html, see "COPYING" and "COPYING.LESSER" |
|
|
|
Alan Tse
I agree with this approach to use optional for the additional text. The ambiguity of what portion of the repo is covered by a license still exists regardless of this decision so it’s not something we should or could solve for.
From: <Spdx-legal@...> on behalf of Steve Winslow <swinslow@...>
CAUTION: This email originated from outside of Western Digital. Do not click on links or open attachments unless you recognize the sender and know that the content is safe.
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.)
Background
* 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]
Proposal:
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] https://github.com/spdx/license-list-XML/tree/master/test/simpleTestForGenerator; in license-list-data repo at https://github.com/spdx/license-list-data/tree/master/text [8] https://www.gnu.org/licenses/gpl-howto.html, see "COPYING" and "COPYING.LESSER"
|
|
|
|
Max Mehl
Steve, thank you so much for summarising the discussion, and the Legal
Team for working on the topic. I regret that I did not join the call, but from what I see you basically got everything covered anyway. ~ Steve Winslow [2022-01-10 22:33 +0100]: * The license-list-XML repo includes plain text versions of each licenseOff-topic: would there be a better way for REUSE to fetch the full license texts? Personally, I'm +1 to make these changes:As a REUSE team member, I am obviously in favour of these changes as well. * It doesn't resolve all possible ambiguities about "did you meanAs also mentioned by Alan, this is a separate problem. For REUSE however, this is no big deal as you can tell from the name of the license text file (e.g. LICENSES/LGPL-3.0-only.txt) that the file should cover the LGPL license. If someone had also file under GPL, thios would just mean that another license text file (e.g. LICENSES/GPL-3.0-only.txt) would exist. *Things that are off-topic for this thread*:FYI, in the discussions we've had with FSF about this topic, this was also our proposal but it has been rejected by them. 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 |
|
|
|
Alexios Zavras
Thinking about it more generally, I think the issue stems from the assumption that “one license == one file”. I am not sure everyone should rely on this being true in all cases.
For the SPDX License List, where we care about license texts and identifying (matching) them, we were OK till now, by a combination of convention, tradition and some luck. Fortunately, all widely used Open Source licenses are a single text file.
For the REUSE project, with the goal of conveying this information, I think the assumption has evolved towards “I can include a license in a single file”, which might be worth re-considering.
After all, I can easily imagine a BSD-like license that says “… must retain the above copyright notice, this list of conditions, the following disclaimer, and the photograph of the author.” (where the photograph is presumably in a separate file). We are lucky no such license is in wide use today.
Actually, there is no need for such hypothetical example: we already have in the License List the Community-Spec-1.0 license, which has sections that refer to external files that must accompany the license text. They are not even optional: the license says “term X has the meaning as set forth in the accompanying X.md file”.
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).
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.
-- 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.)
Background
* 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]
Proposal:
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] https://github.com/spdx/license-list-XML/tree/master/test/simpleTestForGenerator; in license-list-data repo at https://github.com/spdx/license-list-data/tree/master/text [8] https://www.gnu.org/licenses/gpl-howto.html, see "COPYING" and "COPYING.LESSER"
Intel Deutschland GmbH |
|
|
|
Steve Winslow
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:
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>.
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] https://github.com/spdx/license-list-XML/issues/646#issuecomment-569969690 if you're really bored
|
|
|
|
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 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).
Thanks for raising this issue!
Best,
Till
-------- 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:
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>.
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] https://github.com/spdx/license-list-XML/issues/646#issuecomment-569969690 if you're really bored
|
|
|
|
Richard Fontana
On Tue, Jan 11, 2022 at 10:48 AM Till Jaeger via lists.spdx.org
<jaeger=jbb.de@...> wrote: 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. Richard
|
|
|
|
Max Mehl
~ Steve Winslow [2022-01-10 22:33 +0100]:
*Proposal*:Following up on Steve's proposal, I see many people agreeing on it, or at least shrugging. There has been a proposal by Alexios that would require a larger rework as I understand it, but it feels not like a blocker to this concrete proposal, rather like a good idea to make special cases like these easier to handle in the future. Are there any more blockers? 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 |
|
|
|
Steve Winslow
Hi Max, circling back on this thread and your question: We briefly discussed this as a follow-up on the last legal team call, and agreed that there did not appear to be any significant objections to modifying the LGPL-3.0[-only/-or-later] templates as earlier described here. I'm planning to submit a PR to incorporate the GPL text as optional in the templates, so that it'll be included for the next license list release. Best, Steve On Mon, Jan 24, 2022 at 11:02 AM Max Mehl <max.mehl@...> wrote: ~ Steve Winslow [2022-01-10 22:33 +0100]: |
|
|
|
Philippe Ombredanne
Steve, Max:
FWIW, I already voiced my objection on this topic in the past and I think this is going to be a source of confusion and ambiguity. Why would we need to change the SPDX text for the purpose of one tool and convention? Max: Could you not change your text in your tool instead? - I do not think any of the license texts in SPDX have been designed to be used as reference texts; if anything the templating makes them non suitable for this purpose. - If mixing related texts together is the new way to craft a license text, why not also change the texts of the LGPL 2 and 2.1 to include the text of the GPL 2 in them? - Like the LGPL, every other exception of the GPL would technically demand to include a GPL text too... Does this mean that all the exception texts should be updated now? On Thu, Mar 10, 2022 at 4:06 PM Steve Winslow <swinslow@...> wrote: Hi Max, circling back on this thread and your question:-- Cordially Philippe |
|
|
|
Max Mehl
Hi Philippe,
~ Philippe Ombredanne [2022-03-10 18:33 +0100]: Why would we need to change the SPDX text for the purpose of one toolIIUC, this is not changing the text of the LGPL license in SPDX, but adding an optional segment. This optional text does not come out of the blue but is provided officially by the FSF: https://www.gnu.org/licenses/lgpl+gpl-3.0.txt I refrain from reiterating the whole rationale why some people asked FSF to do that. It's there, and I think there is good reason for SPDX to include it. Max: Could you not change your text in your tool instead?Sure, we could make a special rule for downloading the license text. But as said, I think it provides extra value for SPDX as well. - I do not think any of the license texts in SPDX have been designedI am sorry if we use it that way, but it proves to be extremely useful for us (REUSE). Since we cannot maintain a compendium of SPDX-supported license texts ourselves, this is the next best solution. - If mixing related texts together is the new way to craft a licenseIANAL, but LGPLv2.x are crafted differently than LGPLv3. While the former can be read as standalone licenses, the latter expands GPLv3. It cannot be understood without it and could easily be understood as an exception [^1]. In earlier mails there was some discussion whether it's an exception or not. But that's not important, FSF does not see it like that. - Like the LGPL, every other exception of the GPL would technicallyAbsolutely not. The problem is that LGPLv3 is not considered an exception, both in SPDX and FSF, while e.g. GCC-exception-3.1 is. In the REUSE scope, when you add SPDX-License-Identifier: GPL-3.0-only WITH GCC-exception-3.1 to a file and run `reuse download --all`, the tool will download both the full GPL license text as well as the exception from [^2]. With LGPL-3.0-only, the user would just get the "incomplete" text from [^3]. Best, Max [^1]: E.g. "1. Exception to Section 3 of the GNU GPL." [^2]: https://spdx.org/licenses/GCC-exception-3.1.html [^3]: https://spdx.org/licenses/LGPL-3.0-only.html -- Max Mehl - Programme Manager -- Free Software Foundation Europe Contact and information: https://fsfe.org/about/mehl -- @mxmehl The FSFE is a charity that empowers users to control technology |
|
|