Elasticsearch Forked. Now What?

This post was originally published on Medium and moved here later. The diagram was added and the post updated during the move.

AWS announced it was forking Elasticsearch on January 21, 2021, in a blog post called Stepping up for a truly open source Elasticsearch , about a week after Elastic changed the license on Elasticsearch and Kibana. The fork picked up the name OpenSearch in April, and 1.0 went generally available on July 12th, so this seems like a reasonable moment to work through what actually happened this year and whether it changes anything for you.

Most of what has been written about this concerns who was right, and I don’t find that a useful question to sit with for long. If you operate a search cluster the questions that matter are narrower than that. Did your license change, do you have to do anything about it, and what are you signing up for in either direction.

What Elastic changed

In January, Elastic announced that Elasticsearch and Kibana would leave Apache 2.0 and become dual licensed under the Server Side Public License and the Elastic License, starting with 7.11. The reason given was cloud providers running Elasticsearch as a managed service without contributing back, and AWS was named plainly enough that nobody had to guess at the target.

It’s worth being careful about what actually changed here, because plenty of people read the announcement as “Elasticsearch is no longer free” and that isn’t what happened. You can still download it, run it in production, and pay nothing at all. What the SSPL stops you doing is offering the software to other people as a service without also releasing the software you use to run that service, and if you’re running a cluster to power your own product then that clause never comes up.

SSPL and whether it counts as open source

MongoDB wrote the SSPL in 2018 for exactly this situation. The Open Source Initiative does not consider it an open source license, and MongoDB eventually withdrew it from the approval process, so this is less a matter of opinion than of a definition the license doesn’t satisfy. You can argue about whether that definition is the right one, and people do, but that’s a separate argument from where the license currently stands.

Where it stops being academic is procurement and packaging. A lot of organizations have policies written in terms of OSI approved licenses, and downstream distributors have obligations that a copyleft license with a service clause makes genuinely awkward. Linux distributions are not going to carry SSPL software in their main repositories, so if your Elasticsearch has been arriving through a package manager rather than a tarball, that pipeline may quietly dry up on you.

What forking 7.10.2 gets you

AWS forked Elasticsearch and Kibana at 7.10.2, the last release under Apache 2.0, and named the result OpenSearch in April. The inherited history is the part that matters in practice, because everything through 7.10.2 is shared. The query DSL is the same, index formats are the same, your mappings carry over, and most application code cannot tell the difference.

OpenSearch also absorbed the plugins that were previously Open Distro for Elasticsearch , so alerting, anomaly detection, index state management, k-NN, SQL, and the security plugin all ship in the box rather than being bolted on afterward. Anyone already running Open Distro is looking at something closer to a rename with better packaging than a fork. What you get at 1.0 is 7.10.2 with those plugins folded in and relicensed as one coherent thing, which is a sensible place to start from and is also, unavoidably, several releases behind where Elasticsearch is now.

Where the two will drift

Compatibility today is roughly as good as it is ever going to be, since the fork is three months old and both sides started from identical code. I’d plan on the gap widening rather than hoping it stays narrow, because that’s the direction these things always go.

Nothing Elastic ships from 7.11 onward turns up in OpenSearch unless somebody reimplements it, and nothing OpenSearch builds turns up in Elasticsearch. Two teams with different priorities working from separate codebases drift apart, and the drift tends to accelerate once the easy shared ground has been covered.

The first place I’d expect to feel it is the client libraries. Those were relicensed along with the server, and there’s already conversation about clients verifying what they’ve connected to and declining to talk to anything that isn’t the official distribution. If you’re making plans around this fork, treat the client library as a decision you will eventually have to make rather than a detail that sorts itself out.

Do you need to do anything

Probably not, and I’d rather say that clearly than have somebody kick off a migration on my account. The urgency in this year’s coverage has not matched the exposure that most teams running a cluster actually have.

If you’re on 7.10 or earlier then your software is Apache 2.0 licensed and nothing about that changed retroactively. Upgrading to 7.11 or later means accepting the new license, and for most people that is genuinely fine. Read it, confirm it doesn’t conflict with anything you’ve promised a customer, and carry on with your week.

The group with a real decision to make here is smaller than the volume of discussion suggests. If you embed Elasticsearch in a product you distribute, or you offer search as a service to your own customers, or you work somewhere whose policy permits only OSI approved licenses, then this is genuinely your problem. Everybody else has a reading assignment rather than a project.

Who should move

Moving makes sense if the license conflicts with your business model, if you were already on Open Distro, or if you’re on AWS and want the managed offering to keep tracking the open source project instead of drifting away from it. In the first case it isn’t really a choice, and in the other two you’re mostly formalising a position you already held.

Staying makes sense if you’ve built on features that arrived after 7.10, if you pay Elastic for support and get real value from that relationship, or if you simply don’t have a licensing problem to solve. Migrating a search cluster is genuine work carrying genuine risk, and taking that on for ideological reasons when your business has no exposure is a bad trade.

For most teams the answer is to do nothing yet, stay on 7.10 for the moment if you can, and look again in six months once the two projects have started to actually differ. The decision gets much easier when there’s something concrete to compare, and three months after a fork there isn’t.

Betting on a project versus betting on a vendor

The one thing I’d push back on is any pitch of OpenSearch as a straightforward win for open source. The license really is better, Apache 2.0 is Apache 2.0, and if the relicensing was your problem then the fork solves it outright.

Governance and licensing are different questions though, and OpenSearch right now is a project that AWS created, AWS staffs, and AWS controls. Choosing it means you have swapped one vendor steering the roadmap for a different vendor steering the roadmap, and what protects you in that arrangement is the license rather than the governance.

That protection isn’t nothing, to be fair about it. Apache 2.0 means anyone can fork the code again if AWS starts making decisions the community hates, and that backstop is exactly what Elasticsearch users have just lost. It still isn’t the same thing as a project run by a foundation with several companies around the table, and saying otherwise would be doing the fork a favor it hasn’t earned yet.

What I’ll be watching over the next year is whether contributors turn up from outside AWS, and whether the project’s decisions start to look like community decisions rather than vendor decisions. That will tell you a great deal more about where this ends up than any feature comparison will.

If you’re weighing a move and want to talk through what it would actually involve, please reach out.