Imported Rant – Why Redis and MongoDB licenses are open source
This post was originally written in response to The Linux Experiment’s “Redis ditches FOSS” item, where Nick, the presenter, was critical of the recent Redis license change where they moved from the original BSD license to MongoDB’s SSPL, a change that was portrayed (and I’m paraphrasing a bit) as “the company taking the code the open source volunteers have given them and closing it in order to monetize the volunteers’ work”.
TL;DR – the fact that OSI labels SSPL as “not open source” is nothing more than FUD by the major cloud providers, as the only meaningful difference between that and the GPL is section 13 that makes life harder for cloud providers.
Nick analysis is incorrect: the MongoDB Service Side Public License that Redis has chosen does not prevent people from copying the Redis source code, making changes (“forking”) and distributing the resulting work to other people.
The difference between the SSPL and the original BSD are mostly the same as the difference between GPL and BSD, including:
- The requirement to deliver source code to third parties, in case you re-distribute the source code (section 6).
- The no sub-licensing requirement – i.e. you can’t license your part of software under a license different than the one you received (sections 4 & 5).
- The virality – i.e. “linking” causes the entire work to be considered derived, except SSPL throws out the term “linking” as too technical and replaces it with “(works that) by their nature extensions of the covered work, […] (or) combined with it such as to form a larger program” – which is a better way to understand the “linking” part in a way that doesn’t require the reader to understand C compilers (section 5).
So for all that, if you’re OK with the GPL, you should be OK with the SSPL (some people do not consider the GPL as a “free” license, because it does not allow you to restrict the freedom of others, like BSD does, but that’s on them).
The SSPL only makes one more addition – which is the thing that drew the ire of the OSI and makes the SSPL so-called “not open source”, and is the one thing that is supposed to force AWS to get a commercial license1: if you offer the software “as a service” – i.e. make the software itself available for a fee, not creating a new product that uses the service internally, but just exposes the entire service itself as is, then you need to either get another license (and pay for it) or open source your entire support infrastructure, from UI to system operations (section 13).
I personally do not like that approach, but I like even less the concept of AWS (and others) taking the support & consult business model that open source companies have thrived on for years, and trashing it.
Redis is a commercial company that have made available their main product for free to the community under the support & consult business model – like MySQL and many others before them. They do take code contributions from outside developers but the majority of Redis code was created in Redis Las and they don’t deserve to be painted as people who “make use of open source volunteers and then do a 180 and try to monetize the h*** out of this and ditch open source”.
The new Valkey fork that AWS support, is the “free software that lets us sell it as a commercial product” trick that IBM pulled with Apache, Oracle with Open Office and others. The big players will only use open source that is either a commodity owned by another big company (see MySQL) or that they can cannibalize the business model of smaller players, and as soon as the smaller player decides to stand up to them – its forking time! The fact that the Linux Foundation is playing ball is shameful but not surprising – the Linux Foundation exists to commercialize open source and make it available to large enterprises for free and they don’t care much about enterprises abusing open source licenses nor do they care about open source business models other than their own – i.e. an industry association with industry backers.
- which they won’t and therefor the idea is to prevent them from actually using Redis [↩]
Put $$$BIGCLOUD aside for a moment and think about smaller enterprises like KeyDB. Instead of trying to figure out where the line is drawn and causing their Legal team major headaches, they created another fork (of plain Redis) that keeps the old rules of the game. It’s very similar to the situation the Opentofu folks have found themselves in, and there wasn’t even a $$$BIGCLOUD player involved there.
PS: I am still waiting for someone to show the world how to comply with those license terms when offering the software as a service. Companies that switch their OSS to SSPL are such hypocrites.
IIUC KeyDB is a fork of Redis 6 – way before the license change, and at least according to their own claim about the reason for the fork, it is about different ideas about performance and features that wouldn’t (didn’t? I don’t know that they even talked with Redia Labs about their ideas) work with Redis Labs roadmap. They also don’t offer a SaaS version so I don’t think their case factors into this issue at all.
If the worry is that “oh, the license has changed! Oh no, now I need to read the new license and think whether it changes my business model! This is too much work! I rather fork and maintain a big performance complex software product myself”, then… Seriously? I mean, I know lawyers are lazy(*) but this is ridiculous.
*) I worked with Intel legal department on a few things, and oh boy – I can tell you stories.