Why does the BSL license get so much hate from developers?
Let’s start with a bit of history. According to Maria DB, the creators of the Business Source License, ”BSL is a new alternative to closed source or open core licensing models. Under BSL, the source code is always publicly available. Non-production use of the code is always free, and the licensor can also make an Additional Use Grant allowing limited production use. Source code is guaranteed to become Open Source at a certain point in time. On the Change Date, or the fourth anniversary of the first publicly available distribution of the code under the BSL, whichever comes first, the code automatically becomes available under the Change License. The Change License is mandated to be GPL Version 2.0 or later, or a compatible license (i.e., the Change License is always an Open Source license that enables use of the software in a GPL project).” Other than Maria DB itself, a bunch of other companies such as Sentry, Cockroach Labs, Confluent, Mongo DB, Elastic, Redis labs and most recently, Hashicorp, have adopted this license.
BSL is not considered as an open source license by the Open Source Initiative. A complete list of the approved licenses that comply with the Open Source Definition (ie, they allow software to be freely used, modified, and shared) can be viewed here.
While one can understand why licenses like the BSL exist and can see their value (Having software under the BSL is certainly better than it being completely closed off), whats puzzling is the usage of the term "Open Source" for such licenses. It often seems like companies want the branding perks of OSS without fully committing to its principles. That brings us to a very important point:
The motivation to contribute to Open Source Software
Most developers contribute to understand new technologies, languages and frameworks and prove the competency post learning publicly. There are also seasoned maintainers who vet contributions and maintain large repositories.
Developers often find a unique sense of joy and fulfillment in contributing to open source projects. For many, it's not just about the code, but the thrill of creation and collaboration. Take, for instance, the sense of pride and fun that comes from seeing one's work come alive in the digital realm. Additionally, contributing to open source can inadvertently serve as a career booster. Many hiring firms view open source contributions as a testament to a developer's passion and skill, often considering it a bonus during the recruitment process. Beyond the professional perks, there's an undeniable ego boost when you see your creations being used and recommended by peers in the tech community. In a way, open source offers a shot at digital immortality—a chance to make a lasting impact that might just outlive its creator. This allure of creating something long-standing and beneficial, combined with potential consulting opportunities and even the distant dream of turning a passion project into a business, makes open source an enticing playground for many developers.
Hashicorp’s recent change to BSL
Hashicorp has had tremendous respect amongst the open source community for what they have built over the years. HCL is the fastest growing language in the world (according to the GitHub octoverse report from 2022). On the 10th of Auguest 2023, Hashicorp switched Terraform from an open source MPL license to the BSL, making Hashicorp effectively closed source. This resulted in the creation of OpenTofu (Previously OpenTF), whose supporters as of 2nd October 2023 include 148 companies, and 734 individuals.
As Yevginy Brikman, the creator of Terragrunt, put in his blog:
As a result of the change to BSL, there is now no certainty with using Terraform:
“If you’re a CTO, and you’re picking an IaC tool to use at your company, if you see that Terraform is BSL licensed, why take the risk? You’re now much more likely to go with alternative tools that are truly open source and have no licensing headaches.”
”If you’re on the legal team at a company and reviewing the licenses your dev team wants to use, and you see BSL, why take the risk? You’re now much more likely to push back and put BSL on the banned license list.”
”If you’re a developer and considering contributing to open source, why contribute to a BSL project with no guarantee you’d be able to use your own work in the future? You’re now much more likely to contribute to something else.”
”If you’re a vendor and considering building a product or tooling in the DevOps space, why build it around Terraform, and take the risk that HashiCorp will, now or in the future, consider you competitive? That’s just too shaky of a foundation to build on, so you’re now much more likely to build around something else.”
A possible solution - an Open Charter?
Recently, in an blog authored by Sid Sijbrandij for Open Core Ventures, he mentioned the possible solution of a Charter. Now what would the charter do, you may ask?
Sid defines it by saying “ An Open Charter is A legally binding corporate formation document stating a company’s commitment to open source and includes a series of objectives for meeting its open source commitment.”
He further goes on to state that:
The only way a company can completely prevent relicensing code that was previously open source is to adopt an open charter in addition to the open source license. Open Core Ventures (OCV) has started numerous companies as public benefit companies using the OCV Public Benefit Company Charter (OPC). Our charter protects a company’s open source mission by:
Requiring the majority of new features added in a calendar year are made available under an open source license
Not withholding or intentionally delaying the release of security fixes for open source features
Not allowing the removal of any software products that were previously open source
Not allowing constraints or limitations such as user or performance limits, size, or number of repositories to projects the company has made available under an open source license
Open sourcing testing frameworks used for open source features
Explicitly communicating which code is open source and which is not.
The approach ensures that a company can’t switch to solely creating proprietary software or relicensing all of its software to a non-open source license. The OPC is open source and available for anyone to use. An open charter plus an open source license is how open source software companies will express their open source commitment in the future. It signals to users that they are serious about their open source status and lets investors and shareholders know that removing open source from the company is not an option in the future.