The Open Source Initiative improves its licensing rules

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 be grammatically and syntactically clear to a speaker of the language of the license.

• Every possible variation of the application for the license must meet the OSD.

• It must be possible to comply with the license on submission. For example, given the scope of copyleft in MongoDB’s Server Side Public License (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.

As for legacy licenses, no suggestions for changes to the text of legacy licenses will be considered. Legacy licenses are licenses that have been used for at least five years by more than twenty projects maintained by different unrelated entities.

The Working Group also decided that the current categorization system of licenses, adopted to prevent license proliferation, 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.

The License Review Working Group also 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 licenses.

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

Why do all this? Because in the past, working through the OSI license standards to get a license approved has been confusing and difficult. With these new rules, everything should be clearer and easier.

In addition, although the OSI doesn't spell it out, it appears that the OSI wants to stop faux open-source licenses from wasting the OSI's time. Many such licenses sound like they're open source at first glance but actually restrict how you can use the software.

These include licenses that require business users to subscribe to a commercial license, such as MariaDB’s Business Source License; the SSPL, which restricts how the code can be used in a software-as-a-service (SaaS) cloud; licenses where you can only read the code but not change it such as the aptly named Read Only License; and the so-called ethical licenses that demand users object a particular set of ethical rules such as the Hippocratic License.

These are all very different, but at the end of the day, they all restrict how you can use a program and/or its code. The OSI started as an organization to defend its developer freedom first, and it will continue to do so for the foreseeable future.

The OSI will not, however, be offering specific license recommendations. That's beyond the group's ability and scope. If you want to know what's the best open-source license for you, find an open-source savvy lawyer and advisor.

Finally, neither the OSI nor the License Review Working Group will be delisting older or unused licenses. This issue may be taken up in the future.

Other noteworthy Linux and open-source stories:

• GitHub revokes stolen code-signing certs, invalidates some versions of Atom and GitHub Desktop for Mac

• helloSystem 0.8: A friendly, all-graphical FreeBSD

• Microsoft upgrades Defender to lock down Linux gear for its own good