121–130 of 815 posts
Earlier quoted context omitted.
Microsoft made one called Garnet, I wouldn't say its a fork though, its basically compatible with Redis and implemented mostly in C#. It supports the RESP wire protocol from Redis for ease of compatibility. https://github.com/microsoft/garnet
You do see how that's even worse, right?
I contributed a minor (but imho still neat :p) improvement to Redis under its original license, and personally moved to using redict when the unexpected license change to SSPL was announced - and I was feeling betrayed as a contributor to a properly-FOSS-codebase. (Had they switched to AGPL right away, I'd have been perfectly fine with that change from a moral perspective, ftr.) I have a great deal of respect for ant…
I think we need to get back to state where we take software licenses serious in letter and in spirit. The transitions Redis made are pristine on a legal and moral level. Feeling betrayed is absolutely uncalled for.
I contributed a minor (but imho still neat :p) improvement to Redis under its original license, and personally moved to using redict when the unexpected license change to SSPL was announced - and I was feeling betrayed as a contributor to a properly-FOSS-codebase. (Had they switched to AGPL right away, I'd have been perfectly fine with that change from a moral perspective, ftr.) I have a great deal of respect for ant…
Microsoft made one called Garnet, I wouldn't say its a fork though, its basically compatible with Redis and implemented mostly in C#. It supports the RESP wire protocol from Redis for ease of compatibility. https://github.com/microsoft/garnet
Here's the play: Open source with AGPL, then offer an enterprise license. You get two wins. The OSS community applauds your adoption of an agressive OSS license. Enterprise customers can't use software under AGPL because it risks infecting their IP, so they're forced to buy an enterprise license.
I think you are thinking of GPL. Many companies are happy to use AGPL licensed software in their stack.
Edit: Oops, typoed the license names.
Earlier quoted context omitted.
Why would PaaS providers switch back to offering Redis? They've clearly all already invested a lot in Valkey (AWS, GCP, Heroku).
AWS and GCP offer valkey-based versions of products that are typically based on Redis, but those versions are currently, generally, preview-grade, and statistically zero customers are using them. They still offer the original, Redis-based versions of those products, which, statistically, 100% of their customers are using.
You've said this twice now, but not provided any data or even a hand-wave to a possible source so that others could go get the data and look at it.
If it's statistically something, where are the stats?
Our company made the switch over to Valkey, and we've invested hundreds of engineering hours into it already. I don't see us switching back at this point especially when it's clear Redis could easily pull the bait-and-switch again.
how does it take hundreds of hours to swap out a back end when you're using a trivial protocol like redis? did you switch out the client or something? maybe the problem is not using pluggable adapters? is your business logic coupled to the particular database client API? oof. I know the cluster clients are different (been there, done that) but hundreds of hours, seriously? or was that just hyperbole?
If valkey is working, why spend that time reverting to redis, when you could be spending it on things that are actually going to provide value?
After what Mullenweg has pulled, in the era of Blogging CEOs I have to be cynical. Valkey.
That's great news. I never liked the newly sprung up licenses. I understand the background but always felt a burden having to read and understand them, and wonder how they'd hold up in practice. GPL licenses have been around for decades and is something people, including legal teams, know more about. And when I say "know", I don't mean "like": it could be that this will just make it easier for a particular team to de…
I did get my stuff working with Pekko (the Apache fork of Akka), and it did work, but I was so pissed off at the entirety of this that I ended up rewriting the entire thing again using Vert.x, which I double checked the license for before doing more work.
I do understand why Akka feels like they have to use something like BUSL, it's hard to make money as a smaller software company, doubly so for open source software, and I also realize me complaining that "this free product made with free labor isn't free enough for me" is pretty entitled, but fundamentally I really don't think that the BUSL (and its similar licenses) are the right way forward. Whether or not it's fair, stuff like Akka does have competition from stuff that has more OSS-friendly stuff, and fundamentally I'm just going to use those, and if they're not up to snuff I'll augment them myself.
I contributed a minor (but imho still neat :p) improvement to Redis under its original license, and personally moved to using redict when the unexpected license change to SSPL was announced - and I was feeling betrayed as a contributor to a properly-FOSS-codebase. (Had they switched to AGPL right away, I'd have been perfectly fine with that change from a moral perspective, ftr.) I have a great deal of respect for ant…
The only real reason to use non-copyleft licenses for these kinds of projects is to be able to do the rug pull, so you should have expected it instead of feeling betrayed. I imagine they will now require copyright assignment or something like that for external contributors to be able to relicense new code under a commercial license.
Amazon gets to make millions off of the thing you built.
"Equitable source" licenses with MAU / ARR limits, hyperscaler resale limits, and AGPL-like "entire stack must be open" clauses is the way to go. It's a "fuck you" to Amazon, Google, and Microsoft in particular and leaves you untouched.
Open source today is hyperscaler serfdom. Very few orgs are running Redis on bare metal, and a equitable source license can be made to always support the bare metal case.