Date   

Re: [spdx] Message Approval Needed - spdx@anthonyronda.com posted to spdx@lists.spdx.org

Anthony Ronda
 

Thanks for the forward! It appears to be open for public comment now

> (Btw, this message got caught up as from a non-member - not sure if you used a different email address?)

I specifically entered this email into https://lists.spdx.org to avoid that, because spdx@myname is the address I registered as a forwarding alias for SPDX listservs 🙃



-Anthony


Re: proposal for Fedora to start using SPDX identifiers

Jonas Smedegaard
 

Quoting J Lovejoy (2021-08-05 05:52:13)
Hi Sebastian,

I knew/hoped there'd be some SPDX'ers who were also Fedora fans!

See comment below on where folks familiar with SPDX could be of most help:

On 8/4/21 4:00 PM, Sebastian wrote:
As some of you may remember, SPDX-legal undertook adding many
licenses on the Fedora Good list back in 2013-14 time frame. I have
since looked at the current Fedora Good list and updated a
comparison doc, see:
https://docs.google.com/spreadsheets/d/1fi5SVzyCAL0UDravvkS6Us4lFwRiQy-l3qTUEkY92U0/edit#gid=243613621

For any of you who are here and Fedora enthusiasts, help with
researching some of the licenses and (eventually) updating existing
Fedora package license info once this all moves forward would be
greatly appreciated. It would also be good to think about ways to
collaborate into ways to automate any cross-functional processes
going forward so that we stay in sync.
Wow - that's an extensive spreadsheet you have there! I'll be able
to offer some information on the 'Teeworlds license' listed in the
spreadsheet at tomorrow's, shall we say, Legal 'Teem' meeting :)
For any of the licenses marked as "NO" (not on SPDX License List, but
identified on the Fedora good list) - there is a need to:
1) see if the license is still used in Fedora - this can be done by a
search for the Fedora identifier (if it's unique)
2) if so, then finding the actual text of the license in the source
files and seeing if it happens to already be a match to something on
SPDX License List
3) if not, submit to add
Since I assume it is not only relevant if those licenses identified by
Fedora exists "in the wild" only _distributed_ by Fedora, I can suggest
to also make use of https://codesearch.debian.net/


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private


Re: proposal for Fedora to start using SPDX identifiers

J Lovejoy
 

Hi Sebastian,

I knew/hoped there'd be some SPDX'ers who were also Fedora fans!

See comment below on where folks familiar with SPDX could be of most help:

On 8/4/21 4:00 PM, Sebastian wrote:
As some of you may remember, SPDX-legal undertook adding many licenses
on the Fedora Good list back in 2013-14 time frame. I have since
looked at the current Fedora Good list and updated a comparison doc,
see:
https://docs.google.com/spreadsheets/d/1fi5SVzyCAL0UDravvkS6Us4lFwRiQy-l3qTUEkY92U0/edit#gid=243613621

For any of you who are here and Fedora enthusiasts, help with
researching some of the licenses and (eventually) updating existing
Fedora package license info once this all moves forward would be
greatly appreciated. It would also be good to think about ways to
collaborate into ways to automate any cross-functional processes going
forward so that we stay in sync.
Wow - that's an extensive spreadsheet you have there! I'll be able to
offer some information on the 'Teeworlds license' listed in the
spreadsheet at tomorrow's, shall we say, Legal 'Teem' meeting :)

For any of the licenses marked as "NO" (not on SPDX License List, but identified on the Fedora good list) - there is a need to:
1) see if the license is still used in Fedora - this can be done by a search for the Fedora identifier (if it's unique)
2) if so, then finding the actual text of the license in the source files and seeing if it happens to already be a match to something on SPDX License List
3) if not, submit to add

I have a notes column going to track any research as needed in the interim and am happy to add anyone with edit access who wants to help work on this. I think this is probably best done by folks who are pretty familiar with SPDX (the license list generally and matching guidelines)

Thanks,
Jilayne




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


Re: proposal for Fedora to start using SPDX identifiers

Sebastian Crane
 

Dear Jilayne,

I've been chatting to some of the Fedora folks about adopting the use
of SPDX license identifiers in its package spec files. I just posted a
comment/ proposal to a PR that was opened some time ago, See
https://pagure.io/packaging-committee/pull-request/971#
That's great news! I have been using Fedora for about two years as my
primary operating system, so hearing about this development is
particularly interesting to me.

As some of you may remember, SPDX-legal undertook adding many licenses
on the Fedora Good list back in 2013-14 time frame. I have since
looked at the current Fedora Good list and updated a comparison doc,
see:
https://docs.google.com/spreadsheets/d/1fi5SVzyCAL0UDravvkS6Us4lFwRiQy-l3qTUEkY92U0/edit#gid=243613621

For any of you who are here and Fedora enthusiasts, help with
researching some of the licenses and (eventually) updating existing
Fedora package license info once this all moves forward would be
greatly appreciated. It would also be good to think about ways to
collaborate into ways to automate any cross-functional processes going
forward so that we stay in sync.
Wow - that's an extensive spreadsheet you have there! I'll be able to
offer some information on the 'Teeworlds license' listed in the
spreadsheet at tomorrow's, shall we say, Legal 'Teem' meeting :)

Best wishes,

Sebastian


Re: [spdx] Message Approval Needed - spdx@anthonyronda.com posted to spdx@lists.spdx.org

J Lovejoy
 

Hi Anthony,

Thanks for pointing this out. I tried to add a comment, but it appears to be closed. Thomas is active in the SPDX-tech team, but would be nice if someone from the SPDX-legal could add a bit - anyone part of TODO Group who can comment?

Copying the tech team for awareness as well. 

(Btw, this message got caught up as from a non-member - not sure if you used a different email address?)

Thanks,
Jilayne



Change your notification settings


From: "Anthony Ronda" <spdx@...>
Subject: TODO Group comments on SPDX+GitHub
Date: August 3, 2021 at 9:59:58 AM MDT


https://github.com/todogroup/gh-issues/issues/72

This conversation might benefit from the participation of experienced SPDX folks. In summary, they're discussing the lack of GitHub support for complex licensing identification that could in theory be supported with SPDX identifiers. ORT gets a shout-out.

Repo description:
A curated set of issues related to GitHub and running corporate scale open source that the TODO Group would advocate for with GitHub or possibly in git itself.

In case you haven't heard of TODO Group: https://todogroup.org/members/



Re: 3.14 license list release

Steve Winslow
 

Hi Lars,

I've just added comments in both threads giving a +1 to add each of these.

If others from the legal team community can add in (so that we've got approval per https://github.com/spdx/license-list-XML/blob/master/DOCS/request-new-license.md#review-process), then fine to add for 3.14 if you're able to submit the PR's with passing XML / test files sometime before Saturday.

Can a few others from the community weigh in on the issue threads as well? Here are the direct links:

On Mon, Aug 2, 2021 at 8:17 AM Lars Willighagen <lars.willighagen@...> wrote:
Hi,

I have requests open for two Creative Commons ports, CC BY-NC-SA 2.0 FR and CC BY 3.0 NL. Could those still be included in this release, or is it too late for that? I can prepare the files today if required.

Thanks,
Lars

Op vr 30 jul. 2021 om 20:38 schreef J Lovejoy <opensource@...>:
Hi all,

We are going to aim for the end of next week for the 3.14 release - giving everyone an extra week to tidy up any outstanding issues.  So, if you haven't gotten to something, you have a bit more time!

Thanks,
Jilayne



--
Lars Willighagen



--
Steve Winslow
VP, Compliance and Legal
The Linux Foundation


Re: 3.14 license list release

Lars Willighagen
 

Hi,

I have requests open for two Creative Commons ports, CC BY-NC-SA 2.0 FR and CC BY 3.0 NL. Could those still be included in this release, or is it too late for that? I can prepare the files today if required.

Thanks,
Lars

Op vr 30 jul. 2021 om 20:38 schreef J Lovejoy <opensource@...>:

Hi all,

We are going to aim for the end of next week for the 3.14 release - giving everyone an extra week to tidy up any outstanding issues.  So, if you haven't gotten to something, you have a bit more time!

Thanks,
Jilayne



--
Lars Willighagen


3.14 license list release

J Lovejoy
 

Hi all,

We are going to aim for the end of next week for the 3.14 release - giving everyone an extra week to tidy up any outstanding issues.  So, if you haven't gotten to something, you have a bit more time!

Thanks,
Jilayne


Re: Combined version of LGPL + GPL 3.0

Philippe Ombredanne
 

Dear Sebastian, Max:

On Wed, Jul 28, 2021 at 7:03 PM Sebastian <seabass-labrax@...> wrote:

- Users of REUSE would simply need to download LGPL-3.0 via the REUSE
tool. The tool fetches the SPDX License List's text, including with
the optional sections. As a result, no further action would be needed
to comply with the LGPL's condition that the GPL be included.
That's the source of the issue. License texts in SPDX have never been
designed to be used as a reference for attribution. This is
unfortunately commonly done but ends up more often than not with
garbled text because of the extra adornments, templating, commentaries
or placeholders present in SPDX texts.
MO, this should be clarified on the SPDX web site to avoid this trap.

Max:
The problem is simply that REUSE should not reuse the SPDX texts but
instead use its own reference texts. For instance, on my side we
maintain our own reference texts in ScanCode and AttributeCode for
attribution, and these texts have been cleaned from SPDX adornments,
comments, placeholders and similar.

Alternatively SPDX could add a new reference text for each tracked
license (when it differs from the existing text) which would be a
useful public service and would avoid the confusion we have today.
There you could have an LGPL+GPL thing, best combined with some extra
statement to clarify what the GPL text means here. And REUSE could
then use this alright

- License scanning tools following the SPDX License Matching Guidelines
would not be affected: as the entire GPL section is surrounded by
<optional> tags, existing occurrences of the LGPL text would still be
matched as LGPL, as has been the case thus far.
If you have a file that contains only the full text of the LGPL and
the full text of the GPL there is no way to disambiguate, matching
guidelines or not. This would throw off matching tools in a trap that
would entice them to return misleading results (possibly skipping
entirely the GPL) when using SPDX guidelines. Not sure we want this.

No tool could determine if we have these licenses:
- the LGPL with GPL text included for use in LGPL, e.g. a GPL with an
LGPL exception
- the LGPL AND the GPL separately, e.g. GPL with an LGPL exception AND a GPL

You need an extra statement, declaration, or notice to this effect.

You cannot even use an SPDX expression for this for now.
How could you sanely express something such as: "the text below is a
combination of the LGPL and GPL texts, but the license we meant to
document here is really only the LGPL. We included the GPL text
because it is included by reference in the LGPL and should be included
for redistribution".

<rant>
In hindsight the LGPL is a bad FOSS license text design since one must
include another text but the license does not include it by default.
It helps nobody: not the software authors, not the users, not
redistributors, nobody. It just requires extra busy work from everyone
involved and is a source of head scratching and doubt at best. It
could have been because programmers felt it was OK to "import" a
license text in another license text .... but a license text is not
software code. We have to deal with this mess, let's not make it
worse. I feel that the only sane thing at this stage would be to
requalify the LGPL-3.0 correctly as an exception to the GPL because
this is it.
</rant>

--
Cordially
Philippe Ombredanne
license texts janitor


Re: [spdx-tech] capitalization rules for SPDX license ids and operators

Philippe Ombredanne
 

Alexios, Jilayne:

On Thu, Jul 29, 2021 at 9:52 AM Alexios Zavras <alexios.zavras@...> wrote:
You can refresh your memory on the discussions (2015-2020) by reading https://github.com/spdx/spdx-spec/issues/63
I still like my example from that thread: Do we really want to be able to understand
Mit and gpl-2.0 And Gpl-1.0+ aNd ePl-1.0 aND isc
or can we simplify our lives and have one way of expressing the combinations?
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of J Lovejoy
However, please be aware that it is often important to match with the case of the canonical identifier on the SPDX License List. This is because the canonical identifier's case is used in the URL of the license's or exception's entry on the List, and because the canonical identifier is translated to a URI in RDF documents.
I'm wondering - was there a particular reason that the license expression operators are case-sensitive (while the license ids are not)?
IMHO it would be a good time to revisit this.
The case of license identifier does not and never did really matter
otherwise. It does not matter to users. And most tools do not care
either.
The tyranny of a serialization format (e.g. RDF) or a technical
requirement such as URL on a website should not impact everyone. These
should be solved differently.

What about adopting a simple way: define once for all that a canonical
license expression and identifier representation are either all
lowercase or all uppercase and be done with this topic for good.
--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombredanne@...
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com


Re: Combined version of LGPL + GPL 3.0

Alexios Zavras
 

Sebastian,

When you say "Nothing similar had been brought up before" are you talking about the inclusion of GPL text inside the LGPL one?

Because the whole thing "LGPL is an exception" and "needs GPL text" has been discussed at somewhat length:
https://github.com/spdx/license-list-XML/issues/956
(and then on a Legal call, as stated).

-- zvr

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Sebastian
Sent: Wednesday, 28 July, 2021 19:03
To: Spdx-legal@...
Subject: Re: Combined version of LGPL + GPL 3.0

Dear Jilayne,

Things have been moving really quickly on this, so I think I ought to give some background! I believe this to be a complete summary, though of course I don't know of the content of the Max's correspondence with the Free Software Foundation.

Last Saturday I was looking through the list of issues on the REUSE tool repository and noticed https://github.com/fsfe/reuse-tool/issues/86. The issue described is that the LGPL requires the full GPL text to be present for proper compliance, but REUSE does not allow unused license texts to be included in a given repository.

It occurred to me that this could be resolved in the SPDX License List instead of in REUSE - the entire GPL-3.0 could be added in an optional section below the LGPL-3.0. This would mean that:

- No SPDX License IDs would change. LGPL-3.0-or-later and LGPL-3.0-only
would still refer to a standalone license, and users would not need to
use the 'AND' syntax in SPDX documents or license expressions.

- Users of REUSE would simply need to download LGPL-3.0 via the REUSE
tool. The tool fetches the SPDX License List's text, including with
the optional sections. As a result, no further action would be needed
to comply with the LGPL's condition that the GPL be included.

- License scanning tools following the SPDX License Matching Guidelines
would not be affected: as the entire GPL section is surrounded by
<optional> tags, existing occurrences of the LGPL text would still be
matched as LGPL, as has been the case thus far.

I took the time to review the previous discussions about the LGPL in the past, both on SPDX's and REUSE's mailing list archives and GitHub repositories. Nothing similar to had been brought up before, as far as I can tell. Hence, I posted my idea in the reuse-tool GitHub issue and waited - not for long as it turned out!

Earlier this week, both Max and Matija agreed on that issue that it would be a good solution, and Max contacted the FSF about it.

Fast-forward to today, and I was just about to write to you and Steve Winslow to ask for this to be put on the agenda for the next Legal Team meeting. At that point I saw Max's note that the FSF had already released the combined text! Apologies if this caught you by surprise, Jilyane; the FSF's speedy publication certainly did for me! All my correspondence with Max is publicly visible on the aforementioned GitHub issue.

Sorry for the somewhat long post - hopefully I've been able to describe how this idea satisfies the REUSE requirement, whilst addressing the concerns about backwards compatibility for those using the existing identifiers, both for license matching and for licensing their own repositories.

If you or anyone else has any futher questions I'm more than happy to answer them here :)

Best wishes,

Sebastian





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


Re: [spdx-tech] capitalization rules for SPDX license ids and operators

Alexios Zavras
 

Hi Jilayne,

 

You can refresh your memory on the discussions (2015-2020) by reading https://github.com/spdx/spdx-spec/issues/63 😉

 

I still like my example from that thread: Do we really want to be able to understand

Mit and gpl-2.0 And Gpl-1.0+ aNd ePl-1.0 aND isc

or can we simplify our lives and have one way of expressing the combinations?

 

-- zvr

 

From: Spdx-tech@... <Spdx-tech@...> On Behalf Of J Lovejoy
Sent: Wednesday, 28 July, 2021 19:00
To: 'SPDX-legal' <Spdx-legal@...>; Spdx-tech@...
Subject: [spdx-tech] capitalization rules for SPDX license ids and operators

 

Hi Legal, Tech teams,

I just want to clarify my understanding of capitalization sensitivity for SPDX license ids and license expression operators:

Appendix IV states:
License expression operators (AND, OR and WITH) should be matched in a case-sensitive manner.

License identifiers (including license exception identifiers) used in SPDX documents or source code files should be matched in a case-insensitive manner. In other words, MIT, Mit and mIt should all be treated as the same identifier and referring to the same license.

However, please be aware that it is often important to match with the case of the canonical identifier on the SPDX License List. This is because the canonical identifier's case is used in the URL of the license's or exception's entry on the List, and because the canonical identifier is translated to a URI in RDF documents.


I'm wondering - was there a particular reason that the license expression operators are case-sensitive (while the license ids are not)?

Thanks!
Jilayne

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


Re: capitalization rules for SPDX license ids and operators

jroyer6308@...
 

I think I may have received this email in error.




On Wed, Jul 28, 2021 at 09:59 J Lovejoy <opensource@...> wrote:
Hi Legal, Tech teams,

I just want to clarify my understanding of capitalization sensitivity for SPDX license ids and license expression operators:

Appendix IV states:
License expression operators (AND, OR and WITH) should be matched in a case-sensitive manner.

License identifiers (including license exception identifiers) used in SPDX documents or source code files should be matched in a case-insensitive manner. In other words, MIT, Mit and mIt should all be treated as the same identifier and referring to the same license.

However, please be aware that it is often important to match with the case of the canonical identifier on the SPDX License List. This is because the canonical identifier's case is used in the URL of the license's or exception's entry on the List, and because the canonical identifier is translated to a URI in RDF documents.

I'm wondering - was there a particular reason that the license expression operators are case-sensitive (while the license ids are not)?

Thanks!
Jilayne

--

James L. Royer 

275 Turk Street, San Francisco, CA  94102  
E: jroyer6308@... | P: (415) 685-7030


Re: Combined version of LGPL + GPL 3.0

Sebastian Crane
 

Dear Jilayne,

Things have been moving really quickly on this, so I think I ought to
give some background! I believe this to be a complete summary, though of
course I don't know of the content of the Max's correspondence with the
Free Software Foundation.

Last Saturday I was looking through the list of issues on the REUSE tool
repository and noticed https://github.com/fsfe/reuse-tool/issues/86. The
issue described is that the LGPL requires the full GPL text to be
present for proper compliance, but REUSE does not allow unused license
texts to be included in a given repository.

It occurred to me that this could be resolved in the SPDX License List
instead of in REUSE - the entire GPL-3.0 could be added in an optional
section below the LGPL-3.0. This would mean that:

- No SPDX License IDs would change. LGPL-3.0-or-later and LGPL-3.0-only
would still refer to a standalone license, and users would not need to
use the 'AND' syntax in SPDX documents or license expressions.

- Users of REUSE would simply need to download LGPL-3.0 via the REUSE
tool. The tool fetches the SPDX License List's text, including with
the optional sections. As a result, no further action would be needed
to comply with the LGPL's condition that the GPL be included.

- License scanning tools following the SPDX License Matching Guidelines
would not be affected: as the entire GPL section is surrounded by
<optional> tags, existing occurrences of the LGPL text would still be
matched as LGPL, as has been the case thus far.

I took the time to review the previous discussions about the LGPL in the
past, both on SPDX's and REUSE's mailing list archives and GitHub
repositories. Nothing similar to had been brought up before, as far as I
can tell. Hence, I posted my idea in the reuse-tool GitHub issue and
waited - not for long as it turned out!

Earlier this week, both Max and Matija agreed on that issue that it
would be a good solution, and Max contacted the FSF about it.

Fast-forward to today, and I was just about to write to you and Steve
Winslow to ask for this to be put on the agenda for the next Legal Team
meeting. At that point I saw Max's note that the FSF had already
released the combined text! Apologies if this caught you by surprise,
Jilyane; the FSF's speedy publication certainly did for me! All my
correspondence with Max is publicly visible on the aforementioned
GitHub issue.

Sorry for the somewhat long post - hopefully I've been able to describe
how this idea satisfies the REUSE requirement, whilst addressing the
concerns about backwards compatibility for those using the existing
identifiers, both for license matching and for licensing their own
repositories.

If you or anyone else has any futher questions I'm more than happy to
answer them here :)

Best wishes,

Sebastian


capitalization rules for SPDX license ids and operators

J Lovejoy
 

Hi Legal, Tech teams,

I just want to clarify my understanding of capitalization sensitivity for SPDX license ids and license expression operators:

Appendix IV states:
License expression operators (AND, OR and WITH) should be matched in a case-sensitive manner.

License identifiers (including license exception identifiers) used in SPDX documents or source code files should be matched in a case-insensitive manner. In other words, MIT, Mit and mIt should all be treated as the same identifier and referring to the same license.

However, please be aware that it is often important to match with the case of the canonical identifier on the SPDX License List. This is because the canonical identifier's case is used in the URL of the license's or exception's entry on the List, and because the canonical identifier is translated to a URI in RDF documents.

I'm wondering - was there a particular reason that the license expression operators are case-sensitive (while the license ids are not)?

Thanks!
Jilayne


Re: Combined version of LGPL + GPL 3.0

Jonas Smedegaard
 

Quoting Max Mehl (2021-07-28 17:56:41)
~ J Lovejoy [2021-07-28 17:34 +0200]:
From a practical perspective: the LGPL-3.0 clearly states at the
top, "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." It is not uncommon for legal agreements to reference,
by title or URL, another document that is incorporated by such
reference. Thus, not actually including the text of GPL-3.0 does not
make the LGPL-3.0 incomplete.
That's interesting. If this was the case, the whole problem would not
exist. However, in the issue I've shared this was identified as a
problem by multiple persons.
Seems to me that these views are not contradictory but describes
different matters:

* SPDX lingo describes which licensing has been granted
* REUSE wants to know which license documents need to be included

Sensible to me is not to "correct" the LGPL-3-* licenses in SPDX to
embed (optionally or not) the full contents of the GPL-3, but instead to
extend metadata to state that LGPL-3 depends on GPL-3.

I.e. extend SPDX ontology with e.g. "spdx:licenseTextDependsOn".


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private


Re: Combined version of LGPL + GPL 3.0

Max Mehl
 

~ J Lovejoy [2021-07-28 17:34 +0200]:
On 7/28/21 9:08 AM, Max Mehl wrote:
Do I understand correctly that FSF still doesn't think of LGPL-3.0 as an
exception to GPL-3.0 (even though functionally and structurally it is)
and thus wants us all now to identify LGPL-3.0 as a conjunctive license
expression, using and?
Yes, that was a suggestion made by Matija in the discussion we've had.
It was turned down by FSF.
to clarify: the FSF turned down GPL-3.0* WITH LGPL-3.0* or
GPL-3.0* AND LGPL-3.0*
(as you understand it, not asking you to speak for the FSF)
From my understanding, they did not want to treat LGPL-3.0 as an
exception to GPL-3.0. So they turned down "GPL-3.0* WITH LGPL-3.0*".

"GPL-3.0 AND LGPL-3.0" as well as "GPL-3.0 OR LGPL-3.0" is no problem in
the REUSE space. You'd have both license texts in LICENSES/ which is
what is missing if you just mark files as LGPL-3.0.

Now, we have a concatenated version. The license effectively did not
change from my perspective, now it's just complete and intuitive. But
IANAL.
From a practical perspective: the LGPL-3.0 clearly states at the top,
"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."
It is not uncommon for legal agreements to reference, by title or URL,
another document that is incorporated by such reference. Thus, not
actually including the text of GPL-3.0 does not make the LGPL-3.0
incomplete.
That's interesting. If this was the case, the whole problem would not
exist. However, in the issue I've shared this was identified as a
problem by multiple persons.

I have seen, in practice, people include the text of both in the COPYING
and COPYING.LGPL files - which has made me take pause wondering - are
some files under one and some under another or is it really just
LGPL-3.0? Having an SPDX identifier in the actual files denoting
"LGPL-3.0*" takes care of any confusion there.
Ack that this method could create confusion. However, with the
combination of a concatenated version under "LICENSES/LGPL-3.0-only.txt"
and "SPDX-License-Identifier: LGPL-3.0-only" in the file header, I
cannot see any practical confusion.

Sure, the full GPL text is present in the LGPL...txt file, but given its
file name and the SPDX tag, it should be obvious what's meant.

I am afraid that compliance issues have been caused *before* this change
as the downloaded LGPL-3.0 license was not complete.
By compliance issues, do you mean compliance with the REUSE spec?

I guess the other point here is that - in my mind, using REUSE, as a
spec to provide license info, etc., should require SPDX and FSF to make
some kind of change. That seems a bit backwards.
Our understanding was that SPDX was unhappy with the current situation
but did not succeed in making the FSF change their treatment of LGPL in
either direction (exception or concatenation). That is why we went the
short informal route.

I acknowledge that this was not perfect given the backlash that comes up
here.

In any case, I think it's good to have the discussion with all
interested parties, even if we got to it in a 'round about way. ;)
Sure, that's also why I propose it here ;)

My availability in August will be close to zero though, but perhaps
Matija can chime in who was present in the call and a leading force
behind this anyway :)

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


Re: Combined version of LGPL + GPL 3.0

J Lovejoy
 

Hi Max

On 7/28/21 9:08 AM, Max Mehl wrote:
Do I understand correctly that FSF still doesn't think of LGPL-3.0 as an
exception to GPL-3.0 (even though functionally and structurally it is) 
and thus wants us all now to identify LGPL-3.0 as a conjunctive license 
expression, using and?
Yes, that was a suggestion made by Matija in the discussion we've had.
It was turned down by FSF.
to clarify: the FSF turned down GPL-3.0* WITH LGPL-3.0* or
GPL-3.0* AND LGPL-3.0*
(as you understand it, not asking you to speak for the FSF)


What is the implication of just LGPL-3.0 at this point, then? What 
happens in terms of backward compatibility for everyone already using 
that identifier?

I appreciate you looking into this, but it really would have helped to 
be involved.
We didn't think this was so controversial to be honest.
Having the discussion and getting input from the FSF isn't controversial. It's the order of events and mode of comms that is not ideal. :)

Again, my point of view is that this improves the situation for users,
especially those of REUSE: so far, when adding the LGPL-3.0 license from
SPDX to their repo for LGPL-3.0 licensed code, the license text was
incomplete as it required the GPL-3.0 license to be present as well.
That's unintuitive and would have required special clauses in tooling
like REUSE.

Now, we have a concatenated version. The license effectively did not
change from my perspective, now it's just complete and intuitive. But
IANAL.
From a practical perspective: the LGPL-3.0 clearly states at the top, "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."
It is not uncommon for legal agreements to reference, by title or URL, another document that is incorporated by such reference. Thus, not actually including the text of GPL-3.0 does not make the LGPL-3.0 incomplete.

I have seen, in practice, people include the text of both in the COPYING and COPYING.LGPL files - which has made me take pause wondering - are some files under one and some under another or is it really just LGPL-3.0? Having an SPDX identifier in the actual files denoting "LGPL-3.0*" takes care of any confusion there.

Please note that the official LGPL text by FSF has not been altered. The
concatenated version is an alternative format.

As had been discussed here before, LGPL more aptly belongs on the 
exceptions list to be used with the WITH operator.
Again, full ack. But my understanding was that SPDX did not want to go
this route as the license steward (FSF) does not consider it an
exception but a separate license.
That's pretty much right. I don't recall if we ever really asked FSF directly, to be honest!

In any case, any change like this is not inconsequential for existing 
users of SPDX and all scenarios need to be fully discussed (as we 
learned last time we made a major change in our identifiers for the 
FSF). Is this change initiated by REUSE or FSF?
I cannot speak for FSF, just REUSE and the FSFE, REUSE's coordinator.

REUSE obviously does not intent to change SPDX identifiers or cause
compliance issues. I, too, dislike the -only/-or-later special cases,
which is also why my motivation was to get rid of this special case that
two license texts for one license have to be shipped. 

I am afraid that compliance issues have been caused *before* this change
as the downloaded LGPL-3.0 license was not complete.
By compliance issues, do you mean compliance with the REUSE spec?

I guess the other point here is that - in my mind, using REUSE, as a spec to provide license info, etc., should require SPDX and FSF to make some kind of change. That seems a bit backwards.

In any case, I think it's good to have the discussion with all interested parties, even if we got to it in a 'round about way. ;)

Thanks,
Jilayne

Best,
Max



Re: Combined version of LGPL + GPL 3.0

J Lovejoy
 

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.

On 7/28/21 8:53 AM, J Lovejoy wrote:



On 7/28/21 4:35 AM, Max Mehl wrote:
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.

This is a problem. We already went down this road with having back-and-forth conversations with FSF (by way of Richard Stallman and John Sullivan) in 2018 when Richard Stallman wanted us to change the identifiers to be more clear about -only and -or-later. The mode of communication ended up being a mixture of off-list and on-list, which I never was very comfortable with and which made for a lot of extra work. I'm not in favor of repeating that.

If there is something that the FSF, REUSE, or any other community wants addressed related to SPDX identifiers, that conversation needs to begin here - on the open mailing list which anyone can join and for which all the archives are available.

I have copied John and Don on this email directly so they are aware.

I have moved the tech team to bcc - for general awareness, as any such change could impact tooling. Once a conversation is kicked off on this list, we can pull the tech team in at the appropriate time.

Thanks,
Jilayne






301 - 320 of 3278