The Prodigal Cache Returns: Redis Embraces Open Source Again with AGPLv3 Well, well, well. Look who decided to rejoin the open-source party. After a year-long detour into the somewhat murky waters of source-available licensing, Redis is making waves again. This time, it's by embracing a bona fide open-source license for its latest major release, Redis 8. The chosen license? The GNU Affero General Public License version 3 (AGPLv3). For those following the Redis saga, this is quite the plot twist. Let's rewind a bit. A Year in Licensing Limbo Just over a year ago, Redis Ltd. (formerly Redis Labs) sent ripples through the tech community by ditching its permissive BSD 3-clause license. This license essentially allowed anyone, including massive cloud providers, to use, modify, and commercialize Redis freely, often without contributing much back to the core project. Feeling the pinch from cloud giants offering Redis-as-a-service and reaping the rewards, Redis shifted gears dramatically. Starting with version 7.4, Redis adopted a dual-licensing strategy: the Redis Source Available License v2 (RSALv2) and the Server Side Public License v1 (SSPLv1). Neither of these is recognized as truly "open source" by the Open Source Initiative (OSI). The goal was clear: compel cloud providers offering Redis services to either obtain a commercial license or open-source their entire service stack built around Redis (under SSPLv1's terms). Microsoft blinked and licensed Redis. Others, notably AWS, Google, and Oracle, didn't. Instead, they threw their weight behind a fork called Valkey, governed by the Linux Foundation. This fork, based on the last BSD-licensed version of Redis, quickly gained traction, becoming a rallying point for those uncomfortable with Redis's licensing shift. Redis CEO Rowan Trollope admitted the move was only "medium successful." He even anticipated the forks, acknowledging that over time, Redis and projects like Valkey would diverge significantly. That divergence point, he noted, really begins now with the launch of Redis 8. Enter AGPLv3: A Return to Open Source Roots? So, why the change of heart? It seems to be a confluence of factors. Community Pressure & The Valkey Effect: The rise of a well-backed fork like Valkey undoubtedly put pressure on Redis. Losing community goodwill and potentially significant user segments to a fork isn't a sustainable long-term strategy. Internal Deliberations: Apparently, the debate wasn't just external. According to Redis insiders, discussions about using AGPLv3 instead of SSPLv1 were happening before the initial switch away from BSD. It seems the AGPL camp within Redis finally won out. Seeking Clarity and Trust: The RSALv2/SSPLv1 combo created confusion and legal ambiguity for many users and companies. Returning to an OSI-approved license like AGPLv3 restores clarity and signals a renewed commitment to open-source principles, albeit with stronger copyleft provisions than BSD. Redis has even rebranded its free offering from "Community Edition" to "Redis Open Source." Understanding AGPLv3: Not Quite BSD It's crucial to understand what AGPLv3 entails. It is an OSI-approved open-source license. However, it's a strong copyleft license. Key aspects include: Network Provision: If you modify the AGPLv3-licensed software and make it available to users over a network (like a SaaS offering), you must make the source code of your modified version available to those users under the same AGPLv3 terms. Derivative Works: Any derivative works based on AGPLv3 code must also be licensed under AGPLv3. This is significantly different from the permissive BSD license Redis used previously. While it allows free use and modification, the network provision directly addresses the core issue Redis had with cloud providers: it prevents them from taking the AGPLv3 version of Redis 8, modifying it, offering it as a service, and keeping those modifications proprietary. They either open-source their service layer built on Redis or negotiate a commercial license with Redis Ltd. This approach is similar to that taken by other companies like Grafana Labs and Elastic. It's Complicated: The Tri-License Reality Here's a nuance often missed in the headlines: Redis isn't replacing RSALv2 and SSPLv1 with AGPLv3 for Redis 8. Instead, it's adding AGPLv3 as a third option. Redis 8 and future versions are now tri-licensed under RSALv2, SSPLv1, and AGPLv3. Users can choose the license that best suits their needs, with AGPLv3 being the clear open-source path. Older versions remain under their respective licenses: Redis <= 7.2.x: BSD 3-clause Redis 7.4.x - 7.8.x: Dual RSALv2/SSPLv1 This tri-license approach gives Redis flexibility, allowing them to cater to different user segments while maintaining their commercial interests and adhering to OSI-approved open-source standards via AGPLv3. Importantly, core Redis modules like RediSearch, RedisJSON, RedisTimeSeries, and RedisBloom are also moving to this tri-license model with the release of Redis 8. What Does This Mean for You? For most developers and end-users building applications with Redis, this is good news. You can confidently use Redis 8 under the OSI-approved AGPLv3 license without the legal gray areas of the previous source-available licenses. For companies offering Redis-as-a-service, the calculation remains similar to the SSPLv1 scenario if they choose the AGPLv3 path: modify Redis 8 and offer it? You'll likely need to release your modifications or seek a commercial agreement. This move, coinciding with the return of Redis creator Salvatore Sanfilippo to the project, feels like an attempt to mend fences with the open-source community while still protecting Redis Ltd.'s commercial interests. Redis 8 itself brings significant improvements, including native vector search capabilities crucial for AI workloads, now accessible under a true open-source license. Will this strategic shift back to open source be enough to halt the momentum of Valkey and fully regain the community's trust? Only time will tell. But for now, Redis is undeniably "open source again," albeit with stronger strings attached than before. It's a pragmatic compromise, and arguably, a necessary step in Redis's ongoing evolution.
