CockroachDB changes the terms for competing database services

A hosted database can compete with the company developing its code even when the host complies with the code's license. Cockroach Labs is responding to that business problem by changing the license for future CockroachDB Core releases. The restriction targets a defined database-service offering, with an eventual conversion to Apache 2.0.

The June 4 announcement names 19.2 as the first planned release under the new arrangement. Existing 19.1 releases and future patches in that series retain their Apache licensing. Enterprise components continue under their separate Cockroach Community License.

I find CockroachDB's consistency model technically attractive, and that judgment does not settle the licensing question. A database can have useful engineering properties while its distribution terms introduce a separate constraint. Both belong in an evaluation because a system's permitted deployment model can outlast the initial choice of query engine.

The restriction defines a database service

The license text linked by the announcement is Business Source License 1.1 with Cockroach Labs' parameters. Its additional-use grant permits use except for a defined Database Service.

That definition matters more than the shorthand description of competing with a cloud provider. It concerns a commercial offering that lets third parties access the licensed database functionality by creating tables whose schemas those parties control. Employees and contractors are excluded from that third-party description.

This makes schema control an explicit part of the boundary. An application that uses a database behind its own service is not automatically described by the same mechanism as a service that lets customers create their own tables. The text identifies a particular way the database functionality becomes available to outside users.

The distinction should be preserved when explaining the change. Calling it a ban on commercial use would be inaccurate because the additional-use grant is broader. Calling it unrestricted permission for every hosted product would also erase the defined database-service restriction.

The license provides an alternative when a proposed use does not meet its current requirements. It says the user must obtain a commercial license or refrain from that use. The new distribution terms therefore reserve a commercial relationship for the restricted service model.

Redistribution also retains obligations. The terms require displaying the license on original or modified copies and state that receiving a copy from another party does not remove the conditions. Passing the source through another distributor therefore does not eliminate the need to identify its version and current permissions.

This is an explanation of the published mechanism, not a conclusion about a hypothetical product with unspecified behavior. Whether a particular offering matches the definition depends on what it exposes and who controls the schemas. The text supplies those criteria instead of a universal classification based on the word cloud.

Source availability and open source are different properties

The BSL notice explicitly says it is not an open-source license. Source remains available, but the additional restriction means the current grant does not permit every use. The announcement acknowledges this distinction.

That matters for how the project is described. Access to implementation code supports inspection, debugging and modification. Those practical benefits remain useful, but they do not establish the same permission set as Apache 2.0.

The license's base grant allows copying, modification, derivative works, redistribution and non-production use. Production permissions come through the additional-use grant. Reading the base paragraph alone would therefore give an incomplete account of what Cockroach Labs permits.

The parameters are also essential. BSL is a license framework whose additional-use grant and change conditions are supplied for the licensed work. Another project's use of BSL can have different production permissions even if the framework's name is identical.

My preference is to name the actual terms under consideration. Describing a dependency merely as source available is useful only at a broad level. A decision about operating or redistributing it needs the specific additional-use grant and the identity of the licensed work.

The text identifies CockroachDB 19.2 as that work. It does not present one undifferentiated rule for every historic version. Version identity is consequently part of the licensing record, just as it is part of a technical compatibility record.

The conversion mechanism belongs to each release

The BSL text supplies a Change License and a Change Date. Its terms grant rights under the Change License when the stated condition is reached. The framework also contains a fourth-anniversary backstop if that occurs first.

Cockroach Labs' selected Change License is Apache License 2.0. The announcement describes its intended restriction period as three years for each release line. Those are related facts, but the framework's general timing rule and the project's chosen parameters should not be collapsed into one sentence that omits their difference.

The announcement also says patch releases do not restart the conversion period for the release line. That is relevant to maintenance planning because accepting a later patch does not, under the described policy, create a fresh full waiting period for that line.

As of today, the conversion is a prospective mechanism in the published terms. It should not be described as an event that has already occurred. The practical promise is that a particular version's restricted period has an endpoint specified by its license.

There is still a distinction between an older converted version and a newer release with its own parameters. The license applies separately to versions, and its text says Change Dates may vary. A rolling policy therefore does not mean that the newest code is always available under the eventual license of an older version.

This gives users a defined future permission change while leaving a continuing restriction on newer releases during their initial period. That is the business compromise expressed by the mechanism. It protects a period of service competition without making the restriction permanent for each BSL-covered version.

Enterprise code does not share that conversion

The repository license notice at the linked revision describes multiple licenses in the source tree. It lists BSL and Cockroach Community License code, alongside MIT and BSD-style material.

The notice says files default to BSL unless their headers state otherwise. That makes file-level notices relevant when identifying the terms of a component. A repository-wide shorthand does not replace those exceptions.

It also distinguishes build outputs. Running the ordinary build produces a binary that includes CCL-covered code and is subject to CCL terms. The notice names a separate build target for producing a binary without that code.

The announcement explicitly says the enterprise license does not convert to open source after three years. Consequently, the BSL conversion cannot be used to describe the entire combined product as eventually Apache-licensed. The terms of enterprise components remain separate.

This is an important practical distinction for artifact selection. Two binaries built from related source can contain different licensed components. A deployment record that names only the source repository and version may omit the build composition that determines the applicable terms.

The business rationale explains the chosen boundary

Cockroach Labs presents the change as a response to the competitive advantage of integrated cloud providers. Its concern is that a provider can offer the database as a service with an experience improved by the provider's surrounding platform.

The restriction consequently addresses service distribution, rather than limiting the number of nodes a user may operate. That choice is consistent with the product's purpose as a scalable distributed database. Restricting ordinary cluster size would impose a different constraint on the applications the project wants to attract.

The company's argument explains its intent, but intent and permission remain distinct. An operator can understand the competitive concern and still require the exact grant for an intended use. The license text is the place where the service definition and version-specific conditions appear.

I prefer to keep the technical and commercial decisions connected without treating either as sufficient on its own. CockroachDB's transaction behavior may fit an application's correctness needs. Its terms must also fit how the application and its database functionality are made available to others.

For current 19.1 users, today's announcement says that line remains under its existing Apache arrangement, including patches. For the planned 19.2 line, the relevant change is the BSL additional-use restriction and its conversion mechanism, with enterprise code continuing under CCL. These distinctions let an evaluation identify the exact release, component set and service model involved, rather than assuming that all uses of CockroachDB now have identical terms.