The License Review Process

The goal of the OSI License Review Process is to ensure that licenses and software labeled as "open source" conform to existing community norms and expectations. For that reason, 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 license-review.

Purpose of the Process

• Ensure approved licenses conform to the Open Source Definition and provide software freedom
• Identify appropriate License Proliferation Category
• Discourage vanity and duplicative Licenses
• Ensure a thorough, transparent and timely review (e.g. within 60 days)

How to Submit a Request

1. Read the Open Source Definition and ensure that your license complies with it
2. Identify the type of submission (Retirement, Legacy Approval or Approval)
3. Ensure you have appropriate standing to submit the type of submission that you have identified
4. Subscribe to license-review (if you aren't already)
5. Submit a formal request to license-review.
6. The request email must include:
   • the submission type and license name in subject field (to ensure proper tracking)
   • a plaintext copy of the license
   • the supporting data listed below (as appropriate for the type of submission)
   • a link to earlier public discussions (if any)

Submission Types and Supporting Data

For Approval

Has appropriate standing: License Steward

Approval of completely new licenses, or licenses previously used by only a single entity

• Rationale: Clearly state rationale for a new license
• Distinguish: Compare to and contrast with the most similar OSI-approved license(s)
• Legal review: Describe any legal review the license has been through, and provide results of any legal analysis if available
• Proliferation category: Recommend which license proliferation category is appropriate

For Retirement

Has appropriate standing: License Steward

A request to retire the license. This request can only be made by the license steward. Note that successor licenses must be approved through the new license approval process.

• Version: Specify exactly which version is being retired
• Successor: Identify successor license(s), if any.

For Legacy Approval

Has appropriate standing: License Steward and Licensees

Retroactive approval of historic/legacy licenses that have already been extensively used by an existing community, but have not previously been approved.

• Rationale: Describe the nature and history of the existing usage.
• Proliferation category: Recommend which license proliferation category is appropriate

Decision Process

The OSI has adopted the guidelines below, which we aim to follow when reviewing licenses, to ensure that a license will be approved only if it conforms to the Open Source Definition and provides software freedom.

"Decision Date" for a license normally means (a) 60 days after a license is initially submitted to the license-review list for review, and (b) 30 days after submission of a revised version of a license that was previously submitted for review. A license is considered to be submitted for review if it follows the process set forth at https://opensource.org/approval. While we will try our best to adhere strictly to this 60/30 day Decision Date definition, circumstances may require us to extend the Decision Date further.

No later than the next available Board meeting after the Decision Date, the OSI will select one of four possible decisions:

1. Defer for another 30-day discussion cycle, if community discussion of conformance of the license to the OSD remains active.
2. Approve if, after taking into consideration community discussion, the OSI determines that the license conforms to the Open Source Definition and guarantees software freedom. A license may be approved on the condition that a change be made, but in general a license requiring changes will have to be resubmitted.
3. Reject if (a) the OSI determines that the license cannot practically be remedied to adequately guarantee software freedom, or (b) there is sufficient consensus emerging from community discussion that the license should be rejected for substantive reasons, or (c) the license is problematic for nonsubstantive reasons (for example, it is poorly drafted or significantly duplicative of one or more existing OSI-approved licenses).
4. Withhold approval, if (a) the OSI determines that approval would require reworking the license and (b) the license submitter appears willing and able to revise the license constructively.

Community discussion of submitted licenses takes place on the License Review mailing list. The submitter should participate in this discussion by replying to any questions asked or claims made about the license. The License Committee Chair will provide recommendations for decisions to the OSI board (and copy the License Review list).  The License Committee Chair will report the decision to the list. If a license is approved, the OSI website will be updated as appropriate.