Open-source business models: the three-year verdict on source-available licences
HashiCorp, Redis, and Elasticsearch all changed licences to fight cloud providers. Two reversed. Here's what the record shows.
Between August 2023 and March 2024, three of the most widely deployed open-source infrastructure projects changed their licences within twelve months of each other. HashiCorp flipped Terraform from MPL 2.0 to the Business Source Licence. Redis moved from BSD to a dual SSPL/RSAL structure. And Elasticsearch, which had already left Apache 2.0 in 2021, deepened its proprietary stance. The conventional wisdom at the time: open-source business models could not survive cloud providers free-riding on community-funded code.
By May 2025, two of the three had reversed course. Redis 8 relicensed under AGPLv3, a genuine OSI-approved open-source licence. Elasticsearch added AGPL as an option alongside its commercial Elastic Licence. HashiCorp was absorbed into IBM for $6.4 billion, and the OpenTofu fork (the community's response to the BSL switch) now leads on contributor activity. The licence wars lasted roughly two years. What they produced, mostly, was forks, contributor attrition, and a sharper picture of what actually holds up.
The problem they were all trying to solve
Each company had the same adversary: AWS, GCP, and Azure offering managed versions of their open-source software without meaningfully contributing back to the project.
Amazon ElastiCache and MemoryDB run on Redis internals. Amazon OpenSearch forked Elasticsearch after the 2021 licence change. AWS Elastic MapReduce used Terraform at scale. The companies building this infrastructure watched cloud providers extract substantial revenue from their code while the original maintainers footed the engineering bill.
The licence change was an attempt to fix that imbalance. The Business Source Licence limits commercial use for the first four years. The SSPL requires any company offering the software as a managed service to open-source its entire platform stack, making it unusable for cloud providers without compliance overhead they were not willing to take on. Neither solved the problem. Both created a different one.
Why the restrictions didn't work
The cloud problem isn't a licensing problem. It's a distribution problem. AWS doesn't need your source code. It already has it, from the years before the licence changed. The managed service they sell runs on stable, older versions, not the bleeding edge the project maintainers are actively developing. A licence restricting future commercial use doesn't reach code already in production.
What the licence changes did reach was the contributor community. Developer ecosystems are built on trust that the ground rules won't shift. When MongoDB moved from AGPL to SSPL in 2018, external contributions declined noticeably within a year. When Redis made the same move in March 2024, the Linux Foundation announced Valkey, a community fork, within two weeks, with immediate institutional backing from AWS, Google, and Ericsson. A year after the Redis licence change, devclass found the project had lost most of its external contributors to Valkey.
The effect is asymmetric. Cloud providers have legal teams and can work around new licences by forking, freezing, or substituting. Individual contributors have simpler calculus: if the licence changed once, it can change again. The project is no longer safe to build on.
The reversals and what they mean
Elasticsearch re-added AGPLv3 as a licence option in September 2024 — the first major reversal in the wave. Redis followed in May 2025 with Redis 8 under AGPLv3. Neither company framed it as a defeat publicly. Both described it as a business decision to re-engage the open-source community.
The timing of both reversals tracks with a shared signal: the original licence change had not improved the competitive position against cloud providers, while it had visibly damaged the community. Amazon OpenSearch continued to grow after Elasticsearch's 2021 switch. Valkey gained production deployments at companies that would previously have defaulted to Redis. The companies reversed when it became clear the licence wasn't solving the original problem and was clearly creating a new one.
The honest read: a company that reversed is not in the same position as one that never changed its licence. Redis has more external contributors on Valkey than on Redis. Elasticsearch competes with a fork backed by the company that once was its biggest threat. Reversals are recoverable, but they're not free.
Three open-source business models that held up
Not every open-source company tried to solve the cloud problem through licensing. The ones that didn't mostly built sustainable businesses anyway, using one of three approaches.
Managed cloud, operated by the original author
Elastic pioneered this before the licence drama. Elastic Cloud, the managed service the company sells directly, competes with Amazon OpenSearch on the same terrain. The bet is that a customer willing to pay for a managed service will choose the original author because the original author is better at operating it: deeper institutional knowledge, faster access to new features, tighter SLAs. Neon (managed Postgres), PlanetScale, and Cockroach Labs have built variations of the same thesis. None of them restricted their licences to do it; they competed on operational quality instead.
Open core
Selling the enterprise edition (RBAC, SSO, audit logs, compliance tooling) on top of a genuinely open-source base. GitLab is the clearest example of this done right at scale. Grafana Labs runs a similar structure. The model works when the core is genuinely useful to the community and the enterprise layer is genuinely useful to enterprise buyers. Most companies that attempt open core get that ratio wrong. The ones that got it right tend to have recurring revenue uncorrelated with the cloud-provider problem.
Foundation governance
PostgreSQL, Kubernetes, and Linux have stayed open source because no single company owns them. Their governance structure is foundation oversight, multiple major contributors, and no single entity with the authority to change the licence. That constraint turned out to be protective. PostgreSQL runs more production workloads in 2026 than any proprietary relational database, and has done so without a single commercial licence change in its history.
| Project | Original licence | Change | Community fork | Status, 2026 |
|---|---|---|---|---|
| Terraform (HashiCorp) | MPL 2.0 | BSL 1.1 (Aug 2023) | OpenTofu (CNCF) | Acquired by IBM ($6.4B); OpenTofu leads contributor activity |
| Redis | BSD | SSPL/RSAL (Mar 2024) | Valkey (Linux Foundation) | Reversed to AGPL (May 2025); external contributors mostly on Valkey |
| Elasticsearch | Apache 2.0 | SSPL/Elastic Licence (Jan 2021) | Amazon OpenSearch | Re-added AGPL (Sep 2024); Elastic Cloud business continues |
| PostgreSQL | PostgreSQL Licence | None | None | Still dominant; foundation governance intact |
| Kubernetes | Apache 2.0 | None | None | Still dominant; CNCF governance intact |
“If you need a licence change to compete with cloud providers, you probably need a different product strategy.”
What this means for open-source business models in 2026
Three things are sharper now than they were in 2023. First: licence restrictions don't reach the problem they're designed to solve. Cloud providers fork, freeze a version, or substitute before the change takes effect. The licence change is expensive to the community and largely free to the cloud provider.
Second: forks are faster than they used to be. OpenTofu reached production readiness in under a year, backed by CNCF infrastructure and AWS engineering resources. Valkey did the same. The assumption that a fork would take years to gain traction no longer holds. If you change your licence, assume a credible fork exists within six months.
Third: AGPLv3 is the boundary that neither Redis nor Elasticsearch found until after they'd tried something more restrictive. It's an OSI-approved open-source licence, which means it retains community trust, while requiring any company that offers the software as a network service to publish their source code. That covers the cloud-provider case better than most practitioners gave it credit for in 2023. Both companies ended up here after routes through more restrictive territory.
For engineering leaders and founders deciding in 2026 whether to open-source a new infrastructure product: the source-available path has a documented track record now, and the record isn't good. Open core, managed-first, or foundation governance are the models with a credible evidence base. Restricting your source to source-available is mostly a way to lose your community twice: once when you announce, and again when the fork ships.
The projects that will dominate infrastructure in five years are mostly the ones whose governance structures today make it impossible for any single company to change their licence. That's not an accident — it's the most durable moat in open-source software, and it was always available.
Frequently asked questions
Related reading
Bootstrapped or venture-backed: the Indian SaaS calculus in 2026
India hosts the second-largest SaaS ecosystem outside the US. The raise-or-bootstrap question has a different answer in 2026 than it did in 2021. Here's the data behind the shift.
Open-source licensing for engineers: a corporate codebase guide
Legal is not reviewing every npm install — you are. Here is the practical check to run before adding a dependency, and the licence type that catches most SaaS teams off guard.
The AI wrapper debate, three years in: what the survivors built
Three years after the GPT-4 wrapper wave, a handful of AI companies are thriving and most are gone. The split was not random — and the pattern tells you something useful about building on top of LLMs in 2026.