The License Review working group asks for community input on its recommendations

Some time ago the Open Source Initiative formed a working group to examine and improve the license review process. The stated purpose of the working group was to:

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

The OSI has a parallel undertaking investigating how to improve the tooling that will be used for the license review process and also how to best serve the public in the ways we provide information about Open Source licenses. Although the tooling project and the work of the License Review Working Group are intertwined, the below conclusions of the License Review Working Group are focused on the requirements and policy that will inform the tooling project, but do not include the tooling project itself.

The License Review Working Group was originally scoped to discuss the delisting of licenses, but we did not reach the topic. It is a challenging subject because it means that the OSI first needs to learn who is using the licenses that may be considered for delisting and understand what effect it might have on them if their license undergoes a change in status. We therefore eliminated this topic from the mandate of this working group and recommend that it be taken up by a new working group dedicated to this subject alone.

Recommendations of the License Review Working Group for discussion.

Legacy licenses – 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.

New licenses – a “new” license is any license that is not a legacy license.

License submission process

We have received feedback that it is very difficult to navigate the review process because it is not clear the role of the license-review email list and its relationship to the OSI. License submitters do not know how much weight to give to the comments made on license-review. The OSI will provide more explanation for the public on the decision making process and in particular the role of the license-review list participants.

For all licenses, the submission process will:

• Require 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).
• Identify what projects are already using the license, if any.
• Ask for the identity of the license steward, if known. 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)
• Identify any proposed tags for the license (see below regarding tagging).

For new licenses, the license submitter will also

• 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.
• 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.

In both categories, approval of a similar license in the past does not bind the OSI to approval of a newly submitted license.

License approval standards

New licenses

In addition to meeting the OSD, the following standards apply to new licenses:

• 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.
• The license does not have terms that structurally put the licensor in a more favored position than any licensee.
• To the extent that any terms are ambiguous, the ambiguity must not have a material effect on the application of the license.
• It must be grammatically and syntactically clear to a speaker of the language of the license.
• Every possible variation of the application of the license must meet the OSD.
• It must be possible to comply with the license on submission. As an example, given the scope of copyleft in the SSPL, it is not a license that anyone currently would be able to comply with.
• The license must fill a gap that currently existing licenses do not fill.

Legacy licenses

The license must meet the OSD. 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.

License categories

The Working Group has decided that the current categorization system of popular licenses and all approved licenses, adopted to prevent license proliferation, was very beneficial when it was adopted but is no longer needed for the purpose. 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. The OSI intends to crowdsource volunteers for both creating a list of tags and adding the tags to the licenses and will be seeking volunteers for that task as the next stage of the project.

In order to continue the success of the anti-proliferation work, the License Review Working Group proposes, in addition to tagging, three categories of licenses:

• Rejected. This category is for licenses that have been considered and rejected.
• Approved. This category is for licenses that meet the minimum standard to be an OSI-approved license.
• Preferred. This is conceptually what the category “popular and widely-used or with strong communities” was designed to fill. The intent is that this category will be objectively created from data using adoption metrics and also a quality filter that is tagging-based. For example, a required forum provision in a license is not a disqualifier, but it is disfavored. A license with a required forum provision might not pass the filter.

Work that the OSI will not undertake

The OSI will not recommend licenses, other than categorizing as above, and will not try to provide advice on what licenses should be adopted for any particular use case. It would require resources that the OSI does not have to create and maintain this complex information. It is also an area that generally requires the services of lawyers or open source advisors, who can engage more deeply with projects or companies in order to provide them with advice specific to their needs and desires

To collect feedback on this proposal, we’re going to use annotations on the wiki. You will need to register to leave a comment. Highlight the text, hit CTRL-M, type your comment, save the annotation. More information on Xwiki help. The OSI will keep the discussion open for four months.