How the OSI checks if new licenses comply with the Open Source Definition

Earlier this month, we announced completion of the project to review the list of Approved Licenses. The Open Source community needs a resource to confidently and easily identify OSI-approved licenses, and now we have it. This approval registry offers a comprehensive and authoritative listing of all licenses so organizations know that the license they choose for their project allows their software to be freely used, modified, shared and monetized in compliance with the Open Source Definition.

But how do we check the compliance of new licenses with the Open Source Definition? The License Review Working Group was formed to examine ways to improve the license review process, with the stated purpose of evaluating or reevaluating:

• the criteria for approving licenses, potentially setting different standards for licenses in use versus new licenses
• the process for considering licenses for approval, including whether the OSI should itself nominate licenses for approval
• the current categories for licenses, including how they are used and their usefulness
• whether there should be a process for decertifying licenses, and what the process and standards would be for the process

(Originally, the group was scoped to examine the process of delisting licenses, but it delegated this topic to a separate working group.) 

One important output of the License Review Working Group was defining the difference between a legacy license and a new license. A legacy license is now defined as one that has been in widespread use for at least five years by a number of different unaffiliated entities. New licenses are, by definition, all other licenses. 

The updated license review process is now live and below are the most important changes.

License submission process

The group took on the license submission process, focusing on the difficulty in navigating the review process. The role of the license-review email list and its relationship to OSI is clarified with more explanation on the decision making process, in particular the role of the license-review list participants.

The new submission process clarifies the difference in process between new licenses and all licenses. For all licenses, the submission process requires that the license submitter affirmatively state that the license complies with the Open Source Definition, including specifically affirming it meets OSD 3, 5, 6 and 9 (the points that historically have been more problematic). They must identify what projects are already using the license, if any, and ask for the identity of the license steward, if known. The OSI will try to get in touch with the license steward if different from the license submitter. Submitters must provide any additional information believed to be helpful for license review, as well as a unique name for the license (preferably including the version number) and an SPDX identifier if one already exists. Finally, all license submitters must identify any proposed tags for the license.

For new licenses, the license submitter will also be asked to describe what gap is not filled by currently existing licenses that the new license will fill. Specifically, they must compare it with the most similar OSI-approved license(s). They must describe any legal review the license has been through, including whether it was drafted by a lawyer, and provide examples of others’ potential use of the license to demonstrate that it is not a license that is uniquely usable only by the license submitter.

For both categories (new licenses and all licenses), approval of a similar license in the past does not bind the OSI to approval of a newly submitted license.

Approval standards

The License Review Working Group also developed approval standards for new and legacy licenses and clarified that the current categorization system of popular licenses and all approved licenses is no longer needed. Rather than continuing the current categorization of licenses, the OSI plans to adopt a tagging system for licenses. These tags will aid third parties in identifying licenses suitable for their use case.

In order to continue the success of the anti-proliferation work, the License Review Working Group proposed three categories of licenses: Rejected, Approved, and Preferred. 

In short, a great deal of time and effort went into the careful examination of many issues, and the support of and commentary from the community were invaluable in reaching a set of recommendations that were approved by the board. If you’re interested in the deliberations and details, you can read more at the License Review Working Group wiki.

Next steps

We’re planning to further improve for the license review process by introducing new tools to discuss the text of the licenses. Recognizing that holding conversations over email is uncomfortable for all actors, we’re designing a better system. Stay tuned for more changes.