Elastic license change: the SSPL and Elastic License explained.

The Elastic license change is one of the clearest examples of a relicense that caught enterprises by surprise. As of 2021, Elastic moved Elasticsearch and Kibana from the Apache 2.0 open source license to a dual model of the Server Side Public License and the Elastic License. Both are source available, not open source, and neither is approved by the Open Source Initiative. Software that teams had adopted under a permissive open source license was now governed by terms that restrict offering it as a managed service. The code did not move. The license under it did, and with it the rules that govern how the software can be used.

This article explains the Elastic license change in plain terms for buyers. It sits within the wider cluster on Redis, Elastic and database relicensing, and pairs with the question every operator should ask first, covered in is your Elasticsearch use affected.

What the Elastic license change actually did

Before 2021, the core of Elasticsearch and Kibana shipped under the Apache 2.0 license, a permissive open source license that allowed almost any use, including offering the software as a hosted service. The Elastic license change replaced that with a choice between two source available licenses for each release: the Server Side Public License and the Elastic License. Elastic framed the change as a response to cloud providers offering Elasticsearch as a managed service without contributing back. Whatever the motivation, the practical effect for users was that the open source guarantee they had relied on no longer applied to new versions.

The distinction between source available and open source is the heart of the matter. You can still read the source, build it, and run it for most purposes. What you can no longer do, without restriction, is offer the software to third parties as a service. That single shift is what created exposure, and it is why source available is not the same as open source, a point made in full in source available is not open source and why it matters.

The Server Side Public License, in this context

The Server Side Public License is built around the act of offering software as a service. If you make the licensed software available to third parties as a service, the license attaches a broad source disclosure condition that reaches beyond the software itself to the programs used to operate it as a service. The condition is deliberately wide, and it is the reason cloud providers found the license commercially unworkable for a managed offering. For an enterprise running Elasticsearch internally, the service condition usually does not fire, because internal use is not offering the software to third parties. The risk concentrates in companies that host or resell the search and analytics function, not in those that consume it. The same license governs MongoDB and was part of the Redis dual model as of March 2024, so understanding it pays off across the estate.

The Elastic License, and what it restricts

The Elastic License is the second option in the dual model and the one Elastic encourages for most users. It permits broad use, including internal and commercial use, but it carries three core restrictions. You may not provide the software to others as a managed service, you may not circumvent the license key functionality that gates paid features, and you may not remove or obscure licensing or copyright notices. For the typical enterprise that runs Elasticsearch to power its own search and analytics, none of these usually intersect actual use. The exposure appears when the deployment looks like a service offered to third parties, or when a team has worked around a feature gate. Mapping which of your instances fall into those categories is the practical work, and it is rarely as simple as it first appears.

The 2024 reversal and the AGPL option

The story did not end in 2021. As of 2024, Elastic added the GNU AGPL as an open source option for Elasticsearch, restoring an approved open source license alongside the two source available ones. The AGPL is genuine open source, but it is strong copyleft with a network clause, so it carries its own obligations for anyone who modifies the software and exposes it over a network. The addition gives buyers a third path rather than a clean return to the old Apache 2.0 footing. The detail of that reversal is covered in Elastic and the AGPL, the 2024 reversal explained. The reversal does not undo the exposure created between 2021 and 2024 for versions adopted under the source available terms, which is why the version you run still matters.

What to do about the Elastic license change

Start by establishing which versions of Elasticsearch and Kibana you run and under which license each was obtained, because the terms differ by version and by the date you adopted them. Then map how each instance is used, separating internal consumption from anything that resembles a service offered to third parties. For most enterprises that exercise alone resolves the question, and the answer is that internal use sits comfortably inside the Elastic License. Where it does not, the common open path is the AWS led fork OpenSearch, which continues the function under Apache 2.0. That migration decision is weighed in migrating from Elasticsearch to OpenSearch.

The Elastic license change is a settled fact, but its consequences for any one estate depend entirely on use. This article is commercial and licensing risk advisory, not legal advice. For interpretation of the Elastic License, the Server Side Public License, or the AGPL against your specific deployment, your own counsel is the right place to turn.