Missing SPDX identifier data

[goneall]

The following SPDX identifiers are not in this repo/JSON file but are listed on the OSI website:

• 0BSD
• BSD-2-Clause-Patent
• BSD-1-Clause
• BSD-3-Clause-LBNL
• CAL-1.0
• EPL-2.0
• EUPL-1.2
• CECILL-2.1
• OLDAP-2.8
• PHP-3.01
• MIT-0

The SPDX license ID on the website is incorrect for the following:

• Licence Libre du Québec – Réciprocité forte (LiLiQ-R+) version 1.1 (LiliQ-R+) - should be (LiLiQ-Rplus-1.1)
• Licence Libre du Québec – Réciprocité (LiLiQ-R) version 1.1 (LiliQ-R) - should be (LiLiQ-R-1.1)
• Licence Libre du Québec – Permissive (LiLiQ-P) version 1.1 (LiliQ-P) - should be (LiLiQ-P-1.1)
• Universal Permissive License (UPL) - should be (UPL-1.0)

The following licenses are listed by name on the OSI website but are missing the SPDX identifiers:

• CERN Open Hardware Licence Version 2 - Permissive (CERN-OHL-P-2.0)
• CERN Open Hardware Licence Version 2 - Weakly Reciprocal (CERN-OHL-S-2.0)
• CERN Open Hardware Licence Version 2 - Strongly Reciprocal (CERN-OHL-W-2.0)
• Mulan Permissive Software License v2 (MulanPSL-2.0)
• OSET Public License version 2.1 (OSET-PL-2.1)
• Upstream Compatibility License v1.0 (UCL-1.0)
• The Unlicense (Unlicense)
• Unicode Data Files and Software License (Unicode-DFS-2016)

Although not an inconsistency between the website and this file, I would also like to add some additional SPDX identifiers to the GPL family of licenses. Per request from the Free Software Foundation a couple years ago, we added license identifiers with a suffix "-or-later" to the GPL and LGPL family of licenses. If would be nice if we added those identifiers to this JSON representation. It may also make sense to add them to the website.

[webmink]

Anticipating some more pull requests for the remaining items raised, which I'll add as they arise.

[goneall]

@webmink I added PR #69

I'm wondering if multiple PR's are going to create merge conflicts. I'm going to wait until 0BSD is merged before adding any more PR's in case the current process causes conflicts.

[webmink]

OK. Hopefully we'll be caught up in the next few days!

[goneall]

@paultag You may want to re-open this issue since there are several additional ID's that need to be added. I'll work on those next now that we have PR #65 merged.

[goneall]

I just put in PR's for all remaining SPDX identifiers are not in this repo/JSON file but are listed on the OSI website.

Note CECILL-2.1 was already there - so no need for a PR.

Once these are merged, I'll create PRs for the remaining issues.

[webmink]

Since licensing matters are ultimately overseen for OSI by @pchestek I'm adding her to all of them as an approver. Once she's given us the nod either I or @paultag will merge them.

[goneall]

@paultag @webmink Several of the licenses present on the website with missing SPDX id's are not present in this repo.

Would you like me to create a PR which adds the licenses along with the SPDX ID's missing from the website or did you want to sync up this repo with the website content?

Below is the list of licenses I found on the website without corresponding text in this repo:

CERN Open Hardware Licence Version 2 - Permissive (CERN-OHL-P-2.0)
CERN Open Hardware Licence Version 2 - Weakly Reciprocal (CERN-OHL-S-2.0)
CERN Open Hardware Licence Version 2 - Strongly Reciprocal (CERN-OHL-W-2.0)
Mulan Permissive Software License v2 (MulanPSL-2.0)
Upstream Compatibility License v1.0 (UCL-1.0)
The Unlicense (Unlicense)
Unicode Data Files and Software License (Unicode-DFS-2016)

[richardfontana]

The SPDX license ID on the website is incorrect for the following:

@goneall in general it is incorrect to say these are errors. I am responsible for a few of those cases as I was on the OSI board at the time of the license approval. The case I remember pretty clearly is that of the Licence Libre du Québec licenses. The abbreviations you mention are the ones used by the license steward in the course of making their license submission and (IIRC) reflected in the license texts themselves. At the time, we weren't trying to root out all possible forms of referring to OSI-approved licenses in abbreviated form other than using SPDX identifiers. It's sort of like saying any mention of "GPLv2" is incorrect because "GPLv2" is not an SPDX identifier. Different or alternative system of license abbreviation != "incorrect". It's possible that since the time I left the OSI board the OSI has chosen to more ambitiously or consistently promote use of SPDX identifiers.

[goneall]

@goneall in general it is incorrect to say these are errors.

@richardfontana I'm not commenting on the OSI ID's, I'm specifically referring to the SPDX identifiers on the OSI website.

On the License Listed Alphabetically, the following description of the list is provided:

The following licenses have been approved by the OSI. The parenthesized expression following a license name is its SPDX short identifier (if one exists).

Looking at the SPDX Id's specifically, I found the inconsistency with the SPDX ID's on the SPDX listed license pages.

For example, the following appears on the OSI page:
Licence Libre du Québec – Réciprocité forte (LiLiQ-R+) version 1.1 (LiliQ-R+)

while the SPDX license list has:
Licence Libre du Québec – Réciprocité forte version 1.1 | LiLiQ-Rplus-1.1

Since the OSI web page specifically mentions the SPDX ID for the ID in parenthesis following the name, I would expect the ID to match the SPDX listed license ID. Let me know if you disagree.

[richardfontana]

Since the OSI web page specifically mentions the SPDX ID for the ID in parenthesis following the name, I would expect the ID to match the SPDX listed license ID. Let me know if you disagree.

@goneall you are correct, I misunderstood. Given that you can see the care with which BSD+Patent is handled on this list (with "BSD-2-Clause-Patent" as the parenthesized identifier) I can't explain what happened with the other cases.

[kopeboy]

Any update on this?! I was trying to import the list of OSI-approved licenses to my platform but the link for the JSON in the readme (which is not even https) is not consistent with the info on OSI website.. this is either outdated or a critical bug imho.
I liked the "keywords" you provide to be able to filter, but I guess importing from SPDX is much safer since their repository seems maintained and api + website implementations are consistent.

[goneall]

@kopeboy - I was waiting for PR #82 to be merged before making any additional changes.

@webmink - Any progress on the PR?

[webmink]

Done.

[goneall]

Thanks @webmink

@kopeboy - I have some major release for some SPDX tools this week, but I'll try to get to the other PR's.

BTW - feel free to create PR's for these yourself if you'd like to move these along more quickly - we're all just volunteers ;)