Redis, Elastic and Database Relicensing: The Complete Guide

What database relicensing means

Redis, Elastic and database relicensing describes a clear pattern. Over several years, the companies that steward some of the most widely deployed data infrastructure moved their flagship projects off open source licenses and onto source available ones. The motive was commercial: to stop large cloud providers from offering the software as a managed service without contributing back or paying. The effect, for everyone else, is that a database adopted under an open license now carries terms that did not exist when it was first deployed.

This matters more for databases than for almost any other category of software. A database is not a library you can quietly swap. It holds state, it sits behind high availability guarantees, and it is woven into operational runbooks, backup regimes, and disaster recovery. When the license under it changes, the exposure does not stay in a contract file. It reaches the part of the stack that is hardest to move. That is why a structured, buyer side reading of the change is worth more here than a quick scan of a release note.

The relicensing wave is part of a broader shift covered across this site. For the foundational framing, see the pillar on open source license risk. For the mechanics of how and why projects relicense, see relicensing exposure. The HashiCorp move, the other landmark of the same period, is covered in HashiCorp and Terraform licensing.

The Redis license change and Valkey

As of March 2024, Redis moved from an open source license to a dual model combining the Redis Source Available License version 2 and the Server Side Public License. Later, an open license option was added back into the picture, which is a reminder that this is a fast moving topic and that any reading should be dated. The practical point for an enterprise is that the canonical Redis distribution is no longer simply open source, and the terms now turn on how you deploy and offer it.

The community responded with Valkey, a fork of Redis published under an open license and backed by a group of vendors and contributors. For many enterprises Valkey is the cleanest exit, because it preserves the protocol and much of the operational shape of Redis while restoring open terms. Whether it fits depends on the modules you rely on, the client libraries in play, and the support posture your operations team needs. We weigh that decision in detail in migrating from Redis to Valkey and frame the broader choice in the Redis to Valkey migration decision.

A point that is easy to miss: the Redis change affects new versions. If you froze on an older open source release, those terms persist, but you give up security updates and forward compatibility. That trade between license posture and patch currency is exactly the kind of decision that should be made deliberately rather than by drifting into an upgrade.

The Elastic license change and OpenSearch

Elastic moved first among this group. In 2021, Elasticsearch and Kibana moved from Apache 2.0 to a dual Server Side Public License and Elastic License model. Elastic later added an open license option as well, which again underscores the need for dated framing. AWS responded by leading OpenSearch, a fork of Elasticsearch and Kibana under an open license, which has since built its own ecosystem and managed offerings.

For an enterprise running search and analytics, the Elastic situation is instructive because it has had the most time to mature. The fork is real, the migration paths are documented, and the trade offs are well understood. The work is in matching your specific use of Elasticsearch features, plugins, and integrations against what OpenSearch supports, then deciding whether the open license is worth the migration cost or whether a commercial relationship with Elastic better fits your needs. The principle is the same as with Redis: name the options plainly and attach a cost to each.

Source available is not open source

This distinction sits at the center of every database relicensing decision. The Server Side Public License and the Redis Source Available License are source available. You can read and often modify the code, but neither is approved by the Open Source Initiative, and both attach conditions that the open source definition does not allow. MongoDB, which moved to the Server Side Public License in 2018, was the early example that set the pattern the others followed.

The Server Side Public License is the sharpest case. Its core condition reaches the act of offering the software as a service: if you do, the license asks you to release the source of the surrounding service stack under the same terms. For most internal users that condition is never triggered. For anyone whose business looks like offering the database as a service, it is decisive. Understanding which side of that line you sit on is the first practical question, and it is one your own counsel should confirm. For a plain definition, see our glossary entries on copyleft and the broader glossary.

The enterprise exposure

The exposure from a database relicense takes three forms. The first is competitive use and service restrictions, which matter to vendors and service providers far more than to internal users. The second is copyleft and distribution obligations, which can reach your own product if you ship the database or build on it in a way the license treats as distribution. The third is the commercial license demand, which is the most common practical outcome: a vendor that knows you depend on the software and approaches a renewal with new leverage.

All three can apply to software already running in production. This is the point enterprises most often miss. A license change does not retroactively alter the terms on the version you already deployed, but the moment you upgrade, spin up a new cluster, or take a support path that requires a current release, you step onto the new terms. Because databases are patched for security and scaled as the business grows, that moment usually arrives sooner than a static reading would suggest.

How to map your database relicensing exposure

Mapping starts with finding every place the affected database runs, not just the deployments your team remembers. That means the primary clusters, the read replicas, the caching layers, the embedded uses inside other products, and the copies that live in test, staging, and disaster recovery. A database tends to appear in more places than the architecture diagram shows, and each instance has its own version and therefore its own license state.

With the map in hand, the next step is to classify each deployment against the new license. Most internal instances will sit comfortably inside the terms. A smaller set, usually the ones closest to a customer facing service, will not. Sizing that smaller set is where the real exposure lives, and it is where a clear cost of exposure and a cost to cure can be attached. This is the work our open source license risk assessment is built to deliver, and the gated Redis and Elastic migration guide walks through the method in depth.

Your options: fork, license, or stay

There are three honest paths, and a good decision weighs them on equal terms. The fork path moves you to Valkey or OpenSearch and restores open terms, at the cost of a migration and a shift in support model. The license path takes a commercial agreement from the vendor, which can be right where the feature set and relationship justify it, and where our buyer side negotiation keeps the price tied to your actual usage. The stay path holds you on a known version, accepting the support and currency trade that comes with it.

No path is universally correct. A team with light Redis usage and modern clients may find Valkey almost free to adopt. A team deep in Elastic specific features may find the commercial relationship cheaper than the migration. The discipline is to attach an engineering cost, a license posture, and a timeline to each, then choose with eyes open. Our open source remediation advisory runs that comparison and sequences whichever path you choose.

High availability and clustering considerations

Databases carry a constraint that most relicensing decisions elsewhere do not: the change has to happen without losing the high availability and data integrity guarantees the business depends on. A cache layer can sometimes tolerate a brief gap. A primary transactional store cannot. When the migration touches a clustered deployment, the sequence has to preserve quorum, replication, and failover throughout, which usually means running the old and new systems in parallel and cutting over only when the evidence supports it.

This is where many migrations stall, because the license decision is easy compared with the operational one. We treat the two together. The article on database relicensing and high availability clusters sets out how to keep availability intact while the license posture changes underneath it.

Governance for the next change

The Redis, Elastic, and MongoDB changes are unlikely to be the last. The commercial pressure that drove them has not gone away, and other data infrastructure projects sit under the same incentives. The lesson is to stop treating a relicense as a one off fire drill and start treating it as a recurring risk you can govern. A live map of which databases carry which license, a policy that states your tolerance, and an intake gate that flags a change at the next decision point together turn the next relicense into a managed event. Our work on open source governance and policy builds that capability.

The throughline across all of this is plain. Database relicensing is a commercial risk with operational teeth. Map it precisely, size it honestly, choose a contained path, and keep watch for the next change. Done that way, a license move that blindsides one organization becomes a routine decision for yours.

EXPLORE THE CLUSTER

MORE IN THIS CLUSTER

Explore more from this guide.