1. The Modern Open Source Licensing Crisis
For over two decades, the software engineering world operated on an implicit social contract: open-source maintainers released foundational libraries under permissive licenses (MIT, BSD, Apache 2.0), and commercial companies built proprietary businesses on top while contributing occasional pull requests and funding.
In recent years, that compact fractured under the weight of hyperscale cloud providers (AWS, Azure, Google Cloud). Cloud monopolies repeatedly repackaged open-source databases (Redis, Elasticsearch, MongoDB, Terraform) as managed SaaS offerings, generating billions in cloud revenue without contributing meaningful financial support back to the original creators.
This economic imbalance triggered a massive wave of relicensing, bifurcating the software community between strictly OSI-approved Open Source and newly created "Source-Available" licenses. Understanding these distinctions is now mandatory for every software architect and engineering leader.
2. The Three Families of Software Licenses
Family A: Permissive Licenses (MIT, Apache 2.0, BSD-3-Clause)
Permissive licenses grant nearly unlimited freedom. Anyone can read, modify, distribute, and embed the code into closed-source, proprietary commercial products with virtually no restrictions beyond preserving the original copyright notice.
- Apache 2.0 vs MIT: Apache 2.0 adds explicit patent grant protections, making it the preferred choice for enterprise libraries and foundation projects (e.g. Kubernetes, Rust).
Family B: Strong Copyleft Licenses (GPL-3.0, AGPL-3.0)
Copyleft licenses require that any modified or derivative works distributed to others must also be released under the exact same open-source license.
- The SaaS Loophole: Standard GPL-3.0 only triggers copyleft upon "distribution" of binaries. Running software on a remote server over the web was not considered distribution, allowing companies to exploit GPL software as closed cloud SaaS.
- AGPL-3.0 Fix: The Affero GPL (AGPL) closes this loophole: if users interact with modified software remotely over a network, you MUST provide them with the corresponding source code.
Family C: Source-Available Licenses (BSL 1.1, SSPL, RSAL)
These are NOT Open Source according to the Open Source Initiative (OSI). You are permitted to view the source code, run it internally, and self-host for your own operations. However, you are legally forbidden from offering the software as a competitive managed cloud service.
3. Case Studies: Redis, Elastic, and HashiCorp
| Original Project | Original License | New License | Open-Source Community Fork | Fork License |
|---|---|---|---|---|
| Redis | BSD-3-Clause | RSALv2 + SSPLv1 | Valkey (Linux Foundation) | BSD-3-Clause |
| Terraform | MPL-2.0 | BSL 1.1 | OpenTofu (Linux Foundation) | MPL-2.0 |
| Elasticsearch | Apache 2.0 | SSPL / Elastic (now also AGPL) | OpenSearch (AWS) | Apache 2.0 |
4. The Rise of AGPL-3.0 in the Cloud Era
Many independent indie developers and startups (including Plausible Analytics, AppFlowy, and Baserow) intentionally choose AGPL-3.0 as the ultimate defense mechanism:
- It keeps the project 100% OSI-approved Open Source.
- Individual developers and companies can freely self-host, modify, and run the software internally without paying fees.
- Cloud giants cannot take the codebase, modify it behind closed doors, and resell it as a proprietary competing SaaS without open-sourcing all modifications.
5. Compliance Checklist for Developers & Startups
Before incorporating an open-source tool or library into your tech stack, answer these four compliance questions:
- Is this an imported library or a standalone service? Linking an AGPL library into your proprietary backend can trigger copyleft obligations for your entire proprietary code. Running an AGPL service as a separate Docker container communicating via HTTP API generally isolates your code.
- Are you planning to sell a competing cloud service? If a tool uses BSL or SSPL, you cannot sell a managed service competing with the vendor without purchasing a commercial license.
- Does the project include a patent grant clause? Projects using Apache 2.0 protect you against patent infringement claims by contributors.
- Check the Change Date on BSL projects: Most BSL 1.1 projects (like CockroachDB and Sentry) automatically convert back to standard Apache 2.0 or MIT after 3 to 4 years.
This technical guide was created following our 5-pillar editorial framework. We do not accept monetary compensation or sponsored product placements. All benchmarking tools are tested against real-world criteria.