Why Projects Moved to Source-Available Licenses
Updated 2026-10-17

The history of open source software was built upon mutual collaboration and uninhibited code sharing. Yet over the past several years, prominent market leaders—including MongoDB, Elasticsearch, Terraform, and Redis—abandoned permissive open source terms in favor of Source-Available licensing models.
What arguments did these companies state in their official announcements? Why did traditional open source licenses fail to protect them in the cloud era? And what does Elastic's recent 2024 decision to re-adopt AGPL-3.0 signify for the industry? Based on the Relicensed event database, this guide analyzes the historical timeline and long-term implications.
1. Historical Timeline of Major Relicensing Events
| Date | Project | From → To License | Boundary Release | Stated Core Rationale |
|---|---|---|---|---|
| 2018-10-16 | MongoDB | AGPL-3.0 → SSPL-1.0 | 4.0.3 | Countering hyperscaler free-riding and securing ongoing R&D investments |
| 2019-06-04 | CockroachDB | Apache-2.0 → BSL-1.1 | 19.1 | Preventing managed cloud providers from offering database-as-a-service without contributing |
| 2021-02-10 | Elasticsearch | Apache-2.0 → SSPL-1.0 / ELv2 | 7.11.0 | Halting trademark misuse and commercial service wrapper exploitation by Amazon |
| 2023-08-10 | Terraform / Vault | MPL-2.0 → BUSL-1.1 | 1.5.6 / 1.16.0 | Defending commercial viability against competitors building commercial services off pure upstream code |
| 2024-03-20 | Redis | BSD-3-Clause → RSALv2 / SSPL-1.0 | 7.4.0 | Curbing commercial cloud vendor monopoly over Redis hosting and sustaining ongoing maintenance funding |
2. Three Core Drivers Behind the Announcements
1) Cloud Hyperscaler Exploitation ("Free-Riding")
The central catalyst was the rise of trillion-dollar cloud providers (AWS, Microsoft Azure, Alibaba Cloud) monetizing complex open source databases as hosted services (e.g., AWS Elasticsearch Service, ElastiCache) generating hundreds of millions in revenue, while contributing minimal engineering upstream.
2) Fiduciary Duty to Public Market Shareholders
Ventures like MongoDB, Elastic, and HashiCorp grew from developer startups into public NASDAQ corporations. Pressured to demonstrate quarterly revenue expansion, management could no longer justify funding massive R&D efforts that disproportionately enriched cloud competitors.
3) The Cloud Blind Spot in Traditional Permissive Licenses
Legacy open source frameworks (Apache 2.0, BSD, MIT) were drafted in the desktop and client-server era, premised on binary distribution and copying. They lacked legal mechanisms to regulate remote network invocation over the cloud (SaaS).
3. Industry Reactions: Backlash and the 2024 Return to Open Source
Relicensing sparked severe controversy across developer communities, often labeled as a “bait-and-switch” maneuver. This triggered the creation of major Linux Foundation forks:
- Valkey formed by AWS, Google, and Oracle following Redis's shift.
- OpenTofu formed by the Gruntwork and Linux Foundation alliance after HashiCorp's shift.
- OpenSearch established by AWS after Elasticsearch's transition.
Remarkably, in August 2024, Elastic announced it was adding AGPL-3.0 back to Elasticsearch and Kibana, officially re-entering the OSI open source fold after three years under source-available terms. Redis similarly added AGPL-3.0 in version 8.0.0. This indicates that proprietary lock-in carries severe brand and adoption penalties, prompting companies to search for sustainable middle grounds.
4. Takeaway for Modern Engineering Teams
- Always audit the governance structure of dependencies: Is the copyright owned by a single commercial vendor or held by a neutral non-profit foundation?
- Treat version upgrades as legal events as well as technical ones.
Track all breaking changes across ecosystem software on our Recent Changes Feed.

Get license change alerts
We email you when a tracked project changes its license.
Check the box above to show the Google sign-in button.
Related projects
More guides
Source-Available vs Open Source: The Difference
What separates source-available licenses such as SSPL-1.0, BUSL-1.1, RSALv2 and Elastic-2.0 from OSI-approved open source licenses.
Commercial Use Under BUSL, SSPL, RSALv2 and ELv2
What BUSL-1.1, SSPL-1.0, RSALv2 and Elastic License 2.0 restrict for self-hosting, managed services and embedding in products.
How to Stay on the Last Version Before a License Change
What the version boundary means, how to pin a release before a license change, and what to check about security patches.