This document contains a history of the SPDX License List and OSI-approved licenses, as well as some outstanding issues.
(last update: August 5, 2024)
In the first releases of the SPDX License List, it was determined that the SPDX License List should include all licenses that were ever OSI-approved - a policy that SPDX-legal maintains to this day. The rationale being that once OSI-approved, always OSI-approved and that even old or "OSI-deprecated" licenses may still appear "in the wild".
Note: the OSI and SPDX use the term "deprecated" in different ways. To avoid confusion, this document differentiates by using "OSI-deprecated" or "SPDX-deprecated" for clarity.
In 2011, OSI began using the SPDX license identifiers in URLs and on the license pages.
The SPDX-legal team sought to accurately identify all OSI-approved licenses and their corresponding text to ensure representation on the SPDX License List. This involved cross-collaboration between SPDX-legal and various OSI representatives, with most communication occurring on the SPDX-legal mailing list, OSI's license-disucss mailing list, or both. John Cowan, Martin Michlmayr, Karl Fogel, and Luis Villa were among the OSI board members who helped Jilayne Lovejoy from SPDX-legal on researching the various issues.
This page seeks to explain some of the challenges that this reconciliation work encountered, especially where a solution to the challenge may still leave questions for people currently looking at or using both the SPDX License List and the OSI list of approved licenses. Any suggestions that had been made in the past but not implemented or that would aid in clarifiction have been included here as well.
Over time, the OSI began more actively reviewing licenses and the website got updated in various ways; and SPDX adopted new policies, such as the license expression syntax. As a result, other issues have appeared in terms of "matching" the licenses that appear on both lists. More recent issues may be captured in this repo (using the "OSI related" label) or in an OSI repo, such as OpenSourceOrg/licenses#62 .
The following old or "OSI-deprecated" licenses were confirmed by the OSI as having been OSI-approved, even though these licenses do not or may not (readily) appear on the OSI website any longer:
AFL-1.1AFL-1.2AFL-2.0AFL-2.1APSL-1.2OSL-2.0
See SPDX-legal email list from April 2012 here and here for confirmation of these licenses having been OSI-approved.
Suggestion for OSI: Consider listing all licenses ever approved on OSI website to retain a full historical record (even if noted as superceded).
The OSI explicitly approved two variants of Artistic License 1.0 as stated at the top of the page: with clause 8 and without. Because the presence or absence of clause 8 presents a substantive difference, SPDX added them as two separate licenses.
In the course of this research, it was discovered that the text for the Artistic License 1.0 that was listed on the OSI website did not match the text of the Artistic License used by Perl, which has 10 clauses, clause 5, 6, 7, and 8 being different from those on the OSI site. It is still unclear to this day what was originally submitted to OSI or where the text at https://opensource.org/licenses/Artistic-1.0 (either with or without clause 8) has been used in actual code.
As a result SPDX added 3 licenses to accommodate these variations:
Artistic-1.0Artistic-1.0-cl8Artistic-1.0-Perl
OSI added a separate page for Artistic-1.0-Perl but the notation describing the variant is still confusing.
Suggestion for OSI: OSI add the SPDX ids, Artistic-1.0 and Artistic-1.0-cl8 to this page and update the notation to something like, “OSI approved this variant of Artistic License 1.0, (Artistic-1.0) with 9 clauses, as well as a variant that contains an additional clause 8 (Artistic-1.0-cl8). There is also the variant used by Perl (Artistic-1.0-Perl), which has differences from the text here in clauses 5, 6, 7 and 8.”
And add the SPDX id, Artistic-1.0-Perl on this page and update that note accordingly as well.
These SPDX licenses have an explanation, as appropriate, in the Note field.
In at least two cases, the OSI approved a license exception with an SPDX id that is not current:
- eCos License version 2.0 and lists the SPDX identifiers as
eCos-2.0 - wxWindows Library License and lists the SPDX identifier as
wxWindowsThis is probably because these licenses were originally on the SPDX License List as a stand alone licenses. However, when SPDX 2.0 came out in May 2015, exceptions were moved to their own part of the SPDX License List to be used with theWITHoperator to allow more extensible and varied license expressions, see https://spdx.org/licenses/eCos-2.0.html and now see https://spdx.org/licenses/eCos-exception-2.0.html and https://spdx.org/licenses/wxWindows.html and now see https://spdx.org/licenses/WxWindows-exception-3.1.html
Question: OSI has the GPL-2.0-or-later license notice on its page for the eCos exception, which would use the SPDX license expression: GPL-2.0-or-later WITH eCos-exception-2.0. Did OSI only approve this exception for GPL-2.0-or-later?
Suggestion for OSI: Update the pages to use the current SPDX identifier for the exception (or the full SPDX license expression). Clarify what versions of GPL it is approved for.
These are licenses that were approved by the OSI in full. These licenses allow legally substantive variations based on use of a different license notice (but with the same license text). 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.
CAL-1.0-Combined-Work-ExceptionMPL-2.0-no-copyleft-exceptionOFL-1.1-no-RFNOFL-1.1-RFN- GNU license family, see OpenSourceOrg/licenses#87
Suggestion for OSI: OSI could add the variant SPDX ids to the license pages, and perhaps some kind of notation about the variants that use the same license text.
- Jabber Open Source License - This is a case where the text on the OSI site is not the same as the archived text at http://archive.jabber.org/core/JOSL.pdf SPDX would consider these two texts as different licenses, and was trying to clarify with the OSI which text was submitted and approved by OSI. Martin Michlmayr and Jilayne discussed this back in 2013 (https://lists.spdx.org/g/Spdx-legal/topic/22080295#475), but never reached a resolution. Jilayne emailed the OSI Board about this issue in July 2019.
Suggestion: SPDX could recognize both variants on the SPDX License List and note the one that is specifically OSI-approved. This would require clarification from OSI as to which one was approved and make any updates to its site accordingly. If both variants were OSI-approved, then a new entry would be warranted on the OSI site and on the SPDX License List.
- CVW: MITRE Collaborative Virtual Workspace License - Needs further research as to when it was OSI approved and how it didn't get on SPDX License List.
- OCLC-2.0 - see https://spdx.org/licenses/OCLC-2.0.html - is marked as OSI-approved on SPDX License List
- https://opensource.org/license/python-2-0 uses the right SPDX id in the URL (which is from many years ago), but has the wrong SPDX on the actual page text