Create OSI-SPDX-history.md #1738
Conversation
beginning commit for background and logging issues that were (or were not) from when SPDX sought to include every OSI-approve license on the SPDX License List More research and commits are needed, and will take time! Signed-off-by: Jilayne Lovejoy
|
|
||
| * GPL-3.0-with-GCC-exception | ||
|
|
||
| what is the quesiton here? |
There was a problem hiding this comment.
@richardfontana explained the background of the WITH IDs:
You list some cases of 'WITH' expressions. The OSI has been reluctant to approve license exceptions, except in a few special cases where the exception (or exception coupled with a standard license) is itself thought of as a single license (e.g. LGPL version 3; ec0s-2.0 is also like this). From my recollection of my time on the OSI board, the main concern was the potential numerosity of license submissions if the OSI encouraged submission of exceptions. There's been a tendency to assume that typical types of GPL exceptions are legit (for a GPL-world notion of legit) because they conform to the model of a grant of additional permission -- I need to comment on this issue on another recent thread.
That would resolve my issue with this ID as I can assume that an official SPDX expression containing with is very likely OSI-approved.
There was a problem hiding this comment.
I don't think "OSI-approved" is the correct concept here. Rather, historically, the OSI might have informally said that "normal" (additional-permission-style) GPL exceptions are probably OSD-conformant. There's no formal sense in which OSI has approved anything other than the licenses it has approved through its license approval process.
Also, I don't think you can make this general assumption going forward, because in a recent mailing list thread @jlovejoy has clarified (unless I misunderstood) that SPDX is not, or no longer, strictly tied to an understanding that "exceptions" (the right side of a WITH expression) must be limited to additional permissions. This came out of some interest in exploring SPDX recognition of a currently-hypothetical exception type that would involve imposition of clearly-non-FOSS restrictions on top of FOSS license terms. In the past, SPDX has rejected inclusion of an exception identifier for the Commons Clause but I believe this was prior to SPDX's adoption of its current license incluson criteria.
|
|
||
| * LGPL-2.0 | ||
|
|
||
| this is a deprecated SPDX license id, not sure what the question is here? |
There was a problem hiding this comment.
Ah, that generelly refers to LGPL-2.0*. There is no mention of this license on OSI's list, though an unlinked website exists. So it's unclear whether this license is approved.
|
|
||
| - Many mismatches in GPL/LGPL/AGPL because of -only/-or-later/+. I unified those | ||
|
|
||
| what do you mean my mismatches? and "unified those"? |
There was a problem hiding this comment.
Yes sorry, that was unclear. Of the GPL family, I treated -only, -or-later, and + the same as OSI does not use these. It just means that I did not look for GPL-2.0-or-later on OSI's website, but just for GPL-2.0. Effectively I found LGPL-2.0 as missing (see the comment above).
| Suggestion: Update the [eCos](https://opensource.org/licenses/eCos-2.0) page to use the current `eCos-exception-2.0` identifier and change the URL to https://opensource.org/licenses/eCos-exception-2.0. Clarify what versions of GPL it is approved for. | ||
|
|
||
| ## Licenses that allow for variations by way of a different license notice | ||
| These are licesnes that were approved by the OSI in full. These licenses allow legally substantive variations based on use of a different license notice. This variataion warranted distinct SPDX identifiers to indicate whether or not the allowed variation is being triggered. All of these variations include a Note in the SPDX License List entry explaining this. |
beginning commit for background and logging issues that were (or were not) from when SPDX sought to include every OSI-approve license on the SPDX License List
More research and commits are needed, and will take time!
Signed-off-by: Jilayne Lovejoy