Submitted by Redis, a tremendously popular tool for storing data in-memory rather than in a database, recently switched its licensing from an open source BSD license to both a Source Available License and a Server Side Public License (SSPL).
The software project and company supporting it were fairly clear in why they did this. Redis CEO Rowan Trollope wrote on March 20 that while Redis and volunteers sponsored the bulk of the project’s code development, “the majority of Redis’ commercial sales are channeled through the largest cloud service providers, who commoditize Redis’ investments and its open source community.” Clarifying a bit, “cloud service providers hosting Redis offerings will no longer be permitted to use the source code of Redis free of charge.”
[…]This generated a lot of discussion, blowback, and action. The biggest thing was a fork of the Redis project, Valkey, that is backed by The Linux Foundation and, critically, also Amazon Web Services, Google Cloud, Oracle, Ericsson, and Snap Inc. Valkey is “fully open source,” Linux Foundation execs note, with the kind of BSD-3-Clause license Redis sported until recently. You might note the exception of Microsoft from that list of fork fans.
↫ Kevin Purdy at Ars Technica
Moves like this never go down well.
I have a lot of sympathy for redis.
Open source Is all about sharing. But when cloud providers are the one taking 99% of the profit and giving back 0.1% I can understand them wanting a bigger slice of the pie.
They might lose 80% of that market to the new fork, but at that point..what difference does it make to them. If they keep one or two big corps that won’t move off the brand name they’ll massively increase their revenue.
Assuming they don’t diverge to far, they’ll also be able to merge back in any open source work while adding features of their own.
I guess that it’s not even 0,1%.
Server Side Public License? Probably has to be one of the worse licenses there. No wonder everyone wants to find an alternative.
Most of the SSPL is the AGPL. The SSPL has an expanded the scope rather then focusing on the system the person is interacting with, which is a fuzzy definition anyway.
Which parts of the SSPL are bad?
https://www.mongodb.com/legal/licensing/server-side-public-license
Out of section 13 is the following between the dashes
—-“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available—-
This asks for your complete stack. So you cannot run Redis with this license on MS Windows or some form of Mainframe as hosting because you cannot provide the source code of that. Asking for the complete stack is very much over reach. This over reach has caused a predictable response. Y
What if you use visual studio you know the closed source one to modify the source code. That “all programs” bit has way too much reach yes that is doubles down that it not restricted with ” including, without limitation”
The AGPL so called fuzzy define did equal that AGPL would not be the user between basically rock and hard place. AGPL was fairly much never asking for something you could not provide.
SSPL has the problem of major overreach never pays to make a license with no restriction on what items it effects as SSPL is. If you do your end up forcing your customers either to fork your project to keep on using the same solution or stop using your project/program working out a completely different solution. Yes we have seen over reach with closed source applications licenses that have resulted in complete programs disappearing out of different industries that were dominate program because the over reach license and all the replacements were really horrible to use.
I’m pretty happy about this. The monetization shoe dropped, and the forks are out. The forks aren’t attached to a company, and as such, they can add features which Redis held back. No more open core corporateware!
I was rather hesitant to use Redis due to something like this happening, and now the forks are clear of the company.
Redis is nice and holding different data structures is fairly novel, but it’s ultimately a single threaded KV store. There are many of those, and Redis itself is not that advanced. It’s a great little project, but not something to build a business around.
Redis Fork List:
– KeyDB https://github.com/Snapchat/KeyDB
– Valkey https://github.com/valkey-io/valkey
– Redict https://codeberg.org/redict/redict#forking-in-progress