Redis Breaks Up with SSPL: A Custody Battle for Your Data Cache

Welcome to the latest episode of “When Licenses Attack,” where today we’re witnessing Redis—the beloved in-memory database that powers half your infrastructure without you even knowing it—crawling back to the open source community with a freshly signed AGPLv3 license in hand¹.

The SSPL Experiment: A Cautionary Tale in License Engineering

Redis’s fling with the Server Side Public License (SSPL) has officially ended, proving once again that relationships built on “almost open source but not quite” foundations are destined for heartbreak. The SSPL—MongoDB’s infamous attempt to have its open-source cake while eating cloud provider profits too²—turns out to be the software equivalent of that experimental phase everyone regrets in their 20s.

Let’s be honest: the SSPL was never going to work. It’s the licensing equivalent of building a microservice architecture for a Hello World app—technically impressive but absolutely unnecessary for most use cases. Redis discovered what the rest of us already knew: artificially constraining who can do what with your code is a fantastic way to watch your community evaporate faster than free pizza at a developer meetup.

The Automated Deployment Pipeline to AGPLv3

Redis 8 now ships with AGPLv3, which basically means: “Use our code however you want, but if you modify it and offer it as a service, share your changes.”³ It’s like a reasonable prenuptial agreement for software—protecting core values without threatening to take half your infrastructure if things go south.

This is what happens when you actually listen to your community instead of your venture capital overlords. antirez—the creator who has apparently “rarely written anything that isn’t open source”¹—pushed for this return to open principles, which is the database equivalent of your cool uncle convincing your parents to extend your curfew.

Chaos Engineering Your License Strategy

For DevOps teams everywhere, this is actually significant. Your Redis dependency just went from “potential future licensing headache” to “one less thing to explain to legal.” In the ever-evolving hellscape of modern infrastructure dependency management, having one less licensing time bomb in your stack is a win worth celebrating.

The real question is: how many other critical infrastructure components are one board meeting away from a license change that breaks your entire deployment strategy? Your configuration manager doesn’t know. Your CTO doesn’t know. Your documentation certainly doesn’t know.

Your Action Items (Because Every Post Needs Them)

1. Update your dependency documentation to note Redis’s return to AGPLv3
2. Check your Redis version plans—Redis 8 brings the new license along with performance improvements
3. Consider auditing your other “open-ish” source dependencies for similar licensing landmines
4. Take a moment to appreciate that at least one piece of critical infrastructure is moving toward more freedom, not less

In the meantime, I’ll be over here updating my “Licenses Most Likely to Cause 3 AM Production Incidents” threat model, and crossing SSPL off at least one entry in the database category.

Remember: in infrastructure as in relationships, communication and clear boundaries matter. Redis just improved both.