Elasticsearch license AGPL: the download says otherwise

Elastic's download page for Elasticsearch 9.5.5, released 6 October 2026, still says "This default distribution is governed by the Elastic License, and includes the full set of free features." The Elasticsearch license AGPL change announced in 2024 added AGPLv3 as a source-code option. It did not relicense the artifact you install. If your product embeds or resells search, that gap is the whole decision.

Most teams last looked at this in August 2024, read a headline that said the matter was settled, and moved on. What follows is what Elastic's own licensing FAQ and download page say today, what the Elastic License 2.0 actually forbids in its own words, and which teams the distinction genuinely binds. This is a licensing orientation, not legal advice; your counsel signs off, not your architect.

What you are looking at	Elasticsearch	OpenSearch
Default download	Elastic License	Apache 2.0
Source-code license options	SSPL 1.0, AGPLv3, Elastic License v2	Apache 2.0
Offering it as a hosted service	Restricted under ELv2	Permitted under Apache 2.0
Steward	Elastic	OpenSearch Software Foundation

Elastic added AGPLv3 to the source, not to the release

On 29 August 2024, Shay Banon published a post titled "Elasticsearch is open source again", which said "we will be adding AGPL as another license option next to ELv2 and SSPL in the coming weeks." The Elastic licensing FAQ puts it the same way: "In September 2024, we are adding the Open Source Initiative (OSI) approved AGPLv3 license as an option alongside SSPL and our Elastic license."

Read the verbs. Adding, alongside, an option. Nothing in either sentence replaces anything. Two paragraphs later the same FAQ states the part the coverage dropped: "Our releases will continue to be under the Elastic License."

That is not a leftover from an older version of the page. The current download page for Elasticsearch 9.5.5, with a release date of 6 October 2026, carries the Elastic License sentence and does not mention AGPL at all. Two years after the announcement, the default distribution is governed by the same license it was before.

One thing we will not tell you is which Elasticsearch release first shipped with the AGPL option in its source tree. The FAQ said the change "is expected to take place before the 8.16 release is generally available", and that is a stated expectation, not a record of what happened. We found no primary source confirming it, so we are not asserting a version number. If your compliance file needs one, read the LICENSE.txt in the tag you actually build from.

The Elasticsearch license AGPL option covers the free source only

The scope is narrower than "Elasticsearch is AGPL" suggests. Elastic's FAQ says AGPLv3 applies to "the free portions of the source code of Elasticsearch and Kibana", while "The Elastic License 2.0 applies to our distribution and the source code for the free and paid features." Three source licenses are on offer: SSPL 1.0, AGPLv3 and Elastic License v2.

So relying on AGPLv3 is a build decision, not a download decision. You take the source, you take only the free portions, you compile it yourself, and you accept AGPLv3's network copyleft on whatever you then distribute or expose over a network. That is a real engineering commitment: your own build pipeline, your own plugin and upgrade testing, your own CVE watch on a tree you no longer get as a signed vendor artifact. Teams that read the headline and changed nothing about how they obtain Elasticsearch did not acquire an AGPL binary. They are still running an Elastic License one.

The AGPL option also arrives with its own obligation rather than removing one. AGPLv3's section 13 is the clause that sets it apart: if you modify the Program and your version supports remote network interaction, your modified version "must prominently offer all users interacting with it remotely" the chance to receive its Corresponding Source at no charge. For a product team that has patched an analyzer, written a custom plugin or forked a scoring component, swapping ELv2's hosting limitation for AGPLv3's network-source obligation is a trade between two sets of conditions, not an escape from conditions. Which trade is cheaper depends entirely on whether your differentiation lives inside the search engine or around it.

What the Elastic License 2.0 actually forbids

ELv2 is short, and the restrictive part is three numbered limitations. From the license text: you may not "provide the software to third parties as a hosted or managed service" where that service "provides users with access to any substantial set of the features or functionality of the software"; you may not "move, change, disable, or circumvent the license key functionality in the software"; and you may not "alter, remove, or obscure any licensing, copyright, or other notices of the licensor in the software."

Notice what is absent. There is no clause against embedding, and no clause against redistribution as part of a larger product. Elastic's FAQ says as much: you may embed and redistribute Elasticsearch "as long as you're following the limitations in ELv2". The FAQ also notes that public cloud providers "will need to comply with SSPL, AGPLv3 or the Elastic License" to offer a version released after the change.

Limitation 1 is the one that decides most cases, and it turns on a question of fact rather than a question of law: is the search your customers are getting substantially Elasticsearch's own feature set, or is it your product, which happens to run Elasticsearch inside it? A log analytics product whose UI is a thin wrapper over Elasticsearch queries sits very differently from an aquaculture platform where search ranks pond and farmer records inside a workflow nobody would call a search service. Limitation 2 matters to anyone who has ever been tempted to patch around a license-gated feature in a vendored dependency, which is the same class of problem we see in Oracle's JDK 21 license change: the code keeps running, and the entitlement quietly stops.

Who this affects, and who it does not

Comparison posts never draw this line, so here it is. The distinction binds you if you embed, white-label, bundle or resell Elasticsearch inside a product you ship to customers, or if you offer Elasticsearch, or something substantially equivalent to it, as a hosted or managed service. If you are an ISV whose contract grants the customer a copy of your platform and that platform contains an Elasticsearch node, you are in scope and should read ELv2 line by line with counsel.

It does not bind you if you run Elasticsearch to power search inside your own application, self-host it for your own use, or operate it internally for logs, metrics and observability. Running a cluster your own staff and your own users query through your own app is ordinary use of the default distribution. You do not need to migrate anything, and a licensing review is not a reason to start one. The honest answer for most internal deployments is that nothing changed in 2024 and nothing changed in 2026.

The grey zone sits between those two: multi-tenant SaaS where tenants get an index each, white-label deployments at a reseller's domain, on-premise appliances. Those are judgment calls on limitation 1's "substantial set of the features or functionality" test, and they are worth the hour of legal time rather than an architecture decision made from a blog post.

There is a second group the license question reaches indirectly: teams whose Elasticsearch version is old enough that the license they agreed to is not the license that now applies to upgrades. Elastic's FAQ is clear that cloud providers must comply with SSPL, AGPLv3 or the Elastic License to offer "a version released after this change", which means the relevant terms attach to the release you move to, not the one you installed years ago. A cluster frozen on an old major version is a modernization problem wearing a licensing costume, and the upgrade path is where the two meet.

Should you migrate from Elasticsearch to OpenSearch?

Only if the license actually binds you, and then only after you have costed it. OpenSearch states that it is "open source that stays open: vendor-neutral, fully Apache 2.0 licensed from ingest to dashboard, and a project of the Linux Foundation." The OpenSearch Software Foundation describes itself as "a project of The Linux Foundation" and is explicit that it "is not involved in technical oversight of the OpenSearch open source project" — technical governance sits under a separate technical charter. Apache 2.0 end to end removes the hosted-service question entirely, and foundation stewardship removes the risk of a second unilateral relicensing.

Take the counter-argument at full strength. AGPLv3 is OSI-approved, and if you are willing to build from source you have a genuinely open-source Elasticsearch available to you today. ELv2 permits embedding outright. Elastic's paid features, support contract and commercial roadmap are real value that an Apache 2.0 fork does not hand you, and a migration consumes quarters of engineering attention that was promised to your product. We will not quote benchmark comparisons between the two in either direction, because we have not verified any of them; anyone who shows you a performance table as the reason to switch is selling something.

The migration mechanics deserve the same skepticism. The commonly used approach is a snapshot of the source cluster restored into the target, then a reindex where mapping or analyzer definitions differ, but neither vendor publishes a supported Elasticsearch-to-OpenSearch path that we were able to open and read, so treat any step-by-step guide you find as community knowledge to validate on your own data. Plan for client libraries, plugins, security configuration and Kibana-to-OpenSearch-Dashboards work as separate pieces. This is leverage-first thinking of the kind we laid out for RHEL alternatives: establishing that you have an alternative is often worth more than executing it.

Where the Elasticsearch license decision belongs in your modernization plan

Treat it as a dependency-entitlement question, not a search question. The practical sequence is short. Read the license file in the tag you build from, not the blog post. Write down, in one paragraph, what your customers receive and whether it is substantially Elasticsearch's feature set. If it is, price three options — comply with ELv2 as it stands, build the free source under AGPLv3 and take on the copyleft and the build pipeline, or move to Apache 2.0 OpenSearch — and give each a number before anyone opens an editor.

That audit tends to surface the rest of your dependency licenses too, which is where it stops being a legal errand and becomes engineering work. If you are weighing whether an embedded search tier forces a re-platform, our legacy application modernization team maps the dependency and entitlement surface of a shipped product and costs the three options against your release calendar, so the license decision arrives with a number attached instead of a hunch. Bring us the version you build from and the contract clause that worries you; those two artifacts answer most of it.