Opinion Way back when we loaded software with punch cards and magnetic tape, all programs were “free software” and “open source.” Then along came proprietary software, and everything changed. But programmers rebelled and developed the first formal definitions of free and open source software.
Today, code that’s not open source is the rare exception. But that hasn’t stopped companies who mistook open source as a business model instead of a development model from trying to combine proprietary methods with “open source” code. The latest is Sentry’s Functional Source License (FSL).
Following in the tradition of Server-Side Public License (SSPL), Common Clause, and the Business Source License, the FSL nods at the importance of open source while sneering at its heart by claiming its approach is “Freedom without Free-riding.”
Please.
Sentry is a developer-oriented app code monitoring service that began as a short bit of code for Django, the open source, high-level Python web framework. Today, it’s still used most for open source code development. Without open source, Sentry doesn’t exist.
Neither do any of the companies now using “source-available” or other semi open source licenses. They all began as open source companies, then to maximize profits, they relicense the code they’ve gotten for free from contributors to lock down the code.
As Thierry Carrez, vice chair of the Open Source Initiative (OSI) board, told me, “Some companies have built their software by leveraging the body of open source code available to them, without having to ask for permission before using hundreds of open source packages in their dependencies. They built their reputation by publicly committing to the open source principles. But in a short-sighted effort to capture incrementally more value, they later decide to abandon the model that made them successful in the first place.” Exactly so.
Sentry, MariaDB, Redis, and HashiCorp, to name a few of the former open source companies, can get away with this thanks to rights-aggressive Contributor License Agreements (CLA)s. These are legal documents that define the terms contributors grant for their code to be used in an open source project. While some CLAs, such as the Apache Software Foundation’s CLA or Linux’s Developer Certificate of Origin, are used simply to protect the legal rights of their projects, others are used to grab your code and its copyright, such as MongoDB’s contributor agreement. With these CLAs, the companies can then use and relicense your code in any manner they like.
As Drew Devault, the founder and CEO of SourceHut, said about Elasticsearch and its move from open source to source available, “Elasticsearch belongs to its 1,573 contributors, who retain their copyright, and granted Elastic a license to distribute their work without restriction. This is the loophole which Elastic exploited when they decided that Elasticsearch would no longer be open source, a loophole that they introduced with this very intention from the start… Elastic has spit in the face of every single one of 1,573 contributors, and everyone who gave Elastic their trust, loyalty, and patronage.”
Now, here we are with Sentry, and it’s the same story with a different license. In all fairness, Sentry has been using a source-available license for a long time. Before the company created and adopted FSL, it had used BSL since 2018. If anyone was still donating code to Sentry, they had to know exactly what they were getting into.
So why make a new license? Sentry head of open source, Chad Whitacre, explained: “BSL has two major flaws. First, the default non-compete time period is four years, which is a really long time in the software world. This can make it feel like the eventual change to Open Source is only a token effort. It almost might as well be 100 years. For Sentry, we chose to tighten it to three years, but even that is probably too long.”
After that period, the code refers to either the Apache 2.0 or MIT license. But, that’s not as generous as it sounds. Under the FSL, you can use its code for “any purpose other than a Competing Use. A Competing Use means use of the Software in or for a commercial product or service that competes with the Software or any other product or service we offer using the Software as of the date we make the Software available.”
In other words, you can look but not run the code for a business. For more, you can look at the company FSLed versions of Apache and MIT. As far as I’m concerned, neither is an open source license.
Whitacre added, “The more serious flaw is that BSL has too many parameters: the change date, the change license, and the Additional Use Grant. The Additional Use Grant is the biggest problem. It is a giant fill-in-the-blank that effectively means that every BSL is a different license.”
I can’t argue with that. Each company’s BSL is unique. This also means it makes it hard for customers to know exactly what they’re getting legally when they contract with a company using BSL. It’s Sentry’s hope that the FSL will make its products and services more appealing to its customers.
Maybe it will. But I agree with Carrez, who said: “Releasing yet another license variant that removes developers’ self-sovereignty in their technical choices is nothing novel: it is still about removing essential freedoms from the whole software ecosystem to clearly assert ownership over their proprietary software and the use you are allowed to make of it. This is not open source: it is proprietary gatekeeping wrapped in open washed clothing.”
