RELICENSING

The OpenSearch fork story.

The OpenSearch fork story is the clearest example of how a community answers a relicense. When Elasticsearch moved to source available terms, a fork preserved an open source path. This article tells the story plainly and draws the lessons for any enterprise weighing a similar move.

A fork is what happens when a license change leaves part of a community behind. The OpenSearch fork story is worth understanding not only because Elasticsearch is widely deployed, but because it shows the full pattern: a relicense, a stranded user base, a continuation under an open license, and the slow divergence that follows. For an enterprise mapping its own exposure, this story is a template for what a community fork can and cannot do for you.

What happened to Elasticsearch

Elasticsearch and its companion Kibana were distributed under the permissive Apache 2.0 license for years, which let cloud providers and enterprises build freely on top of them. In 2021 the maintainer moved both projects from Apache 2.0 to a dual model of the Server Side Public License and the Elastic License. That change turned an open source project into a source available one. The Server Side Public License is not approved by the Open Source Initiative, and its service condition targets parties who offer the software as a managed service. For the mechanics of that clause, see the competitive restrictions in the SSPL.

For most enterprises running Elasticsearch internally, the change was a question rather than an immediate breach. For cloud providers offering Elasticsearch as a service, and for vendors building products directly on it, the new terms were a direct obstacle. The Apache 2.0 freedoms they had relied on were gone for any future release, and the path forward under the new license was uncomfortable. That is the condition a fork exists to resolve.

Why the fork was created

AWS led the creation of OpenSearch, a fork taken from the last Apache 2.0 release of Elasticsearch and Kibana. The fork continued under Apache 2.0, preserving the open source license that the original had left behind. The legality of forking here rests on a simple point: the code released under Apache 2.0 remains available under Apache 2.0 forever, and anyone may continue from it. A relicense governs future releases, not the freedoms already granted on past ones.

This is the central mechanic of every community fork. OpenTofu did the same for Terraform after the Business Source License change, and Valkey did the same for Redis after its move to the Server Side Public License. The fork captures the last open release and carries it forward, giving the stranded community a continuation it controls. The relicense cannot reach backward, which is exactly what makes the fork possible.

Is OpenSearch a drop in replacement?

At the moment of the fork, OpenSearch and Elasticsearch were nearly identical, because one was a copy of the other. Over time they have diverged. Each project has added features, changed clients, and made design choices the other did not follow. For many common search and logging use cases OpenSearch remains a practical substitute, but the two are no longer interchangeable in every detail. An enterprise depending on a recent Elasticsearch feature, or on specific client behavior, cannot assume a clean swap.

The practical lesson is that a fork solves the license problem but introduces an engineering problem. Migrating is real work: data reindexing, client updates, query compatibility, and operational retraining all have a cost. That cost is usually far smaller than the exposure of running source available software where the license no longer fits, but it is not zero, and it should be scoped and tested rather than assumed.

What the fork does and does not solve

Moving to OpenSearch under Apache 2.0 removes the source available restrictions that apply to relicensed Elasticsearch. That is the point, and for many enterprises it is reason enough. What the move does not do is end the discipline of tracking license state. OpenSearch carries its own license, its own dependencies, and its own future, and the broader relicensing pattern can recur in any project. A fork is a destination, not an exemption from governance.

Lessons for buyers

Three lessons carry over to any relicense. First, the existence of a credible fork is a strong containment option and a source of negotiating leverage, because it gives you an alternative to paying. Second, a fork is most valuable when it has real backing and an active community, since a fork that stalls becomes its own risk. Third, the decision between forking, removing the dependency, and negotiating a commercial license should rest on a sized comparison rather than instinct. The relicensing pillar sets out that method, and the open source relicensing FAQ answers the common follow on questions.

Applying the story to your estate

If you run Elasticsearch, the OpenSearch fork story is not history, it is an open decision. Record which version you run and under which license, describe how you deploy it, and weigh the OpenSearch migration against the cost and terms of staying. Where the question touches the service condition, put the specific facts to your own counsel. The same approach applies wherever a project you depend on has a fork waiting, because the choice the Elasticsearch community faced is the choice the next relicense will hand you.

COMMON QUESTIONS

Questions buyers ask.

CONTAINMENT

Weigh the fork against the cost of staying.

A confidential relicensing exposure review. Independent, buyer side, paid only by you.

Not ready to talk? Read the free open source license risk guides first.