Why we're relicensing CockroachDB

Why we're relicensing CockroachDB

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.

About the authors

Peter Mattis github link

Peter is the co-founder and CTO of Cockroach Labs where he works on a bit of everything, from low-level optimization of code to refining the overall design. He has worked on distributed systems for most of his career, designing and implementing the original Gmail backend search and storage system at Google and designing and implementing Colossus, the successor to Google's original distributed file system. In his university days, he was one of the original authors of the GIMP and is still amazed when people tell him they use it frequently.

About the authors

Ben Darnell github link

Ben is the co-founder and Chief Architect of Cockroach Labs where he worked on the distributed consensus protocols that underpin CockroachDB’s transactional model. He started his career at Google and then went on to a series of startups where he saw firsthand the need for better scalable storage systems. When he’s not working he likes to travel the globe in search of food and adventure.

Spencer Kimball github link

Spencer Kimball is the co-founder and CEO of Cockroach Labs, where he maintains a delicate balance between a love for programming distributed systems and the excitement of helping the company grow smoothly. He cut his teeth on databases during the dot com heyday, and had a front row seat at Google for a decade’s worth of their evolution.

Keep Reading

How CockroachDB implemented consistent, distributed, incremental backup

Consistent, Distributed, Incremental Backup: Pick Three

Almost all widely used database systems include the ability to …

Read more
[podcast] Unscripted founders Q&A on CockroachDB 1.0

LISTEN ON: | SoundCloud |

Join the Cockroach Labs founders for an unscripted conversation about the dirty …

Read more
CockroachDB 1.0 is production-ready

Today, we are pleased to announce the release of CockroachDB 1.0, the first open source, cloud-native SQL …

Read more