The License Review process

All licenses must go through a public review process described below.

The OSI Board is happy to consult with entities in advance to help them navigate the process and improve their license, but formal approval requires going through the License Review Process.

Purpose of the process

1. Ensure approved licenses conform to the Open Source Definition and provide software freedom
2. Discourage duplicative and poorly written licenses and those with unexpected requirements
3. Ensure a thorough, transparent and timely review (e.g. within 60 days)

Overview of the process

Submit the license to license-review mailing list

Someone who wishes to have a license reviewed and approved by the OSI submits the license to the license-review mailing list. Anyone can join the license-review mailing list and participate in the license review process. There is also a license-discuss mailing list; this is for discussion of Open Source in general and we also encourage license submitters to ask for advice on the license-discuss list before formally submitting a license to license-review.

To navigate the process, the license submitter should bear in mind that license approval is a consensus process. This means that no one person, including a Board member, has the authority to approve or reject a license nor require a change, no matter how strongly they may state their position.

Join the mailing list and follow the reviews

The person submitting the license must join the license-review mailing list. When a license is submitted for review, there are often questions for the license submitter. The license submitter should be attentive and responsive to those questions. If they are not, we will assume that they are not interested in participating in the process and the license will be at high risk of rejection.Once a license is submitted, anyone wishing to comment on it will comment on the license-review list.

There are likely to be all different kinds of comments made during the license review process. Some of the comments may impact whether the license will be approved and some may not. There might be observations not relevant to approval; praise or criticism of the writing style or policy choices in the license; ideological statements about the license or the OSI’s approval policies more generally; or an explanation why the license fails to meet the requirements for approval. Some discussions can get quite lengthy.

Board members and employees of OSI may participate in license review in their individual capacity. When participating in their individual capacity, they are expected to use a non-OSI email address. 

Reacting to comments, issuing new license versions

There will often be suggestions made for changes to the license. Suggestions are only that; the license submitter should not feel obligated to change the license, although it might be wise to do so if comments are pointing out a reason why the license is unlikely to be approved. However, a license cannot be changed while it is being considered.

If the license submitter would like to change the language of the license, the current version of the license should be withdrawn from review and an updated version submitted. We recommend that, if changes are going to be made, that the license submitter wait and collect all the desired changes in a single new submission rather than withdrawing and resubmitting the same license several times.

Reaching consensus for a decision

The “Decision Date” for a license normally means (a) 60 days after a license is initially submitted to the license-review list for review, or (b) 30 days after submission of a revised version of a license that was previously submitted for review, provided that date is no earlier than 60 days after the original license was submitted. While we will try to adhere to this 60/30 day Decision Date definition, circumstances may require us to extend the Decision Date further.

The License Committee observes the ongoing discussion to determine whether it has reached a conclusion and whether there is consensus on approving or rejecting the license. If there is not yet consensus, the License Committee will ask for further discussion in an effort to reach consensus. This process may require that the Decision Day be further extended.

Issuing the final decision

Upon reaching a consensus, the License Committee Chair will provide recommendations for approval or rejection to the OSI board, copying the License Review list.

The Board will then vote on whether to adopt the recommendation of the License Committee. The License Committee Chair will report the Board’s decision to the list. If a license is approved, the OSI website will be updated as appropriate.

How to submit a request

Licenses being submitted will either be a “legacy” license or a “new” license. 

A “legacy” license is one that has been in use for at least five years by more than twenty projects maintained by different unrelated entities.

A “new” license is any license that is not a legacy license.If it is a family of licenses, each license must be submitted separately.If the license is in a language other than English, the license submitter must provide a certified translation into English.

Request for approval of a legacy license

Who may submit a request: Anyone

The license submitter must:

• Submit a copy of the license as an attachment in simple text format.
• Affirmatively state that the license complies with the Open Source Definition, including specifically affirming it meets OSD 3, 5, 6 and 9.
• Identify what projects are already using the license.
• Provide the identity and contact details of the license steward, if known, and of the submitter. The OSI will try to get in touch with the license steward if the license submitter is not the steward.
• Provide any additional information that the submitter believes would be helpful for license review. For example, approval of the license by Debian, the FSF or the Fedora Project would be relevant to the review process.
• Provide a unique name for the license, preferably including the version number.
• If any exist, provide the unique identifier by other projects, like SPDX or ScanCode.
• Identify any proposed tags for the license (when available; see below regarding tagging).

Request for approval of a new license

Who may submit a request: Anyone, but the License Steward is preferred. The submitter must be a natural person, ideally on behalf of the License Steward, if the latter is an organization.

In addition to the information required for a legacy license, the license submitter must:

• Describe what gap not filled by currently existing licenses that the new license will fill.
• Compare it to and contrast it with the most similar OSI-approved license(s).
• Describe any legal review the license has been through, including whether it was drafted by a lawyer.

License approval standards

It is not possible to comprehensively list all reasons that a license may or may not be approved. Software changes and the role that a license plays in it might change. There will be times when a license presents an issue never considered before. Members of the license-review list are highly skilled, experienced, and deeply involved in Open Source software. Their consensus that a license does not ensure software freedom may, in some cases, be the justification for rejecting a license even where they cannot identify a specific aspect of the OSD or the approval guidelines below that is not met.

Approval of a license with the same or similar terms in the past does not bind the OSI to approval of a newly submitted license.

Standard for legacy licenses

The license must meet the Open Source Definition. No suggestions for changes to the text of legacy licenses will be considered. The license will be approved, or not, as written. The historical context of the license and the common understanding of its meaning will be considered when deciding whether it can be approved. 

Standard for new licenses

In addition to meeting the Open Source Definition, the following standards apply to new licenses:

1. The license must be reusable, meaning that it can be used by any licensor without changing the terms or having the terms achieve a different result for a different licensor.
2. The license does not have terms that structurally put the licensor in a more favored position than any licensee.
3. To the extent that any terms are ambiguous, the ambiguity must not have a material effect on the application of the license. 
4. The license must be grammatically and syntactically clear to a speaker of the language of the license. 
5. Every possible variation of the application of the license must meet the OSD.
6. It must be possible to comply with the license on submission. As an example, given the scope of copyleft in the Server Side Public License (SSPL), it is not a license that anyone currently would be able to comply with.
7. The license must fill a gap that currently existing licenses do not fill.
8. The text must be the complete license; overlays like Commons Clause and exceptions like ClassPath will not be approved in isolation from the license they modify.

Read the common restrictions that have not been approved, and the reason why they are not approved.

License Tagging

The OSI is planning to use a tagging system to identify attributes of both currently existing licenses and licenses being submitted. The list of such tags is not yet available.