Database relicensing compliance obligations.

Database relicensing compliance obligations are a frequent source of confusion, and the confusion is understandable. The obligations are not uniform. They depend on which license a project adopted, which version you run, and how your deployment is exposed to the outside world. A clear answer requires separating these variables rather than reaching for a single rule. This guide does that, and points you to the inventory work that turns the answer from a guess into a record.

Which databases changed their license and when

The timeline matters because the version you run carries the terms in force when that version shipped. MongoDB moved to the Server Side Public License in 2018. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License in 2021. As of March 2024, Redis moved to the Redis Source Available License and the Server Side Public License. Each of these projects later added an open license option for newer releases, which means a single product name can span several license states across its version history. Source available is not open source, and none of these source available licenses are approved by the Open Source Initiative.

What the Server Side Public License actually requires

The Server Side Public License is built around a single trigger: offering the licensed software to third parties as a service. When that trigger is met, the license attaches a broad source disclosure condition that reaches not just the software itself but the programs used to make it available as a service. For a company running the database for its own internal needs, that condition typically does not fire. For a company that resells the database functionality as part of a hosted offering, it can. The competitive restrictions in the source available terms are covered in more depth in our piece on the competitive restrictions in the Server Side Public License, and the mechanics in the Server Side Public License explained.

Internal use versus offering a service

The single most important distinction in database relicensing compliance is internal use against external service. Most of the heavier conditions in these licenses turn on whether you are offering the software to others. A database that backs an internal analytics tool sits in very different territory from one that powers a feature your customers pay to use. The line is not always clean, which is exactly why it deserves careful mapping rather than assumption. We treat this boundary directly in relicensing and internal versus external use.

Build a version accurate inventory first

No compliance answer is possible without knowing which versions of which databases you run and where. Use software composition analysis to enumerate every instance, then record the version of each, because the version sets the license. A manifest that lists a database by name without a version is not enough, since the same product can carry an open license in one release and a source available license in the next. The inventory is the foundation, and it is the deliverable that lets every later question be answered with a record rather than a recollection. We cover the discipline in our pillar on Redis, Elastic, and database relicensing.

Map obligations to each deployment

With the inventory in hand, classify each deployment by exposure: internal only, customer facing, or offered as a service. Then attach the relevant license conditions to each. The work concentrates the analysis where it matters, which is the small set of deployments where your use intersects what the license actually restricts. The rest of the inventory matters for completeness, but it rarely drives a decision. This mapping is also what makes a future audit answerable, because it produces a defensible record of what you run, under which terms, and since when.

Choose a path and document it

Where an obligation applies and you do not wish to carry it, the options are familiar: move to an open license version or a fork such as OpenSearch or Valkey, take a commercial license from the vendor, or change the deployment so the trigger no longer applies. Whichever you choose, document the decision and the reasoning. A recorded choice, made deliberately and tied to the inventory, is far stronger ground in any later inquiry than a deployment no one examined. Interpretation of whether a specific obligation applies to your use is a question for your own counsel.

Working through these obligations is part of our open source remediation advisory service. To see how a relicense reaches you through a managed service, read database relicensing and your cloud provider, and for the migration path, see migrating from Elasticsearch to OpenSearch.