We at dotCMS, are not alone in taking the BSL road.
Some of today’s most successful open-source-based companies have adopted BSL or similar “source-available” licensing models to marry open development with sustainable business:
MariaDB
As mentioned, MariaDB Corp introduced the BSL and uses it for certain products (while the core MariaDB database remains fully open source). This allowed them to freely share the code and build a developer community, while still protecting specific monetization streams. MariaDB’s databases are now ubiquitous in enterprises, proving that this model can work at scale.
CockroachDB
The team behind CockroachDB, a popular distributed SQL database (with over 28k stars on GitHub), moved from an Apache license to BSL for their later versions. CockroachDB’s founders did this explicitly to prevent cloud providers from offering the database as a service without contributing back. Today Cockroach Labs is a thriving company, and the database is used in production by major companies – all while its source code remains available for anyone to inspect or use under the license terms. Developers still collaborate via pull requests, and after the licensed period lapses, each version becomes fully open. This approach has allowed Cockroach to foster a huge open-source user base and build a viable business.
Sentry
Sentry (the popular error-tracking platform) is another great example. They switched to BSL in 2019, after being open source, because they found big cloud vendors could otherwise host their project and undercut them. The result? Sentry continued to flourish. Users can still self-host Sentry for free (it converts to Apache 2.0 after three years in Sentry’s case), but no one can sell a competing Sentry-as-a-service without a commercial agreement. This protective measure didn’t alienate the community – instead, it ensured Sentry’s team could keep funding development.
HashiCorp
In a very high-profile move, HashiCorp (known for Terraform, Vault, and other devops tools) adopted BSL for all its products in 2023. Their stated goal was “to ensure continued investment in its community and to continue providing open, freely available products.” HashiCorp saw huge companies taking their fully open-source tools and offering competing services, so they opted for BSL to require those players to get a commercial license. While the decision sparked debate (and even a fork of Terraform by purists), HashiCorp stands by it as necessary to sustain their open-source work. And HashiCorp is indeed highly successful – it went public and its products are ubiquitous in cloud infrastructure. By using BSL, they aim to keep their software widely usable for individuals and organizations (the source is still out there on GitHub) while ensuring that the only folks who can’t freely piggyback are those selling HashiCorp’s software as a service in direct competition.
Others
Many other companies and projects have embraced similar licenses. Our own CMS space has seen moves like Directus (an open-source data platform/CMS) switching to BSL. Big names like Elastic and MongoDB created slightly different licenses (SSPL, etc.) for the same reasons as BSL – to guard against cloud exploitation. According to our research, even companies like Redis Labs and Docker have used source-available licenses for parts of their stack. And let’s not forget Red Hat, which built a multi-billion dollar business on open-source software with subscription support; they recently adjusted how they share RHEL source code to protect their business model (a controversial move in the community, but it underscores the tension between pure open source and commercial realities). The takeaway is that blending open collaboration with protective licensing is a proven strategy. When done right, it results in thriving communities and sustainable companies.