(EDIT: Genuine question - I'm trying to understand if this is a license purity issue or something else).
LWN has a good overview:
https://lwn.net/SubscriberLink/966631/8bc9d155d4e2afb3/
Redis Ltd is only responsible for about 20% of the work.
It makes perfect sense for AWS and Google to fork immediately after the switch, but for contributions before the switch, there is no basis for AWS and Google to complain Redis Ltd, either legally or morally.
Employees on their own time, or paid to do it?
So I'm clear though - if I wrote a SAAS product tomorrow that under the covers used Redis, I'm OK, but if I spun up a bunch of servers and offered managed Redis as a product, I would need to pay?
...which, given LGPL, will be worse now as they'll simply not share their modifications because that's the legally safest option.
I don't know much about the genesis of Redis or Redis Labs, who key people and dates are, etc. I guess this obfuscation is part of the problem.
Are there any instances where an SSPL license or similar is warranted?
Open source does not make a difference who uses it.
No, people are not upset Redis is trying to make money. People are upset that something that used to be FOSS is no longer FOSS, and are trying to protect themselves from future pain by doing something that is very common in FOSS, which is forking a project.
Just because someone is trying to make sure the software they rely on continues to be FOSS, doesn't mean that they are out to actively hurt the original creator(s) of the original project. I don't know how you could possibly read the situation like that either.
Redis Labs also did not in any way make Redis. They came in later to exploit the already open source project for their own benefit.
Then, another company that is offering a hosted Redis and support hires antirez and so becomes the 'offical' Redis company.
In 2020 antirez leaves and goes and writes a novel (called "Wohpe") instead.
https://en.wikipedia.org/wiki/Redis_(company)#History
Antirez hasn't been involved in Redis in a long time.
This is a common enough pattern when open-source projects leave their roots and then, eventually, alienate theiropen source base. Perhaps the time is ripe for Antirez to come back and shepherd one of the forks, a bit like mariadb?
What these companies want is licenses which prevent AWS and other cloud providers from competing with them on their specific technology, regardless of how much those same companies are contributing to the technology. Redis is the most extreme example here - by all accounts I've read, Amazon was a major contributor, not just throwing bug fixes here or there. But that doesn't help Redis Labs, they want money, not code. And the AGPL would have done less than nothing to help stop Amazon from running their own Redis service: Amazon was already doing everything (or at least most things) that the AGPL would have required of them.
SSPL is just a figleaf. No one sane redistributes third party SSPL code without having a contract with the company, it's essentially proprietary in all but name. But it allows the company to maintain this air of open source legitimacy.
And if it grew organically, well OpenSearch is not exactly thriving. One of my clients are using it and it's a massive PITA to be on it.
No idea how badly it affected enterprise revenue for ElasticSearch though, but ES is going to win that fight in the long term.
For the vast majority of open source projects, being used by (and, importantly, receiving contributions from!) the "big boys" is a Good Thing and something to be aspired to.
GitHub is proprietary and not ideal, but when trying to get developers on board after a fork, using GitHub and using the same license as the original avoids spending innovation tokens / weirdness budget unnecessarily.
Changing the license was an absolutely essential requirement, and this is a crucial time to evaluate and commit to that change. As far as we're concerned, not being copyleft was a bug that was exploited by Redis Ltd, and a fork which doesn't fix that bug isn't addressing the underlying problem.
I find it amusing that you called it "weirdness budget", but then again that pretty accurately describes the feeling I get when I see someone using a fairly niche DB instead of something like PostgreSQL, or something like NixOS instead of a regular Ubuntu LTS or RHEL-like. Not that it's a bad thing, there's plenty of specific use cases out there for sure.
I honestly do not see this as being different than Redis. Do BSD or MIT and be done with it.
It seems needlessly ideological. Everyone wants to call their stuff open source but have strings attached.
The term 'Open Source' is well-defined and includes licenses like the one redict picked (LGPL 3.0). It is incorrect to try and lump this in with source-available licenses that are IMO anathema to Open Source.
It’s simply a fact that MIT for instance allows things like Redict and this discussion to take place, as well as other things. It is maximally permissive.
Anyway, the Redict team are doing their thing and letting Redis and Valkey be. You’re the one insisting on Redict doing things the way you would like, so who exactly is being ideological?
Edit: Linux was always GPL, Redis was not, so I don’t see the relevance.
That's what a permissive license would allow, which is a subset of Open Source.
> I honestly do not see this as being different than Redis.
Redis doesn't give you the 4 freedoms; in point, "The freedom to run the program for any purpose".
> Everyone wants to call their stuff open source but have strings attached.
This literally is open source.
https://www.linuxfoundation.org/press/linux-foundation-launc...
And very next section:
"If you compile Redict’s source code into an executable form and distribute this executable form to others you are required to include a copy of the Redict source code and any modifications to it licensed under the LGPL."
Let's be real: Especially in the EU, the definition of distribution of derivative works is typically so strong that it's super risky to use any copyleft license and I personally (e.g. consulting for large companies) see huge issues with compliance whenever this happens.
In other words, it doesn't even matter what the current intention of using this license is regarding commercial use (but not distribution?)... I would not recommend to use this commercially for multiple reasons including risk, career but also the fights to be had with legal compliance.
We desperately need all open questions regarding AGPL and SSPL to be clarified in court so this fearmongering can stop. It's really really bad for open source.
Or get hosted redis services from someone other than Redis Labs. That isn't fearmongering about the SSPL, it is literally the point of the SSPL.
> In technical terms, we are focusing on stability and long-term maintenance, and on achieving excellence within our current scope. We believe that Redict is near feature-complete and that it is more valuable to our users if we take a conservative stance to innovation and focus on long-term reliability instead. This is in part a choice we’ve made to distinguish ourselves from Valkey, whose commercial interests are able to invest more resources into developing more radical innovations, but also an acknowledgement of a cultural difference between our projects, in that the folks behind Redict place greater emphasis on software with a finite scope and ambitions towards long-term stability rather than focusing on long-term growth in scope and complexity.
It'll be interesting to see what Valkey's future is with the maintainers having some lofty goals, and expressing frustration that they weren't able to move fast enough or be innovative enough under Redis. As a small-time user of Redis I kind of like the idea that I could just have what I've got now, but with a promise that someone's looking after it. I don't feel the need for millions of transactions per second, a timeseries database, etc.
I think there is a few things I would like to see in the mid to short term. We're trying to make a lot of the core datastructures more efficient (both in terms of memory and performance) as well as the main dictionary. Valkey 8.0 (or whatever first major version we have) will have lower overhead per key-value pair. Multithreading performance is nice, but as you mentioned most people don't need it. It gives folks a lot of runway if they need to scale but don't want to use clustering, and can also be a "quick fix" for certain types of P99 or higher latency spikes. Clustering is also really hard to use today, and a lot of the current folks want to fix that. It's a huge community pain point. Observability is another pain point I would like to improve. (Disclosure, I work at AWS as well) We see a lot of customers ask about "why did we see a performance issue", and Redis really doesn't provide a lot of introspection to diagnose those issues.
Another big area, which maybe will work for redict, is we want better integration with other OSS projects, especially CNCF projects like envoy, open-telemetry, K8s. There are a lot of self-developed projects floating around, we're hoping we can pull all of this together to make a more cohesive project for people to use instead of what we see today.
I think another big issue will be clients. I'm concerned Redis will try to inject a poison pill into the clients they own to make it so they can only talk to "official" Redis versions. Ultimately a small community will struggle to maintain a lot of clients, so I think we need a larger (and likely commercial) investment into keeping clients open. We will likely passively support redict with our clients, so they'll get that for free.
We want to do all the cool feature stuff to (timeseries, JSON, bloom, RAG), but I would like to keep the core pretty clean.
One feature that would be very helpful would be some form of analytics and a memory profiler. At one point I'd written a python library to iterate over a RDB to identify what the top keys consuming most memory were, but Redis has added a lot of complexity and new data types since, so I doubt it still works.
>Ultimately a small community will struggle to maintain a lot of clients, so I think we need a larger (and likely commercial) investment into keeping clients open
I'm not sure that this is true, at least not the commercial part. Redis clients are pretty simple (compared to Redis itself, at least). Redict is leading an effort to encourage community forks of the official Redis clients, as well as sending patches downstream to third-party clients. We set as an explicit goal to fork the ecosystem as well; we've started this work with hiredict and don't intend to stop.
I think there was some mention at some point about our two forks working together on maintenance of the protocol specification independently of Redis Ltd, which would be a good way to ensure that the clients remain broadly compatible with both of our forks.
I think Redis Ltd. is vastly overestimating the value of their product. Redis is incredibly popular, but the vast majority of users are just looking for a simple in-memory key-value store for lightweight database use cases, caching, etc. I've used it in some way in just about all my projects for the past ~15 years.
The thing is, I don't care that it's Redis. I don't care about most of its features. I could have subbed in memcached or any number of other solutions. It would have been trivial and had no impact on my system.
I have no doubt that there are some power users who need advanced features of Redis, but I also have no doubt that Redict will be better, and that there will be companies who provide commercial support for it.
I'm just going to use Amazon ElastiCache for big projects, and continue not caring at all about what it is behind the scenes. And I'll s/redis/redict in my docker-compose.yml for small/personal projects, and that'll be the end of it.
I can't imagine a scenario where Redis Ltd. is relevant or profitable 10 years from now. Oracle can afford to lose money on MySQL forever, and treat it as a loss-leader for acquiring new Oracle DB customers or at least new MySQL service contracts. Redis Ltd. has one product and few people need support for it or care much about it vs. alternatives.
Edit: Or Valkey instead of Redict; either way, which exemplifies the degree to which I don't care.
>And I'll s/redis/redict in my docker-compose.yml for small/personal projects, and that'll be the end of it
FYI we're publishing to registry.redict.io, so s:redis:registry.redict.io/redict:g
https://redict.io/docs/redis-compat/containers/
Not that it detracts from your point in any way :)
And double thanks for providing an SPDX document for the contents of the image.
MySQL is still widely used, including by a large portion of publicly-traded tech companies. That said, most newer startups seem to be choosing Postgres instead.
MariaDB is also somewhat widely used, but not nearly as much as MySQL. And MariaDB's commercial enterprise (which was VC-backed and went public via a SPAC) is not doing well.
I believe this is factually false. Consider just one datapoint:
Not randos on HN
These options (Redict, Valkey) don't seem to support JSON as a data type, so I'd like to know if there is some server specifically made for dealing with JSON documents. Something like a very lightweight MongoDB server which can be managed via a browser and where the data can be inserted/updated/removed via HTTP calls.
For such a small need, you might also look at PouchDB. Inspired by couch but simplified to allow it to run in-browser.
What is the stance on incorporating Rust into the codebase?
I don't think anyone is going to be very excited about introducing Rust unless there's a compelling reason to, but feel free to bring it up on the issue tracker for discussion and see if you can form a consensus on the matter with the rest of the community.
I wish you the best of luck and when I am able to be involved with OSS again, I will gladly help out with Redict. I think the LGPL is a good choice.
Areas where I would personally want to see Rust in a project like this, a) parsing and talking with the network b) extension mechanism moved to Wasm (Wasmtime for execution) but that plugins would be moved into a Wasm container.
It would also be a nice property if the core of the project maintained a compile to Wasm compatibility so that Redict could be run everywhere.
Being non-open source Redis can merge any contributions made to Valkey but not from Redict. So if you don't want your code to end up in Redis, contribute to Redict.
Interestingly, there have only been two commits from a single developer to the Redis repo in the last two weeks since the license change. A huge decrease.
> Interestingly, there have only been two commits from a single developer to the Redis repo in the last two weeks since the license change. A huge decrease.
It's just a guy from Redis. It's not even one of the three former maintainers (Oran, Yossi, or Itamar). The number of open PRs is also dramatically down (it was around 550 when I last looked before the fork, since I've gotten a lot of notifications from old PRs of people refusing the CLA).
Not only are you not subject to the conflict of interest between users and sellers in a commercial product, you aren't even subject to the popularity contest tyranny of the majority in a non-commercial product.
If someone takes the last open version of something and forks it and never does anything further to it and no one else ever uses it, but it does what they want, they win.
They win at life no matter what anyone thinks about that fork.
