Back on February 3rd, 1998, shortly after the Netscape web browser source code –Firefox’s ancestor–was released, a group of developers came together to label and define a pragmatic, business approach to sharing software code. Of course, there was already “free software,” but that term, then and now, came loaded with a particular business/political take that not everyone cares for. So, it was that at the meeting Christine Peterson came up with the term “open source.” The group that would shepherd this idea going forward is the Open Source Initiative (OSI).
The OSI has done great work in defending open source, but getting new licenses approved has never been easy or simple. You see, open-source licensing is very complicated. So to help clear things up in 2020, the OSI formed a License List Working Group. Its job was to:
- Reevaluate the criteria for approving licenses, potentially setting different standards for licenses in use versus new licenses..
- Reevaluate the license approval process and should the OSI 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.
At the same time, the OSI was also investigating how to improve the license review tooling and process and how to inform people about open-source licenses better. As the endless arguments about open-source licenses show, this is a non-ending task.
So, what does this mean?
Moving forward, if you want to submit a new license, your license must:
- Comply with the Open Source Definition. In particular, you must specifically affirm it meets OSD 3, 5, 6, and 9. Historically, these are the points that have caused the most headaches.
- Identify what projects, if any, are already using the license.
- Identify the license steward. The OSI will contact the license steward if the 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 Free Software Foundation (FSF), or the Fedora Project could be count in its favor.
- Provide a unique name for the license. This should include the version number.
- Identify any proposed tags for the license (see below regarding tagging).
For new licenses, the license submitter must also:
- Describe what gap is not filled by currently existing licenses that the new license will fill. With dozens of approved open-source licenses, chances are your particular issue has already been covered.
- 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 cases, approval of a similar license in the past doesn’t bind the OSI to approve a newly submitted license.
Continuing on, besides the OSD, the proposed license must follow the below standards.
- 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 for the license.
- It must
