CockroachDB was conceived of as open source software. In the years since it first appeared on GitHub, we’ve tread a relatively typical path in balancing open source with creating a viable business. We’ve kept our core code under the Apache License version 2 (APL), launched a managed service, and gated some features for established companies under an enterprise license.
But our past outlook on the right business model relied on a crucial norm in the OSS world: that companies could build a business around a strong open source core product without a much larger technology platform company coming along and offering the same product as a service. That norm no longer holds.
Competitors have always been legally allowed to offer another company’s OSS product as a service. Now, we’re finally seeing it take place. We’re witnessing the rise of highly-integrated providers take advantage of their unique position to offer “as-a-service” versions of OSS products, and offer a superior user experience as a consequence of their integrations. We’ve most recently seen it happen with Amazon’s forked version of ElasticSearch, which Salil Deshpande neatly described in TechCrunch as both “self-interested and rational.”
To respond to this breed of competitor, we’re introducing a change to our software licensing terms. The full details of the change are below and on Github, but the short version is this:
Today, we’re adopting an extremely permissive version of the Business Source License (BSL). CockroachDB users can scale CockroachDB to any number of nodes. They can use CockroachDB or embed it in their applications (whether they ship those applications to customers or run them as a service). They can even run it as a service internally. The one and only thing that you cannot do is offer a commercial version of CockroachDB as a service without buying a license.
In order to continue building a strong open source core, this restriction has a rolling time limit: three years after each release, the license converts to the standard Apache 2.0 license. Our goal in relicensing with a time restriction is two-pronged: to simultaneously create a competitive database as a service (DBaaS) while also providing a guarantee that the core product will become pure open source.
Evaluating Open Source License Options
A number of companies have licensed their products with this same dual goal. When evaluating existing options, we found that they fit into two general camps: the “copyleft” model, and the tiered model, neither of which fit what we wanted to get out of a license change.
The “copyleft” model
The “copyleft” tradition was started by the GNU GPL and aims to prevent proprietary forks by requiring source code to be published in some cases. The Affero General Public License (AGPL) and the related Server-Side Public License (SSPL) both fall under this camp. The SSPL in particular is intended to address competitive hosted services.
However, we believe that these licenses do both too much and too little. Too much, in that the details are complex and the scope of the copyleft requirement is not always clear. Many would-be users are scared off by the publication requirements of these licenses which are potentially very broad. Too little, in that competitors are both willing and able to publish enough code to enable their own services, without providing any commensurate benefit to the authors of the core technology. Amazon did this with Open Distro for Elasticsearch even though they weren’t compelled to do this by a copyleft license.
We needed something simpler, and stronger.
The tiered model
Another option we considered was adopting a three-tier model: open source core, enterprise components, and a middle ground of features that are not open source but available at no cost. This is a popular model, and more or less the model we have had up until today.
However, this creates bad incentives for our company. It creates pressure to avoid creating new features in the core and do as much work as possible in the non-open-source components. Basically, we would be tempted to sell our core users short by permanently putting our most exciting features behind an enterprise license. If you squint towards the horizon, this model does not bode well for the open source ecosystem.
The BSL solution
We started exploring licenses with a time-limited restriction, and found that we didn’t have to create a new license from scratch. MariaDB’s Business Source License (BSL) 1.1 has the provisions we want and has already been endorsed by OSI founder Bruce Perens. The BSL is a parameterized license, so our use of it is not exactly the same as MariaDB’s.
The key difference is in the “Additional Use Grant”: MariaDB’s MaxScale product, for example, allows you to use MaxScale with up to three server instances. CockroachDB’s Additional Use Grant allows you to use CockroachDB with as many nodes as you want as long as you are not offering it as a commercial DBaaS. Our BSL protects CockroachDB’s current code from being used as a DBaaS without an enterprise license for a period of three years. After 3 years this restriction lapses and the code becomes open source (per our current Apache license) and is free to use for any purpose.
We’re applying this license to the core edition of CockroachDB (i.e., the code that is currently under the Apache 2.0 license). This means that CockroachDB Core is no longer Open Source (according to OSI’s Open Source Definition), although the complete source code is still available, and any commercial usage is allowed with the one exception of building a DBaaS. We believe this is the best way to balance the needs of the business with our commitment to Open Source. The new license still permits the vast majority of users to use, redistribute, and modify CockroachDB freely, and will become no-strings-attached Open Source after three years.
Nuts and Bolts: How the BSL Works
We are relicensing CockroachDB beginning with 19.2, adding the restriction that it may not be used in a commercial database-as-a-service (DBaaS) without a license agreement with Cockroach Labs. The three-year restriction is applied on a rolling basis for each release.
CockroachDB’s enterprise features will continue to use the Cockroach Community License (CCL). Use of enterprise features will always require a license agreement with Cockroach Labs; this license does not convert to open source after three years.
To put this in concrete terms, CockroachDB 19.2 (tentatively scheduled for October 2019) will be the first release to use this new license scheme. It will include code under both the BSL and CCL. In October 2022 (three years after its release), the portions of CockroachDB 19.2 under the BSL will convert to the APL. Patch releases don’t change the conversion date: all 19.2.x releases will convert in October 2022, even though only the base 19.2.0 release is three years old at that point. CockroachDB 20.1 (planned for April 2020) will become open source in April 2023, and so on.
Older versions are not affected by this license change: CockroachDB 19.1 is still using the Apache license, and all present and future patch releases in the 19.1.x series will also use the APL.
We're committed to building a powerful core product that is open source. Even though the BSL isn’t an open source license, this compromise felt closest to the spirit of open source, while still protecting our business. And three years after each release, our commitment to Open Source automatically completes. We believe that the path we’ve chosen is how to build an open core company and still maintain a strong open source legacy in this new reality.
