Umpires of open source licenses

We need officials to rule whether code strikes out or hits a home run when it comes to open source licensing.

Image by:

Open source, like most areas of human endeavor, has institutions and rules that enable it to function. Recently, the open source community has been challenged regarding its licensing. Here's a scenario to illustrate the problem.

Imagine yourself at a baseball game and the pitcher decides he doesn't feel like throwing the ball that day, so he sets up a machine to do it instead. Fans on both sides would be thinking, "Is this a joke? This isn't baseball, what's going on here?" The umpire (referee) would stop the game and have the machine removed and probably the pitcher too. This is why leagues hire umpires to enforce the rules. They make sure the rules are obeyed to uphold the integrity of the game.

Now imagine a group of developers makes their source code publicly available. First, they license the code under a popular license like MIT or Apache. As time goes by and the software becomes more popular, the authors decide they need to edit the license to fit their business needs. They might still call it "open source" except the license may no longer qualify as such. The correct term may rather be "source available." (More on that in a bit.)

Many developers have the misconception that "if a project is on GitHub or GitLab, it's open source." However, without a license, the source code is, by default, subject to copyright and not open source. Even if a project has a LICENSE file, it could still be an imposter if it doesn't provide the rights outlined in the open source definition. This is why open source has established an umpire for open source licenses.

Is it OSI approved?

The Open Source Initiative (OSI) is probably the most widely accepted umpire of the open source community, with representation from a variety of people and company members. Like baseball umpires, they ensure open source licenses play by the rules. Licenses submitted to the OSI undergo a rigorous and sometimes lengthy review process in which members of the open source community debate whether a license meets the open source definition.

A project that uses a license that is not OSI approved but releases its source code might be considered "source available." Per Wikipedia, "source available software is software released through a source code distribution model that includes arrangements where the source can be viewed, and in some cases modified, but without necessarily meeting the criteria to be called open source" (emphasis added).

Here are some of the differences between the two:

How to choose an open source license

In the past, it was difficult to understand the differences between licenses. That is no longer the case. People have put together great resources to explain the differences between open source licenses and under what circumstances a particular license may be better than another. If in doubt or for complex scenarios, consult your lawyer. Here are some great resources regarding open source licenses:

How to strengthen open source

There is no reason to hold anything against source available software. However, it is important for us, as members of the open source community, to clearly understand the difference between "open source" and "source available" and which software is using OSI approved licenses or not. The OSI is the umpire here.

Notes for the developer community:

Realize that "source available" is not "open source."
Recognize that OSI-approved licenses are the foundation of open source.
Educate yourself on the open source definition to avoid losing rights through source-available licenses.
Choose carefully before contributing to projects that do not have an OSI-approved license.
Support the OSI by becoming a member. They are the ones on the front line defending the open source definition that many of us take for granted.
Talk about licensing and other open source issues on the Sustain Open Source Forum.

Thank you to sustainers Serkan Holat and Hank Grabowski for helping us with this post.