Database relicensing and your cloud provider.

When a database relicenses, the first instinct is to look at your own code. That is correct but incomplete. A large share of database use runs through a cloud provider as a managed service, and database relicensing and your cloud provider relationship interact in ways that can change your exposure without a single line of your code being touched. The provider sits between you and the license, and what it decides to do becomes part of your risk picture.

Why a relicense reaches your provider first

The source available licenses adopted in the recent wave were aimed squarely at cloud providers. As of March 2024, Redis moved to the Redis Source Available License and the Server Side Public License. In 2021, Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License. The stated target of these terms was the practice of offering the software as a managed service without contributing back. Your provider was the intended audience of the change, which is why the provider reacts before you even notice. Source available is not open source, and neither the Server Side Public License nor these source available terms are approved by the Open Source Initiative.

The paths a provider can take

A provider faced with a relicensed database has a few options, and each one lands differently on you. It can take a commercial license from the vendor and keep offering the original software, which usually shows up as changed service terms or pricing. It can fork the last open version and run that instead, which is how OpenSearch came from Elasticsearch and how Valkey came from Redis. It can rename and rebrand its managed offering around the fork. Or it can deprecate the service and ask customers to move. The path your provider chose determines what you must do, and it is the first fact to establish.

Why cloud providers led the forks

The major forks did not appear by accident. Cloud providers had built large managed businesses on Elasticsearch and Redis under their former open source licenses. When the terms moved to restrict exactly that business, the providers led forks to preserve an open license version they could continue to offer. Amazon Web Services led OpenSearch from Elasticsearch, and the Valkey project carried Redis forward under an open license with broad provider backing. For a buyer, a provider backed fork is significant because it means the operational work of running the open alternative has already been done at scale. The fork stories are worth understanding, and we cover them in the OpenTofu and Valkey fork story.

What your provider contract actually says

A managed service contract decides where the obligations sit, and the answer is often less protective than buyers assume. Many agreements place compliance responsibility on the customer for how the software is used, even when the provider operates it. Some include the right for the provider to change the underlying software or its terms with notice. Read your agreement for three things: who is responsible if the underlying license changes, whether the provider commits to a specific software version or reserves the right to substitute, and what indemnity, if any, covers a license dispute. These clauses turn an abstract relicense into a concrete allocation of risk between you and your provider.

Should you move to the provider's fork?

For many buyers, moving to the provider managed fork is the least disruptive answer. The provider has done the operational engineering, the migration is often a service change rather than a rebuild, and the result returns you to an open license footing. The caution is the same one that applies to any fork: confirm compatibility against your real workloads rather than assuming parity, and read the new service terms so you understand what you are agreeing to. Where the fork is not a clean fit, a full migration may be warranted, which we cover in migrating from Elasticsearch to OpenSearch.

Bringing the picture together

The full exposure from a database relicense is the sum of what runs in your own code and what runs through your provider. Map both. Establish which path your provider took, read what your contract commits each side to, and confirm whether a managed fork resolves the question or simply defers it. The obligations that flow from the license itself are covered in our guide to database relicensing compliance obligations. Interpretation of your provider agreement is a question for your own counsel.

Untangling provider exposure is part of our open source remediation advisory service. For the wider frame, read our pillar on Redis, Elastic, and database relicensing.