Every time SSPL appears, the community erupts. "It betrays open source philosophy." "It can't even get OSI certification." "It's not real open source." But what does this outrage actually protect?
A license created by MongoDB in 2018.1 Its core clause is singular: if you offer the software as a service, you must open-source the entire stack that constitutes that service — infrastructure, management tools, monitoring systems included. It was designed to prevent structures where companies like AWS take someone else's open source code and sell it as a cloud service while giving nothing back. OSI (Open Source Initiative) refuses to recognize it as open source, calling it "overly restrictive."2
The Redis Incident: Who Stole What?
Redis had been available under a BSD license for years. Developers around the world contributed code, fixed bugs, and wrote documentation. And AWS took it wholesale and sold it as a managed service called ElastiCache.
AWS did have an official maintainer (Madelyn Olson) in the Redis project, contributing TLS support, failover functionality, and more.3 The contributions weren't zero. But the problem is the imbalance between contribution and revenue. Before the SSPL switch, outside non-employee contributors handled 54% of commits. Yet no revenue returned to Redis Ltd. AWS absorbed a significant portion of Redis traffic while the very developers who built Redis were struggling with server costs and maintenance overhead.
Open source back then was a lawless trove of knowledge. Anyone could take from it, and taking came with no obligations. AWS picked up that trove wholesale and sold it in their own store. No value flowed back to the original team or developers.
Redis Ltd's license change to SSPL happened in this context.4 The new license is a dual license of RSALv2 and SSPLv1. SSPL's core clause is simple: "If you offer it as a cloud service, open-source the entire stack." Instead of accepting this, on March 28, 2024, AWS, Google, Oracle, Ericsson, and Snap jointly launched Valkey under the Linux Foundation.5 They simply walked away.
The Legal Loophole: Designed Plunder
Open source licenses were not written for the cloud era.
When GPL was created, "commercial use" meant modifying and distributing software. The "disclose source upon distribution" clause assumed this scenario. But what AWS did was not distribute software. They ran it on servers and sold it via API. No distribution, so the license clause never triggers. Completely legal plunder.
This loophole is known in the industry as the ASP Loophole or SaaS Loophole. GPL, LGPL, BSD, and MIT all require obligations to trigger on "distribution." But running software on a server and returning only results over a network is legally not distribution. Since no binary is handed to the user, GPL clauses never trigger at all. It first became a problem with the ASP (Application Service Provider) model in the early 2000s, and its scale exploded in the cloud era.
AGPL (GNU Affero GPL) emerged to close this loophole by adding a clause: "Even if you serve it over a network, you must disclose the source." SSPL is its extension — it expands the required disclosure scope to the entire service stack. A natural evolution of licensing in response to technological evolution.
The Reality of "Open Source Purists"
Every time SSPL is announced, Hacker News and Reddit boil over. "Violation of open source principles." "OSI didn't certify it." "Betrayal of the community." I too first encountered the Redis license change story through sensationalist headlines stripped of context. The result was there — "license change" — but not the reason why. Not what AWS had been taking for years. The media profited from the controversy without offering any structural explanation or counterargument. They were bystanders.
Looking at OSI's financial structure makes this even clearer.6 OSI's Platinum sponsors include Google and Microsoft. The very companies restricted by SSPL are the ones funding the organization that declared SSPL "not open source."
OSI certification carries no legal force. Anyone can create any license. Even if OSI declares "this is not open source," it cannot prevent the use of that license. However, OSI certification functions as a de facto industry standard mark. Corporate procurement policies, public software lists, and developer community judgment all use OSI certification as a benchmark. The moment OSI declares "not open source," the entire community is structurally set up to reject that license.
The mechanism works like this:
Big tech openly says "we oppose SSPL" → gets attacked
↓
Declares "violation of open source definition" through OSI
↓
Community developers follow it like doctrine
↓
Big tech maintains the existing structure from behind the scenesUnder the banner of "defending open source philosophy," they are effectively protecting big tech's free-ride pass. "Open source betrayal," "community fracture," "license war" — these headlines generate clicks. Every time the Redis and HashiCorp incidents happened, the media faithfully consumed this gossip. They didn't need to explain where the outrage should be directed. Community anger couldn't change the actual power structure; it was spent as content consumption.
The Paradox: Real Victims Defending Their Own Exploitation
Here is the most bitter point. A significant portion of those enraged by SSPL are developers at small companies or independent developers.
When you actually examine how SSPL affects them:
- Self-hosting users → If you run it internally, SSPL imposes no restrictions whatsoever
- Small-scale service developers → If you're not "offering it as a cloud service," it's equally irrelevant
- Developers at large corporations → Legal team rules "SSPL is not allowed" → they oppose it per company policy
That last case is the key. It's not personal belief — it's a structure where company policy drives opposition opinions into the community. And those companies are precisely the ones restricted by SSPL: AWS, Google, Microsoft.
Yet when OSI declares "this is not open source," individual developers follow that judgment like religion. Among the comments criticizing SSPL on Hacker News, many cannot logically explain why they oppose it. "It's not OSI-certified" is the entirety of their argument.
It's a paradox: the true victims — open source maintainers — end up defending the structure of their own exploitation.
The Recurring Pattern
HashiCorp (Terraform → BSL), Redis (→ RSALv2 + SSPLv1), MongoDB (→ SSPL), Elastic (→ SSPL + Elastic License v2, later adding AGPLv3). The direction of license choice differed — BSL says "competitors can't use it," SSPL says "if you use it, open-source everything." But the business pattern is the same:
Build community with MIT/BSD
↓
Attract VC investment
↓
Revenue pressure mounts
↓
License change
↓
Community outrage → "Traitor"
↓
Big tech forks or moves to another projectThis is not betrayal. It is repeated evidence that MIT/BSD cannot be a sustainable business model in the cloud era. It is actually the illogical position to keep believing "this time will be different" when the same ending plays out every time.
A World Where Virtuous Cycles Became Extractive
When open source began, there was a virtuous cycle. A developer releases code, others use it and benefit, and the results flow back to the community. That structure let us develop using countless libraries for free. It was a clear debt.
But things are different now. The beneficiaries of that virtuous cycle are no longer the developer community — they are cloud platforms. AWS, Google Cloud, and Azure absorb the entire open source ecosystem, and platforms monopolize the profits. Developers still contribute for free; platforms earn trillions from it.
Open source philosophy is not wrong. The world it assumed no longer exists. Taking concepts built for an era without clouds and applying them unchanged to an era where clouds suck in everything legalizes exploitation. And what protects that legality — under the name "open source spirit" — is OSI, the community, and the gossip content published today.
SSPL may not be a perfect answer. But it is an attempt to meaningfully address this structural problem. Branding it a "philosophical violation" and rejecting it is, intentionally or not, taking the side that protects exploitation. It is worth being honest at least once about whose interests are served by those who call this evolution "betrayal."
Footnotes
-
MongoDB, SSPL v1 full text (2018). OSI public review thread: License-review mailing list ↩
-
OSI, SSPL review result — concluded "does not conform to the Open Source Definition" ↩
-
Redis creator Salvatore Sanfilippo (antirez) expressed frustration in his 2019 blog that cloud providers were taking far more revenue than they contributed. The data showing outside non-employees handled 54% of commits before the SSPL switch was presented by Dawn Foster, Data Science Director at CHAOSS, at Monki Gras (accounting for 12% of code additions and 15% of deletions). Despite AWS having a maintainer, there was no revenue return structure whatsoever. Sources: devclass.com — one year after license change analysis, AWS Open Source Blog ↩
-
Redis Ltd., Redis license change announcement (2024.03). The new license is a dual license of RSALv2 (Redis Source Available License v2) and SSPLv1. Note: it is not SSPL alone. ↩
-
Linux Foundation, Valkey project official launch (2024.03.28) — founding members: AWS, Google Cloud, Oracle, Ericsson, Snap. Later expanded to include Alibaba Cloud, Huawei, Canonical, and others. ↩
-
OSI sponsor status can be verified on the OSI sponsors page. As of 2024–2026, Platinum sponsors include Google and Microsoft. Board members are primarily from open source foundations; big tech participates through financial sponsorship. ↩