Elastic, the company behind Elasticsearch and Kibana, announced this week that they’re changing the license for both products from Apache 2.0 to a dual license under the Server Side Public License (SSPL) and the Elastic License. The move is directly aimed at Amazon Web Services, which offers Elasticsearch as a managed service (Amazon Elasticsearch Service) without contributing back to the project or paying Elastic for the privilege.
This is the latest escalation in an ongoing war between open-source companies and cloud providers, and it raises fundamental questions about the sustainability of open-source business models.
The Core Conflict#
The tension is straightforward: Elastic creates Elasticsearch, invests millions in development, and open-sources it under a permissive license. AWS takes that code, wraps it in a managed service, and sells it to customers. AWS captures significant revenue from Elasticsearch without the development costs, while Elastic has to compete with its own product being sold by the world’s largest cloud provider.
Elastic CEO Shay Banon didn’t mince words in the announcement: “AWS and Amazon Elasticsearch Service. They have been doing things that we think are just NOT OK since 2015 and it has only gotten worse.”
This isn’t the first time we’ve seen this pattern. MongoDB moved to the SSPL in 2018 for similar reasons. Redis Labs changed licenses for certain modules. Cockroach Labs adopted the Business Source License. Each time, the motivation is the same: cloud providers are using permissive open-source licenses to build competing services without contributing to the projects they depend on.
What the SSPL Actually Means#
The SSPL is based on the GNU AGPL but goes significantly further. The key provision: if you offer the software as a service, you must open-source the entire service stack — not just your modifications to the software, but all the management, orchestration, monitoring, and infrastructure code you use to deliver the service.
This is specifically designed to be impractical for cloud providers. AWS isn’t going to open-source its entire managed service infrastructure just to offer Elasticsearch. The SSPL effectively prevents cloud providers from offering the software as a service without a commercial agreement with Elastic.
It’s worth noting that the Open Source Initiative (OSI) does not consider the SSPL to be an open-source license. The SSPL’s requirements go beyond what the OSI’s Open Source Definition allows, which means Elasticsearch is, by the OSI’s definition, no longer open-source software. Elastic would argue that’s a technicality — the code is still publicly available, and the vast majority of users are unaffected by the license change. But definitions matter, and this distinction has real implications for organizations with open-source-only policies.
The AWS Perspective#
It would be unfair not to acknowledge AWS’s position. Cloud providers argue that they’re doing exactly what open-source licenses allow — using and distributing software under the terms the creators chose. If Elastic didn’t want AWS to offer their software as a service, they shouldn’t have used the Apache 2.0 license.
AWS has also pointed out that they do contribute to open-source projects and that the community benefits from the scale and accessibility that cloud services provide. Managed services lower the barrier to entry and bring more users to the ecosystem.
There’s some validity to this argument. I’ve seen plenty of organizations adopt Elasticsearch because they could get it as a managed AWS service without the operational overhead of running it themselves. Some of those organizations eventually became Elastic customers for premium features. The relationship between cloud services and open-source adoption isn’t purely extractive.
The Bigger Picture for Open Source#
This license change is a symptom of a structural problem in the open-source ecosystem. The traditional model — build it open source, sell support and enterprise features — worked when the primary way to use software was to run it yourself. In the cloud era, the hyperscalers can offer a better operational experience than most vendors, and they have the scale to do it cheaply.
I’ve been contributing to and using open-source software for most of my career, and I find this situation genuinely troubling. The open-source model has produced some of the most important software in history. But if the economics don’t work for the companies that invest in creating and maintaining that software, the model is at risk.
Several approaches are being explored:
- Source-available licenses like the SSPL and BSL that restrict cloud provider usage while keeping the code public
- Open core models where the community edition is genuinely open source but premium features are proprietary
- Cloud-native licensing that specifically addresses the managed service use case
- Foundation-based governance where projects are maintained by a neutral foundation rather than a single company
None of these are perfect. Source-available licenses fracture the open-source community. Open core can lead to artificial feature restrictions. Cloud-native licensing is legally untested. And foundation governance doesn’t solve the funding problem.
What This Means for Users#
If you’re using Elasticsearch in your organization, the practical impact depends on how you use it:
Self-hosted users: Virtually no impact. The SSPL only triggers if you’re offering Elasticsearch as a service to third parties. Running it internally for your own use is fine under both the SSPL and the Elastic License.
AWS Elasticsearch Service users: The existing service isn’t going anywhere immediately, but Amazon may eventually need to fork the project or develop its own compatible implementation. There may be feature divergence over time.
Elastic Cloud users: No change — you’re already a paying Elastic customer.
My Take#
I sympathize with Elastic’s position more than I’d like to. It genuinely is unfair for a cloud provider to take open-source software, offer it as a competing service, and capture most of the economic value. But I also think the SSPL is a flawed solution that creates confusion about what “open source” means and fragments the ecosystem.
What I’d really like to see is the industry develop a new social contract around open source and cloud services. The cloud providers have built enormously profitable businesses on the back of open-source software, and they should be contributing back proportionally — whether through direct funding, meaningful code contributions, or licensing agreements.
Until that happens, expect more license changes, more forks, and more tension. The open-source model that powered the last 25 years of software innovation needs an update for the cloud era. We just haven’t figured out what that update looks like yet.
Part of the Developer Landscape series — because the code we write exists in an ecosystem shaped by business decisions.