The License Review Process
Contents
The License Review Process¶
The goal of the 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.
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¶
Read the Open Source Definition and ensure that your license complies with it
Identify the type of submission (Retirement, Legacy Approval or Approval)
Ensure you have appropriate standing to submit the type of submission that you have identified
Subscribe to license-review (if you aren’t already)
Submit a formal request to license-review.
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:
Defer for another 30-day discussion cycle, if community discussion of conformance of the license to the OSD remains active.
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.
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).
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.