Why the Term "Open Source" is Important

As I get deeper into the Open Source world, I’ve noticed more and more misunderstandings and misrepresentations of Open Source. I touched on this in part in another recent post of mine.

One thing that often pops up is the labelling of “Open Source” even when non-Open-Source terms are clearly active. As of late I’ve started to call out such scenarios but, within an issue report, it’s tricky to relay why this isn’t just pedantry and why the application of the term is important. In this post I wanna dive into why I think it’s important.

Before you read any further I’d like to confirm that I am not a lawyer and the below is made up of my own opinion and understanding.

What is Open Source?

Not any freely available or public code is Open Source, but there are a set of conditions that your code or application must fall within, defined by the OSI (Open Source Initiative) which can be seen here: https://opensource.org/osd

This is the commonly known and understood technical definition of Open Source.

The OSI also performs the task of validating software licenses against the Open Source definition, providing a large set of common license options that you can use, and know to be Open Source, if you don’t want to go to the effort of writing your own license.

What is misunderstood?

Primarily the thought that any public distribution of the code is Open Source. Looking out across the software landscape, especially within the realm of web-based SASS offerings, it’s becoming increasingly common to see “Source Available” licenses used instead. These are generally licenses which provide access to the source code but come with extra restrictions. Let’s take the Elastic License 2.0 as an example of a “Source Available” license. While having many similarities to common Open Source licenses, this adds the following limitations:

You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software.

You may not move, change, disable, or circumvent the license key functionality in the software, and you may not remove or obscure any functionality in the software that is protected by the license key.

These limitations apply signification restriction to what can be done with the code, and actively conflicts with the 3rd and 6th OSI Open Source definitions:

  1. Derived Works - The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
  1. No Discrimination Against Fields of Endeavor - The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

So why does it matter?

Open Source assures a certain level of freedoms to code, and to the users of that code. When publishing software under an Open Source license, authors are making a commitment to those freedoms, often at a sacrifice to their own control and advantage. The author is generally putting the freedom of the code above that business/personal control & advantage.

When software is published under a license such as the Elastic License, or with extra conditions applied such as the commons clause, or with time-based conditions as used in the Business Source License, then often business/personal revenue & control interests are being put before the code itself. That’s not to say these kinds of license are bad at all, I totally respect the need to protect your efforts when building and sharing in the open, but they don’t offer the same freedoms as provided in Open Source. Many of these licenses even explicitly state they are not Open Source to help prevent confusion.

The term “Open Source” carries a lot of weight in the technical community and is often an important philosophy to those maintaining and providing software under that banner. Labelling any source-available project as “Open Source” only serves to fester confusion and blur the lines between what’s really open and what’s restrictive. As time goes on this confusion can propagate, diluting the term & the understood benefits of what “Open Source” brings.

It feels as if many simply use “Open Source” as a marketing term, riding on the reputation and benefits provided by that community without really serving the real meaning of the term, as if they want the benefits of “Open Source” without taking the same risks as everyone else. Seeing non-open-source projects get boosted and marketed under the term can be a punch in the gut to those genuinely building Open Source, especially when these sources are well-resourced VC funders that are able to propagate their misunderstanding through the wider media.