Six years ago in August, Redis – then known as Redis Labs – applied a new license called the Commons Clause to a set of modules, or extensions to the core Redis database. The practical import of this clause was to override the existing open source license to render the software effectively proprietary and source available while still leveraging the brand of the original open source license.
This was not the first commercial open source organization to relicense its assets, or even the first to use that particular license (though Redis retired the Commons Clause license a year later). Neo4J preceded them in that. Nor was it the last time an existing project swapped an open source license for a more restrictive, proprietary alternative. Mongo followed suit two months later exchanging the AGPL for the SSPL, and Confluent (Apache to Confluent Community License) and Timescale (Apache/Timescale License) followed two months after that, a pattern which has continued into the present.
While the initial costs from a public relations and community outrage perspective were high, each successive act of relicensing helped smooth the path for the next. Implicit in this pattern was a normalization of the once controversial act of using open source to reach ubiquity and then unilaterally changing the rules of access in an effort to achieve economic exclusivity. So regular had this practice become, in fact, that project founders began fielding questions from potential investors about when, rather than if, they would relicense their project.
Such is the state of affairs at present. In more and more cases, the accepted strategy for open source commercialization is to leverage open source to achieve breadth, at which point the license is abandoned in favor of something that imposes the kinds of restrictions open source expressly and explicitly forbids.
It may, however, be more accurate to say that that was the state of affairs. It’s too early to say definitively, but there are signs at least that the post-Valkey world is meaningfully different than the world before its release.
Forks
Before considering the Valkey fork specifically, it’s worth establishing some general context around forks.
First, forks have been around as long as open source has. From Unix to Linux to PostgreSQL to MySQL, the history of open source is littered with forks. In recent decades, however, three things have typically been true of forks.
- First, they were broadly considered a nuclear option of last resort.
- Second, with rare exceptions like the 2014 Node/io.js split, few forks attracted much attention.
- Lastly, because of the first and second points, almost regardless of the context of why a project was forked in the first place, the safe bet was always in favor of the original project and against the fork.
Valkey, however, appears to be a different animal altogether.
First, there’s the speed with which the project came together. For those unfamiliar with the history, six years after re-licensing external modules, Redis re-licensed the core database itself on March 20. Specifically, it retired the permissive three clause BSD license in favor of a dual proprietary source available license or the Server Side Public License (SSPL) originally created by Mongo. What this meant in practice was that the permissively licensed database used, contributed to and supported by a variety of players was now effectively a source available, proprietary database.
Eight days later, the Linux Foundation announced the launch of a fork. An eight day timeline for a project of this size and scope is shocking. An eight day timeline to announce a project of this scope that includes names like AWS, Google and Oracle of all vendors is an event without any obvious precedent. Even setting the requisite legal approvals aside, naming and branding take time – as they did in this case, apparently.
Second, there are the aforementioned brands. One of the primary reasons most forks do not succeed is that they fail to gain participatory critical mass quickly enough.
Consider the example of OpenSearch. The same year that Redis relicensed their modules, Elastic decided against relicensing the Elasticsearch project (though they ultimately reversed course three years later) in favor of co-mingling open source and proprietary assets in their core repo and the resulting builds in an attempt to make it more difficult for third parties like AWS to leverage the open source code. In response, AWS went with the nuclear option and forked the Elasticsearch project into OpenSearch, sending shockwaves through the industry.
While OpenSearch is still an active, supported project with substantial usage, however, it has to date failed to make much of a dent in Elasticsearch’s traction. There are many reasons for this, but perhaps the most important is the lack of perceived widespread industry support. AWS has, to date, not gotten any of its hyperscale competitors to commit to the project. Which means that enterprise CIOs evaluating Elasticsearch and OpenSearch have a simple and straightforward calculation to make: who is more likely to deliver them greater innovation over the longer term? AWS – where OpenSearch is one amongst hundreds of projects – and an assortment of smaller, mostly less visible startups? Or Elastic, a $12B company singularly focused on the project and synonymous with search?
Valkey, by comparison, offers a much more nuanced calculation. Redis, obviously, has a deep and unmatched knowledge of the product. But if you are a buying executive at a major enterprise, and you’re choosing between a company yet to go public, and an offering backed by multiple hyperscale options, smaller clouds like Digital Ocean and Heroku not to mention database stalwarts like Oracle or vendors like Percona that will offer on premise support, that is a more difficult calculation.
Which brings us to the last, and arguably most notable, distinction: the attention. The day that Valkey was announced, I posted a link to the press release, with an anodyne caption reading “ok, you have my attention.” That aggressively bland tweet saw almost 150 thousand views – or roughly 15X my follower count. That level of attention, particularly for something as basic as a press release, is extremely unusual.
As has been the level of inquiries RedMonk has received about Valkey. Unlike forks that have preceded it, which have to try and manufacture interest and attention, Valkey is a constant source of curiosity for clients, and questions. What do we make of it? What do the metrics tell us? Are we getting asked about it? Why do people seem to care about it? Does it feel different to us as well? Do we believe the project has staying power? And perhaps the most important question: might Valkey change the calculus for other prominent forks like OpenBao or OpenTofu?
What Does it Mean?
Objectively speaking, we can’t answer that question yet. It’s too soon to say. On the one hand, as of yesterday the Valkey Docker image had been pulled ~193K times in just a few months. On the other, Redis has been pulled billions of times since the project’s inception. Neither of which number tells us much since they’re accretive metrics not amenable to comparison.
Likewise, Valkey has shown greater activity levels versus Redis over the last 30 days. For example, per GitHub, Valkey has seen:
- ~2X the number of merged pull requests versus Redis
- ~3X the number of open requests
- Roughly the same number of closed issues
- ~2X the number of project authors
- ~6.5X the number of code additions
- ~4X the number of code deletions
Superficially, that seems to tell a clear story. But the reality is that forks necessarily involve a great deal of initial logistical blocking and tackling, and that will inevitably boost project metrics in the short term. Also, it’s merely a month’s worth of data.
The short version of the above is that it’s too early to draw any real conclusions, and that the next several quarters will tell us what Valkey actually is and can accomplish. All that we can say definitively at this point is that Valkey appears to be a viable project with anomalous visibility for a fork.
There are suggestions, however, that Valkey’s impact could be broad. In the short term, it has already had a ripple effect on behaviors. In at least one instance, the interest Valkey has attracted has contributed to a reversal of a seemingly set decision regarding a licensing adjacent question. Elsewhere, the tone and tenor of licensing conversations RedMonk is having is materially different than it was five months ago.
In the longer term, Valkey represents – whatever the project’s ultimate fate might be – the first real, major pushback from a market standpoint against the prevailing relicensing trend.
To be clear, no one should get carried away and expect Valkeys to begin popping up everywhere. It’s important to note that there are many variables that impact the friction involved in forking a project and the viability of sustaining it long term. Some projects are easier to fork than others, unquestionably, and Redis – if only because it was a project with many external contributors – was lower friction than some.
Not every project that is re-licensed can or will be forked. But investors, boards and leadership that are pushing for re-licensing as a core strategy will, moving forward, have to seriously consider the possibility of a fork as a potentially more meaningful cost. Where would be re-licensors previously expected no major project consequences from their actions, the prospect of a Valkey-like response is a new consideration.
In recent years the primary costs to the re-licensing of a given project have been developer unrest, buyer irritation (and in some cases additional legal guarantees) and a weather-able period of bad headlines. The uniqueness of Valkey and its potential to reinvigorate projects like OpenBao and OpenTofu, however, signal that that period may be over.
Disclosure: Amazon, Google, Heroku (Salesforce), MongoDB, Neo4J, Oracle, Percona and Redis are RedMonk customers. Confluent, Digital Ocean and Timescale are not currently RedMonk customers.
