Elastic and AGPL: The 2024 Reversal Explained

The story of Elastic and AGPL is the most quoted reversal in the recent relicensing wave, and it is widely misread. As of 2024, Elastic added the GNU AGPL version 3 as an open source license option for Elasticsearch and Kibana, three years after moving those projects off Apache 2.0. The headline read as a return to open source. For buyers, the reality is more useful and more nuanced. An open source option is back on the table, but it arrives as strong copyleft, and the source available terms that prompted the original concern did not disappear. This article explains what changed, what did not, and how the Elastic and AGPL decision should shape your own license posture.

We write from the buyer side, as an independent advisory paid only by the buyer. This is not legal advice. For interpretation of the AGPL, the Server Side Public License, or the Elastic License as they apply to your deployment, we point you to your own counsel.

What Elastic actually changed in 2024

To read the reversal correctly, start with the history. Elasticsearch and Kibana were Apache 2.0 projects until 2021, when Elastic moved them to a dual model of the Server Side Public License and the Elastic License. Neither of those is approved by the Open Source Initiative, so the projects ceased to be open source in the formal sense. That move triggered the AWS led OpenSearch fork. As of 2024, Elastic added the GNU AGPL version 3 as a third option, restoring an OSI approved open source path while keeping the Server Side Public License and the Elastic License available. The projects became multi licensed rather than simply open again.

The distinction matters for your records. The 2024 change did not retract the Server Side Public License or the Elastic License. It added a choice. Which license governs your use now depends on which build you run and which terms you accept. An organization that simply pulled the default distribution may be on different terms than one that deliberately selected the AGPL build. The Elastic and AGPL story is therefore not a single switch you can assume applies to you. It is an option you have to elect and document.

Why AGPL is not a clean return to where you started

The instinct on hearing that Elasticsearch has an open source option again is relief, and a sense that the problem closed itself. That instinct overshoots. The GNU AGPL is an open source license, but it is the strongest copyleft license in common enterprise use. Its defining feature is the network clause. Where the ordinary GPL triggers source sharing obligations on distribution, the AGPL extends those obligations to software made available to users over a network, even when no copy of the software is handed out. For a search engine that often sits behind a service interface, that clause is not academic. It can reach the way you offer the software to others.

So the choice for a buyer is not open versus closed. It is one set of conditions traded for another. The Server Side Public License restricts offering the software as a service to third parties and is not OSI approved. The AGPL is OSI approved but imposes copyleft and network distribution obligations. The Elastic License is the most permissive for internal use but is not open source and carries its own field of use limits. The right answer depends entirely on how you deploy. Pure internal analytics has a very different risk profile than a customer facing search service built on the same engine.

What it means for your deployment pattern

Map the decision to how you run the software. For internal use that never reaches outside users, all three options usually permit the deployment, and the practical question is which terms your governance policy prefers and which you can evidence. For software you embed in a product shipped to customers, or offer as a hosted service, the AGPL network clause and the Server Side Public License service restriction pull in opposite directions, and the engineering and commercial cost of each path differs sharply. The exposure lives in the deployment pattern, not in the project name.

This is why a blanket statement that Elasticsearch is open source again is unsafe to act on. It is open source if you elect the AGPL build and accept the copyleft, and it is source available if you stay on the Server Side Public License or the Elastic License. The work for a buyer is to confirm which build is actually running, in which environment, and under which terms. That is the kind of question our open source remediation advisory is built to answer, by tracing the component through your stack and mapping each instance to a license and a cost.

Does OpenSearch still matter after the reversal?

A frequent follow up is whether the AGPL option makes OpenSearch redundant. It does not. OpenSearch remains a separate project under the Apache 2.0 license, with its own community and governance, and Apache 2.0 carries no copyleft or network obligations at all. For an organization that wants a permissive open source license rather than strong copyleft, OpenSearch can be the cleaner posture even now that Elasticsearch offers AGPL. The two are not interchangeable, and the right choice rests on your tolerance for copyleft, your migration cost, and your view of each project's roadmap. We walk through that tradeoff in migrating from Elasticsearch to OpenSearch.

The wider pattern is worth noting. Redis followed a similar arc, adding the AGPL as an open license option as of 2025 after its own source available move. Two of the most prominent relicensing events have now partially reversed toward open source, but both did so through copyleft rather than a permissive license. We cover the parallel in Redis and AGPL, the 2025 reversal explained. The lesson for buyers is that a reversal is not a reset. It is a new license to evaluate on its own terms.

What a buyer should do now

Start by confirming the facts of your own estate. Identify every place Elasticsearch and Kibana run, the version and build of each, and the license each one is actually under. Then classify each instance by deployment pattern, separating internal use from anything that reaches external users. Where a customer facing or hosted pattern meets the AGPL network clause or the Server Side Public License service restriction, size the options side by side, including staying put, electing the AGPL build, or moving to OpenSearch. Keep the legal interpretation with your counsel and the commercial sizing with your advisory, and the decision stays fast and clean.

The Elastic and AGPL reversal is good news for buyers who want an open source path back. It is not a reason to stop paying attention. For the wider landscape, see the Redis, Elastic, and database licensing pillar, and to confirm your own exposure first, read is your Elasticsearch use affected.