Redis’s U-Turn: Abandoning SSPL and Returning to Open Source

In early 2024, Redis Labs surprised many by moving its popular Redis database from a permissive BSD license to a dual-license scheme: the proprietary Redis Source Available License (RSALv2) and the Server Side Public License (SSPLv1). In effect, this meant that Redis would no longer be fully “open source” by the Open Source Initiative’s definition. After a year of controversy, Redis announced it was reversing course: beginning with Redis 8, the code would be released under the AGPLv3, a true OSI-approved open source license. The creator of Redis, Salvatore “antirez” Sanfilippo, enthusiastically declared “Redis is open source software again” under AGPLv3. This blog post unpacks that licensing saga: why Redis adopted SSPL in the first place, what the community backlash was, and why Redis ultimately switched back to a clear open source license. We also examine the implications for open-source governance and developer values.

What is SSPL and why was it controversial?

The Server Side Public License (SSPL) was introduced by MongoDB Inc. in 2018 as a “source-available” license meant to stop cloud providers from offering MongoDB as a service without contributing code back. SSPL is essentially the GNU Affero GPL (AGPLv3) with one key twist: if you provide the software to others as a service (for example, hosting Redis in the cloud), you must release the entire source code of all the software components required to run that service under SSPL as well. In other words, not only do you open source the database itself, but also your management tools, APIs, monitoring software – essentially “every aspect of the service”.

This provision goes far beyond normal copyleft. By design, SSPL denies cloud providers a “free ride”, but it also takes away traditional rights. Major open-source authorities immediately rejected SSPL. The Open Source Initiative (OSI) publicly stated that SSPL is not an open source license. Debian, Red Hat, and others also refused to recognize SSPL as “free software”. Critics call SSPL a “fauxpen” license: it lets you view the source code, but it violates key Open Source Definition criteria (like allowing all fields of use) by discriminating against service providers. In short, SSPL is effectively AGPL-plus-extra-terms, and it is unequivocally not approved by OSI.

Why did Redis adopt SSPL (in 2024)?

Redis was originally fully open source (BSD 3-Clause). In March 2024, Redis Labs announced that future Redis releases would use dual licensing: either RSALv2 (a source-available permissive license) or SSPLv1. This change was part of folding Redis Stack modules into the core and changing licensing to better fit their business model. The official rationale was twofold: simplify distribution and “protect our ability to continue investing” in Redis while still giving source access. Crucially, the company wanted to prevent large cloud providers from using Redis for free. As Redis CEO Rowan Trollope explained, “the majority of Redis’ commercial sales are channeled through the largest cloud service providers, who commoditize Redis’ investments and its open source community.” Under the new licenses, those providers could no longer offer Redis as a service without either open-sourcing their code or obtaining a paid license.

In practice, this meant that any cloud-hosted Redis offering competing with Redis Cloud/Enterprise would have to abide by SSPL’s strict terms or negotiate with Redis Labs. The policy mirrored moves by MongoDB and others: indeed, within days of Redis’s announcement it was pointed out that MongoDB’s 2018 relicensing under SSPL had already led distros to drop it, and even Elasticsearch (Apache) had switched to SSPL-style terms. Redis leaders argued that SSPL was the “standard wording” to define those limits, and that combining it with the new RSAL permitted continued open contributions while managing commercial uses of the code. In essence, Redis Labs hoped SSPL would deter AWS/GCP from offering Redis for free, while allowing internal use and community contributions to continue under a known license.

Community backlash and alternative forks

The response from developers and distributors was swift and sharp. As one technology news outlet put it, “the horse…may have bolted,” as users immediately sought or created alternatives once Redis adopted SSPL. Many open-source stakeholders rejected SSPL outright. OSI and community members reminded everyone that only OSI-approved licenses count as truly open. Tech media noted that Debian, Fedora, and others would likely remove or refuse the new Redis from their repos. Developers raised practical concerns: some companies reported that their lawyers found SSPL “as clear as mud” and decided to avoid it entirely, opting for a fork instead. In fact, an alternate, fully open-source Redis fork quickly emerged: Valkey. Backed by the Linux Foundation and supported by AWS, Google Cloud, Oracle and others, Valkey retains the old BSD license and integrates new Redis features – it even amassed over 20K GitHub stars within weeks. Other forks/alternatives (KeyDB, Microsoft’s Garnet, DragonflyDB, etc.) also drew attention. One news story likened SSPL to a “poison pill” license because it forces anyone hosting Redis to open-source every dependency, effectively forbidding proprietary service layers.

In short, nearly every cloud provider chose not to “play ball” under SSPL. Many users worried about legal ambiguity and uncertainty. Tech press and forums abounded with acronyms and criticisms, and even Microsoft (whose Azure Cache for Redis has a commercial agreement) admitted RSAL/SSPL left most users chasing alternatives. Summarizing the industry mood, The Register commented “Redis’s dual-licensing approach has upset quite a few open source luminaries,” noting that this was far from Redis’s first license change. In practice, there were no winners: cloud customers still needed caching solutions, and some simply migrated to forks that remained truly open.

The return to open source (Redis 8 and AGPLv3)

Amid this turmoil, Salvatore Sanfilippo (“antirez”), Redis’s original creator, rejoined the company as a developer advocate in late 2024. He openly favored full open-source licensing. In May 2025 he announced on his blog that Redis would add the AGPLv3 license, making new Redis releases genuinely OSI-approved open source again. He candidly noted that “SSPL, in practical terms, failed to be accepted by the community. The OSI wouldn’t accept it, nor would the software community regard the SSPL as an open license.”. In other words, the experiment had backfired: SSPL never gained legitimacy. Redis 8 (GA) was released under AGPLv3, along with the fully open-source data types that had been developed.

The Redis CEO echoed this shift in his official blog, titled “Redis is now available under the AGPLv3 open source license”. He too acknowledged that the community hadn’t accepted SSPL as truly open and that moving to an OSI-approved copyleft license was the pragmatic choice. By releasing Redis under AGPL, Redis Labs still protects against cloud providers (the AGPL also requires that service providers release changes or pay), but it restores the community’s trust. The founder even noted he had written new Redis features (like the Vector Sets data type) with the explicit hope they would be open-sourced, and he was “happy that Redis is open source software again”.

Reactions to the reversal were mixed but generally positive. Many developers and companies welcomed the return to a clear open source model, pointing out that Redis remains a competitive advantage in systems that value transparency. However, some community leaders remained wary, noting that Redis had “burned a lot of bridges” through repeated license changes. OpenUK CEO Amanda Brock lamented Redis’s history of license gymnastics (Commons Clause, SSPL, etc.), calling it a pattern of “undermining open source’s fundamental free flow of value”. In short, trust can be hard to rebuild once eroded.

Lessons for open-source governance and licensing ethics

The Redis story highlights a tension at the heart of modern open-source: How do project stewards balance commercial sustainability with community trust? On one hand, companies like Redis Labs and MongoDB have felt it necessary to shield themselves from being “commoditized” by mega-cloud providers. On the other hand, the essence of open source (as defined by OSI and the community) forbids discriminatory clauses or hidden restrictions. Licensing ethics demand transparency and adherence to community norms. When a project switches to a license that is widely seen as hostile, it can fracture the contributor community and spur forks (as we saw with Redis, HashiCorp’s Terraform/OpenTofu, etc. ).

Developers generally value licenses that are “understood” and carry recognized open-source status. As antirez observed, many in the community mentally refuse to adopt software unless it’s under a license they know and trust (“I would never use it if it wasn’t going to be released under an open source license I understand”). The SSPL experiment made that clear: even if its authors argue it preserves “open code,” the lack of OSI approval led everyone to treat it as non-open. The pivot back to AGPL means Redis once again resides firmly within the open-source ecosystem, using a license that other projects (like Elastic and Grafana) have chosen to protect themselves.

On governance, the episode shows that open source license decisions can be as much political and cultural as legal. Community reactions – not just legal technicalities – ultimately drove Redis’s change. Many in the community felt sidelined by the SSPL move, which reinforced the idea that major open projects need broad consensus to change their licensing philosophy. Finally, this case serves as a reminder that OSI-approved licenses remain the industry standard. True open source is defined (and often enforced) by the community and organizations like OSI. Companies may change licenses for business reasons – and OSI recognizes that in principle – but if they want their software to remain in the open-source commons, they must respect those standards.

In summary: Redis’s brief foray under SSPL taught everyone that the open-source community values clarity and trust above all. The rapid reversion to AGPLv3 (publicly championed by its creator) underlines that, in the end, developer values and communal norms steered Redis back into the open. As Salvatore said, writing new features was driven by “the huge amount of enthusiasm” that came with knowing Redis was open source again. That spirit – and the debates it spurred – offers lessons on how open-source projects can navigate licensing changes while keeping community confidence intact.

Sources: Redis’s own announcements and blog posts, reports from technology press, and official analyses of SSPL and open-source policy provided context and detail for this discussion. Each citation above points to relevant commentary or documentation on these licensing developments.