Cockroach and the Source Available Future

Earlier this month, the database company Cockroach Labs relicensed its flagship database product. This is notable for two reasons. Most obviously, the company is following in the footsteps of several of its commercial open source database peers such as Confluent, Elastic, MongoDB, Redis Labs and TimescaleDB that have felt compelled to apply licenses that are neither open source nor, in most cases, traditionally proprietary.

But the relicensing of CockroachDB is also interesting because this isn’t the first time the company has applied such a license.

In January of 2017, Cockroach Labs announced the introduction of what it called the CockroachDB Community License (CCL). To the company’s credit, in the post announcing this new license, it took pains to make it clear that the CCL, while making source code available, was not in fact an open source license because it restricted redistribution. The CCL essentially enforced a two tier, open core-type business model, in which a base version of the database was made available under a permissive open source license (Apache) while certain enterprise features were made available under the CCL, which essentially requires users of these premium, enterprise-oriented features to pay for them.

With its recent relicensing, the original dual core model has been deprecated. Moving forward, CockroachDB will be made available under two non-open source licenses – which, as an aside to Cockroach, presumably means that section 1B of the CCL probably needs to be updated. The CCL will continue to govern the premium featureset, but the original open source codebase will moving forward be governed by the Business Source License (BSL). Originally released by MariaDB, the BSL is a source available license; a license that makes source code for a project available, but places more restrictions upon its usage than is permitted by open source licenses.

In MariaDB’s case, the original restriction was that the license was free for less than three server instances. More than that, and a commercial license would have to be acquired. For Cockroach, the restriction – or “Additional Use Grant,” in the parlance of the license – is that “that you may not use the Licensed Work for a Database Service.”

Technically, the code is graduated to open source code after three years; the market appetite for three year old code is likely to be modest, however. In practice, then, it is fair to say that Cockroach replaced the permissive, open source Apache license with a non-open source license that restricts the offering of the database as a service.

In practical terms, this means that rather than having its core open source product easily flow through corporate legal firewalls – as legal teams have generally precleared Apache licenses as a known entity – each and every business that wants to adopt CockroachDB will have to evaluate at least one and possibly two unique, non-open source licenses. To put it mildly, this is a significant impediment to adoption, because the database marketplace today is full of options, many of which carry few if any restrictions on usage. If a developer has two database options, one which she can use immediately without restriction and an alternative which she has to submit to legal and await their approval, the former can reliably be predicted to be far more widely used – even if the latter is technically more advanced.

The obvious question, then, is why Cockroach has sought these new restrictions. The answer, both in terms of high level vision and low level execution, says much about the current state of strategic thinking about licensing in the database space.

According to Cockroach, this license is in part necessary because its:

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.

It’s worth noting that the link in that paragraph to the right business model points to the announcement of the CCL, which again was released in 2017. The use of “norm” itself in this case is an interesting choice of words, because easily the most significant violation of open source norms in the last decade or more is licenses such as the BSL and CCL.

Setting that aside, however, it is genuinely surprising to hear a company argue that the norm in 2017 did not include large technology platform companies offering the same product as a service. AWS’ RDS offering by itself had been doing precisely this for close to a decade; RDS MySQL was launched in 2009, PostgreSQL in 2013, and MariaDB in 2015. And that’s just the open source databases; commercial databases were offered as a service as well, with Oracle debuting on RDS in 2011, SQL Server in 2012 and the proprietary PostgreSQL flavor Aurora in 2014. Just within Amazon, then, there were three open source and three proprietary database-as-a-service offerings in market at the time Cockroach was apparently basing its business model on the idea that large technology platforms wouldn’t be offering these products as services.

If the specific justifications for the concern around as-a-service offerings are problematic, however, Cockroach’s big picture concern is one that is both easily understood and common. The fear of AWS and other large cloud providers is, in fact, pervasive in the database category in particular.

One common question is why databases? Few other enterprise technology categories have exhibited the same degree of alarm that the database industry has, and none have been so willing to abandon their open source models in favor of non-open source alternatives. Why?

There are several potential answers to this question, these are likely the two most compelling:

1. That based on the historical profit history and strategic nature of proprietary database products, investors venture and otherwise have been more willing to invest in these than other, more difficult to monetize open source businesses. These investors, in turn, frequently have a different relationship with open source than the original authors of the software, and have applied pressure directly and indirectly to relax commitments to and defense of open source in search of greater commercial returns.
2. That the nature of database infrastructure makes it uniquely susceptible to competition from as-a-Service platforms. Databases historically have been characterized by a significant operational overhead relative to other portions of the enterprise infrastructure, and operational overhead is an area where as-a-Service offerings excel relative to their software-only counterparts. As has been argued here many times, if a company has to choose between two otherwise equivalent software offerings, except that one requires little or no operational overhead, that is a significant competitive advantage – hence the explosive growth for database-as-a-service offerings.

Whatever the reasons, however, Cockroach and many of its commercial database or database-like counterparts have pivoted from regarding AWS and its ilk as a curiosity five years ago to existential threat today. Cockroach’s own licensing demonstrates this shift; in 2017, its licensing strategy reflected a concern that enterprises wouldn’t pay for premium features. As of this month, it has effectively abandoned its open source roots – roots that date back not just to the founding of the company but the individual founders’ careers – in favor of a model that attempts to forestall competition from the cloud.

The biggest question now is whether these licensing-led attempts at protecting their businesses will be successful. If history is any guide, the answer is probably not.

One of the interesting things about the relicensing efforts so far is how many have been ineffective, unnecessary, or both.

• Elastic has been competing with AWS since 2015; in spite of this, the commercial company behind it went public in 2018. The company is currently valued around $5.5B. Seeking greater protections from AWS and other cloud providers, the company adopted a source available licensing model and commingled open source code and proprietary code. In response, AWS forked the project and released open source versions of the proprietary software Elastic charged for – thus fulfilling a prediction here that forking would be a competitive response.

• For the past two years, MongoDB has been competing with a cloud provider in Azure that advertises a MongoDB-compatible product called CosmosDB. In spite of this competition from a large cloud provider, MongoDB’s own as-a-service product Atlas grew to an annual run rate north of $100M in less than three years. For context, it took the traditional, on premise business nearly a decade to achieve that feat.

  Nevertheless, the company decided in October 2018 to relicense its project from the restrictive AGPL to the even more restrictive SSPL; a license it hoped would be approved as an open source license, but which it later withdrew from consideration due to objections. A quarter later in January of 2019, AWS launched its own MongoDB-compatible offering, DocumentDB – a product that notably had been in development for years before the introduction of the SSPL and yet was not based on MongoDB’s code.

• In December of last year, TimescaleDB introduced a source-available vanity license called the Timescale License (TSL). While the company had considered a managed service offering, it was at that time fully focused on the on-premise opportunity. Seven months later, it this week launched an as-a-service offering called Timescale Cloud, presumably in response to customer demand but more the need to compete with large technology platform providers offering either native (AWS Timestream) or partner-led (GCP/InfluxData) time series competition. Even providers that don’t wish to offer as-a-Service offerings, in other words, will ultimately be compelled to.

Which brings us back to Cockroach and its licensing decision. In nearly every case, relicensees point to the likes of AWS as a or the justification for the change. While the exact approaches taken differ, often dramatically, the new licenses typically have one thing in common. They attempt to discourage usage by large cloud providers, either by prohibiting it outright (e.g. Cockroach) or by imposing compliance burdens sufficient to make the license non-viable for cloud providers (e.g. MongoDB).

The question is: to what end? Assuming that competing with large providers is the strategic aim, how is that achieved? What problem specifically do source available licenses solve?

• If the goal is full protection from cloud providers, it is impractical if not impossible to achieve. Given sufficient incentives – read: enough market traction for a given project – cloud providers can and have reimplemented protected software or routed around it via API compatibility. It’s also worth noting that at least one existing open source license, the AGPL, afforded enough protection that AWS chose to avoid it when building its MongoDB-compatible offering.
• If the goal is leveling the playing field by incentivizing or mandating contributions either from community members or the cloud platforms that would otherwise run this software as a service, source available licenses are the worst possible solution next to fully proprietary licenses. No large technology provider will be willing to contribute code back to projects not governed by an open source license.
• If the goal is what the author of several non-compete licenses, Heather Meeker, says it is – specifically:

  “the current trend of licensing changes will eventually achieve its desired effect of getting cloud providers to pay for their use of the software”

  it seems highly probable that non-compete, source available licensees are going to be disappointed. First, while there are many examples of reseller agreements of both open source and proprietary software, there are zero obvious examples of a core native service from a major cloud provider being based on a licensed commercial open source product. The next will be the first. Second, it would be poor strategy for a major commercial cloud provider to be entirely dependent – both in terms of cost and product management – on a single third party for a core service.

The benefits, therefore, at best come with caveats. The costs, however, are clear. Non-open source licenses necessarily come with collateral damage. Developers suddenly need approval where none was needed before; competitors spread fear, uncertainty and doubt and ask your customers questions like “if they changed the license once, what makes you think they won’t do it again?”; partners are faced with the prospect of having your new license (and that of everyone else pursuing a similar course) processed by legal; once friendly open source communities become enemies due to the risks hybrid approaches pose to the clean definitions and related acceptance of open source software. And so on.

It is a simple enough task to draft a license that says this potential competitor may not use a given piece of software. Ensuring that the new license is more benefit than cost is another matter entirely, however. As has been covered before, virtually all of the available evidence suggests first that concerns may be overblown, and second that even if it is assumed that they are taken at face value, that licensing mechanisms are not the solution many vendors want them to be.

Regardless of this assessment, new licenses and believers in them continue to arrive. Assuming there is no mass change of heart, which concepts like the escalation of commitment suggest is unlikely, there are three potential paths forward from here.

1. Status Quo: Vendors continue to relicense some or all of their code, each deciding on a unique approach that results in a one off license.
2. Consolidation: Vendors recognize the need to balance their particular desire for license protection with the reality of license proliferation, and choose to consolidate their various source available licenses around a small number of centrally approved and understood models – much as open source did years ago. The Polyform Project might represent a potential home.
3. Escalation: In an interview with The Information concerning its most recent licensing change, Cockroach Labs CEO Spencer Kimball said “We’re basically putting a kind of patent protection against Amazon-like behavior.” It’s not entirely clear what this statement meant, and if it was meant literally or as a metaphor. The post announcing the licensing change does not mention patents. The new license text likewise makes no reference to patents. But whether Cockroach Labs intended it or not, that phrase raises the specter of patent wars which should strike fear into the hearts of anyone who values innovation and velocity in the industry.

   In a perfect world, the software industry would have no patents. Based on the current trajectory away from more open mechanisms towards more restrictive models, however, it is not impossible to see an outcome in which, having found copyright-based licensing mechanisms wanting, the more aggressive advocates of relicensing – venture investors, typically – push for stronger enforcement mechanisms, patents among them. An outcome that would be a disaster.

Having incorrectly predicted that these alternative licenses would not gain in popularity, no guess is made here about which of the above paths the industry is most likely to take. Whatever the future holds, however, the industry’s best hope lies in objective, comprehensive and conservative evaluation of the role and efficacy of the various business model mechanisms available. More particularly, to examine not just a high level goal such as prohibiting competition, but critically assessing the reality and implications of doing so.

It is particularly true if one considers source available licenses to be a potential threat to open source due to the potential for confusion, but even if a relicensee is narrowly and strictly concerned with its self-interest and has no wider awareness or concern, the proliferation of source available licenses is a problem for advocates of that approach. License proliferation was a material problem for open source, which as an aside is one of the reasons in fact that the OSI both exists and remains vital if imperfect, and it will be a material problem for source available advocates as well.

How they choose to address the problem, or perhaps more accurately whether they choose to address it, will determine the future for source available licenses, the companies that leverage them and consequently the industry around both.

Disclosure: Amazon, Confluent, Elastic, Google, InfluxData, Microsoft (Azure), MongoDB and Oracle are RedMonk clients. Cockroach Labs, the OSI, Redis Labs and TimescaleDB are not currently RedMonk customers.