So we as developers don’t have to scramble to replace redis in our SAAS apps and web based software.

This is more about preventing AWS from eating their lunch by providing redis-as-a-service, without paying any sort of compensation to the redis developers.

Redis’ blog post: https://redis.com/blog/redis-adopts-dual-source-available-li...

I feel like there’s an argument that these kind of licensing terms are almost beneficial to ‘big cloud’ because the cost/effort of all of these arrangements might dissuade smaller companies from trying to compete in the hosting and managed-services business.

Microsoft would never just announce something like this on a whim.

Both the internet and open-source enable alternative employment and funding models that up until now might have not have been sufficiently explored.

Sounds like that's basically what happened here, too, except not with Google. I'm not sure why.

Again, it's chump change, these companies drop that kinda money all the time in aquihires..

It sounds like a very bad deal for the likes of Amazon et al. The likes of Amazon offer Redis alongside memcache just because cloud adopters might want to use a memory cache service,but there is no value in buying trademarks for it.

I mean, just take a quick look how Amazon offers managed RDBMS, and how the specific DB is just an afterthought behind a compatible interface.

People seem to think that just because some company has cash that they should mindlessly spend it on things that add absolutely no value.

Plus some great projects don’t even get (monetary) contributions from large corporations. I think because it could weaken their legal position.

Redis is great as an off-the shelf component, but it's not exactly rocket science to re-implement for a big corporation. So redis doesn't really have any leverage in my opinion.

Then their cloud-specific solutions are the up-sell (and lock-in).

I don't think so. The only thing they need to let their customers know is that they offer a memory cache service that is compatible with this or that interface. Whether it's Redis, memcache, Garnet, or whatever it might be, it matters nothing at all. All they need to do is ensure clients can consume their service, and that is it.

This whole thing sounds like a desperate cash grab that fails to argue any point on why it's in anyone's best interests to spend small fortunes on nothing at all.

Which is why Microsoft's new drop-in replacement works with all those things. It could gain traction - who knows.

I suspect in the long run, Amazon will eventually "pay" the licensing fee for customers that demand "Redis". But they will push everyone else towards their in-house fork of Redis that they brand MemoryDB or whatever. You will pay more for the Redis licensed version and AWS will steer you away from it, but it will be there if you are adamant.

This is already happening with Aurora, which has Postgres and Mysql compatible versions. If your company is big enough for special pricing, then you know they want you on Aurora. The pricing discounts for Aurora are insane (50%+) compared to what you might get on a traditional Postgres of equivalent size (20%). They will probably do this with MemoryDB and Redis eventually. Redis is available if you really need it. But this other thing that they maintain is discountable to half the cost of the other one and it becomes a pretty obvious choice.

It’s a community effort and this is just as rude to the community that built it as they are claiming SaaS vendors are being to them by not “giving back”.

This idea that you are owed reciprocity for publishing free software is about as logically sound as expecting compensation from someone when you give them a gift.

Ironically this happened because the community was using the BSD license instead of the GPL, when the former allows someone to fork the code under a different license.

If the big cloud providers wanted to stick it to them, they would create their own fork of the code under the GPL and make substantial contributions to it so that one becomes the main one.

(I don’t know enough to be in either camp.)

When authors pick a license, it's a serious act. It's not a joke like hey I pick BSD but mind you, I don't really want you to follow the terms! Make sure to don't fork or change license. LOL. A couple of years ago somebody forked Redis and then sold it during some kind of acquisition. The license makes it possible, and nobody complained. Now Redis Inc. changes license, and other parties fork the code to develop it in a different context. Both things are OK with the license, so both things can be done.

A different thing is what one believes to be correct or not for the future of some software. That is, if I was still in charge, would I change license? But that's an impossible game to play, I'm away from the company for four years and I'm not facing the current issues with AWS impossible-to-compete-with scenario. I don't know and I don't care, it does not make sense to do such guesswork. What I know for sure is that licensing is a spectrum. I release code under the MIT or BSD, but that's just me. I understand other choices as well. What I don't understand is making the future of open source in the hands of what OSI says it's correct and wrong. Read the terms of the license, and understand if you are fine with them.

This is a false equivalency. No one is defining "creator" as "wrote all of the thing". When describing a project/product as a whole, there's a clear, massive difference between "creator" and "contributor".

Let's say you get a small patch merged into the Linux kernel, would you then call yourself "one of the creators of Linux"? The vast majority of people would not find this remotely acceptable!

How about proprietary software and employment arrangements. Let's say a Microsoft intern gets a few lines of code merged into SQL Server. Would you call them "one of the creators of SQL Server"?

Extending this logic to other words, would you say a company with N employees actually has N founders? No, because these words mean different things.

But if you think AWS would have any shred of ethics when it comes to a topic like this, you’re much more optimistic than I am.

Basically Redis Inc is the one making the fork, which retains the Redis name since they purchased it from antirez.

But they wont be able to leech Redis's future contributions. Knowing AWS they'll most likely create a fork to continue raking in most of the profits in the short-term.

> Yep still the biggest leachers

Redis was literally licensed for people to do whatever they want. That's not leeching.

So whilst their previous license allowed AWS to leech off them, it's now been relicensed to prevent them from profiting off their future investments without compensating anything back.

We’ll see what happens though. If redis Inc (that never created redis) wins over AWS, GCP and others (who also never created redis). Both contributed to its maintenance, as GitHub clearly shows. We’ll see which fork wins out.

I've called AWS's hiring of a single developer a token hire that they then go on to write flowery PR posts about to camouflage their predatory relationship with OSS vendors.

For concrete numbers they contributed 165/12111 commits for a total of a 1.36% of the commits.

Whilst that qualifies as a valuable contribution to any project, it's also dwarfed by the 350M investment in Redis Labs and doesn't absolve AWS from being a called a "leacher" by helping themselves to the majority of the profits whilst contributing relatively nothing back.

It’s funny that you would use commits to quantify investment from AWS, but you’d use $ to buy shares in future profits to quantify investment from redis labs. Why not use the same yardstick for both?

Either way, it doesn’t matter. Not one bit. Everyone who put in effort into redis did it knowing the license. There’s nothing wrong in relicensing future commits. There’s nothing wrong with forking. There’s nothing wrong in using whichever fork works better for you.

You’re insisting up and down that AWS and others were leeching because they didn’t own the copyright to redis. I’ve never heard this interpretation of OSS before, but sure maybe you’re right. But we’ll see which fork comes out on top a year from now.

Specifically: have the major cloud providers ever created a successful FOSS database, cache, or fulltext search index project from the ground up? By this I mean, a FOSS project with its own protocol, own community from scratch, not a fork or a re-implementation or based on another FOSS project, nor a late-stage company acquisition.

I'm struggling to think of even a single example. Even for broader infrastructure (not just db/cache/search), there's few examples, only Kubernetes comes to mind rapidly.

If the cloud providers are widely practicing "FOSS for thee but not for me" with respect to creation of new infrastructure projects, that's predatory and unsustainable.

Yes, but there’s another explanation. Repeating the same mistake countless times and expecting a different outcome is naivety.

I suppose I’m not understanding the point of your position. Software authors cannot fix a licensing mistake by changing the past, but they can use a different license moving forwards.

Code contributions from amazon would've been leeched by other parties using redis as well - something which amazon is accepting (and probably encouraging).

It's lose/lose!

The "Free for all except mega cloud corps" license changes are to disrupt this status quo which currently sees the mega cloud corps with impenetrable moats from capturing most of the value of OSS products others spend their resources into building, AWS are then able to use their war chest profits to out resource, and out compete them, using their own code-bases against them.

It's unfortunate organizations need to resort to relicensing stop this predatory behavior, but its clear in AWSs 20+ year history they're not going to change their behavior on their own.

Some projects require signing copyright transfer before making commits (legal document claiming that you are a) copyright holder and b) you transfer those rights to them ie CLA [0]) so single entity holds whole copyrights.

They usually have a GHA that checks it when proposing PRs.

It doesn't look like redis has any of this.

So they run RedisLabs purely on trademark + admin rights on GH on redis/redis.

If that's the case then they also cannot legally change licence of code that's already there because they're not sole copyright holders of that code.

ps. as a side note that's why ie. SQLite doesn't allow external contributions at all, even though their code is Public Domain – because they can legally claim full copyright/authorship.

[0] https://en.wikipedia.org/wiki/Contributor_License_Agreement

Public domain isn't the only form of free software. You can literally use it in exactly the same way as you did before. Nothing has been taken away from you.

Does this address your concern?

One of the well known flaws of capitalism, in the 'bad, but everything else is worse' sense.

AWS employee Madelyn Olson was a committer on Redis since 2019. Since 2020, she was on the core team of maintainers.

> If you're looking for a primer on what is going on with Redis and why its license change matters, this is the article to read. As someone close to the situation, this is the best summary I've seen.

(And also I'd argue most of redis' value to users was already in place before the VC backed company got involved)

Where the value is or was is pure sophistry. You don't have a crystal ball, just like everyone else.

All this discussion is envious bellyaching from those that are probably leeches themselves. They just want the free gravy train running for themselves.

From my point of view managed databases only really make sense for toy projects, if you’re using these things at scale it’s much more economical to buy some servers and hire some people of your own, and use plain pre-VC Redis. But big corporations seem to have some kind of a fetish for lighting money on fire, and the fight here is fundamentally over in whose fireplace to do it.

it is more expensive to buy managed, but you offload work. I would imagine toy projects are more cash constrained, and makes more sense to rent cheap servers and roll your own.

On the other hand, larger scale projects would rather pay to offload the work of managing and scaling redis.

Large scale projects can take advantage of economies of scale and hire ops people. I’ve found cloud support pretty lacklustre compared to having someone to talk to face-to-face who understands the whole stack for your particular application.

Of course conventional corporate wisdom says waste as much as you like on services as long as you keep payroll down, that may be a bigger challenge than any of the technical ones.

Redis organization doesn't pay any sort of compensation to developers who contribute to redis source code. I do not see any difference here.

Are we really counting contribution based on LoC? Haven't we over the decades decided that isn't valid? Guess every person that makes this claim should once again have their performance based on LoC...

Some simple examples, I'm not saying this is the case though. What if most of Amazon's contributions are high impact contributions where most of Redis orgs are simply maintenance or feature pushes. What if the same is true for a 1% contributor?

By your own statement doesn't Tencent then have a larger claim to redis that Amazon or Redis does?

I think they didn't include the LoC in the article as anything other than a broad estimate of contributions, perhaps for lack of any better measurements.

But the developers licensed the software at no charge. What kind of compensation are they entitled to then?

Sounds like a case of sellers remorse/take-backsies one of the problems that open source was aiming to solve.

I wonder how many bellyachers here contributed to Redis vs. just leeched. (Not a rhetorical question.) How many are just in the peanut gallery (just like I).

Amazon, Google, MS, and all the rest easily have the talent and resources to create a Redis replacement with code that already exists. They'll do so because it is to their advantage to not charge for the license fees Redis now wants.

> Amazon, Google, MS, and all the rest easily have the talent and resources to create a Redis replacement with code that already exists.

And they most possibly will. Goodbye, and thank you for the fish!

A (very) long time ago the Apache developers could have gone down this route.

> You can only run Apache under very specific circumstances!

Or memcached:

> You are only allowed to run a memcached server if you're only caching your own website!

We see how nonsensical this is

I mean, they've already changed licensing for parts of the project twice in 6 years. I have zero faith that they won't pull a Vader and change the terms of the agreement again.

> continue to be supported and maintained (and improved!)

I'd guess that > 99% of any "improvements" Redis the company make, will affect < 1% of users.

As has been pointed out numerous times, it's essentially "done" in terms of functionality - but as a VC funded company they have to constantly do "something", so they'll keep adding niche upon niche features, giving the resume padders at other VC companies something sparkly and new to spend their budgets on.

Meanwhile 99% of people just need a fast key/value store, and maybe half of those need it to be distributed/replicated, and maybe a third need it to run some kind of scripting (Lua) to do "in-db" operations atomically.

With the addition of native TLS several years ago redis is, for 99% of users "functionally complete".

Sure, new TLS versions will come along and need support, kernel or library features they use will adapt or have improvements, etc, but I think you're vastly over estimating the amount of "improvements" to expect that will impact the vast, vast majority of users.

> preventing AWS from eating their lunch by providing redis-as-a-service, without paying any sort of compensation to the redis developers

Look I hate AWS more than most people would find reasonable, and even I'll admit they're not the "bad guys" in this scenario.

The project was released as BSD licensed, so AWS could if they wanted, fork it, and offer a service based on that, and make any fixes/improvements just in their service offering.

They didn't. They had paid staff contributing back to the redis project, for a number of years. This was literally the goldilocks project of the OSS world:

Numerous massive tech companies who all have the financial ability to simply run their own fork, and the legal right to do so (due to BSD-3), willingly contributing to the maintenance of the project.

As I've said before, the story of what's happened to Redis (and HashiCorp stuff) is likely to become a warning to the tech community in general: if an OSS project you rely on transfers control from it's founder(s) to a company, you probably need to consider continuing with a fork from the last open version, because apparently "(try to) monetise popular open source" is the newest way to win the douchebag villain award given to MBAs at VC funded companies.

Or, even simpler, if the project is not contributed to some open source foundation, and does not have copyleft license - it's a trap.

* Me: @enjoy-binbin Out of curiosity, do you have a fuzzer to test out Kvrocks? Your recent great fixes seem like a combo rather than random findings :D

* Binbin: They were actually random findings.I may be sensitive to this, doing code review and found them (also based on my familiarity with redis)

Gompa also raised the issue on openSUSE's Factory discussion list.

After Docker was phased out, various distributions have adopted the compatible Podman as a replacement for Docker. It seems that a similar story is unfolding with Redis.

And then once Red Hat distros switched over to CGroups v2, which Podman enabled them to do, it meant that Docker wouldn't really work all that well anymore until they eventually switched to CGroups v2 also (which they eventually did a few years later). So that's why it got removed from the repos, at least originally.

A related problem I've seen from other complaints made elsewhere is that podman does things just slightly different enough than Docker that it's not a true drop-in replacement.

We've seen that before; where distro maintainers declared software too dangerous/prematurely dead for a while. All it resulted in was community hosted repositories for the old software. (Read: this is why avconv failed.)

Red Hat at least had the muscle to force podman onto some people, but not everyone.

Those are pretty standard kernel modules for enabling userspace networking, which if you were using podman in rootless mode you need (along with another userspace networking package, slirp4netns). "Drop in replacement" does not mean there's not configuration to get it set up, it means it has the same APIs as another system.

I've been using containers for almost 10 years and with almost no fanfare switched to podman 100% like a year ago. Just because you expected to have to do nothing at all doesn't mean it doesn't work.

Am sure you can get over the kernel module tun creation and other limitations by using something like --privileged but at that point, why not just use docker if you are going to run containers "insecurely".

And for the sake of this argument, drop-in replacement means I can take my tools and move them over to the alternative with little to no extra work needed on my part.

Because at least you can tell that it's insecure, rather than insecurity being the default?

Also the "secure" defaults don't matter much if you have to manually jump through hoops in sysctl and modprobe to get things to work. Infact I could even argue that this introduces the risk of having an insecure server by misconfiguration.

And besides, that issue with root feels overblown in the era of single-user systems and servers as cattle.

I am keenly looking on to see if the people involved in Redict see it the same way. As a user of Redis, I would like to switch to one of these open-source forks, and to be honest one which is "done" and focused on maintenance, bug fixes etc. rather than new features sounds more attractive.

And ftr, in my eyes, a project being created/initiated by ddevault is an asset, certainly not a liability.

He changed the license, moved the code, chosen the name and the direction all on his own without consulting anyone in the community.

His history had made me like that he forked it, but his actions and behavior towards the maintainers of Redis and absolute unwillingness to meet in the middle to collaborate really puts a hold on Redict being more than a fleeting thought.

Linux Foundation, core contributors to Redis and what seems to be the majority of the community is rallying around Valkey, so I don't see Redict going anywhere except in a niche subset of users.

The premise of Redict is to create a fork which is driven by a grassroots community rather than a commercial interest, and which is safe from this kind of rug-pull in the future and to press back against this broader trend of rug pulls by commercial vendors of free software. I invited collaborators from the start at every level, going out of my way not to instill Redict as a hostile takeover but as a community-led effort to create a future for Redis which is protected by copyleft. I talked with the people behind Valkey from the start of Redict and extended them a role in shaping everything from the direction and governance and infrastructure and tooling from day one, provided that we could find common ground on the license. Hell, @madolson, the primary force behind Valkey, signed up for a Codeberg account so that she could be made an admin on the Redict repository before placeholderkv even existed. She was removed only when it became clear that she was committed to her own fork and it didn't seem prudent to us to give admin rights to someone who wasn't contributing.

Redict was not refusing to collaborate or meet in the middle. The raison d'etre of Redict was to be a copyleft home for the Redis codebase, and if we could have found agreement on that then every other detail was always clearly indicated as subject to consensus and we proactively reached out to build that consensus, but were refused by madolson and the commercial interests that wanted to be in charge of their own fork rather than participate in a grassroots project.

Even the consensus they wanted on the license choice was, in the end, the consensus of the four commercial vendors. We tried to find a way of participating in this consensus-making process, but it wasn't made for us. Calls we made in public to use a copyleft license were met with resounding support on GitHub, to no avail.

Don't mistake four commercial vendors and the Linux Foundation for a community. I wish them the best of luck, and acknowledge that a corporate-led home for Redis is probably what some people are looking for. That said, I'm not okay with this narrative that Redict was not cooperating with the community, because it's just factually wrong and hurtful to boot.

The BSD license in particular seems like a particularly bad way to run a business.

But the switch from AGPL to SSPL didn't do either of those things.

AWS still built DocumentDB to compete with Mongodb, and didn't use any SSPL OR AGPL code in the implementation (at least according to their FAQ[1]). And AFAIK AWS isn't paying mongo any royalties.

[1]: https://aws.amazon.com/documentdb/faqs/

Well, yeah, its mostly a bad plan, because while it can block competition with your code, it doesn’t block substitution with other code that provides the same function, and if you aren’t one of the big cloud providers, competing in the same function market with bundled services from the big cloud providers, whether or not it is the same underlying code, is the actual problem you face when your monetization is based around “sell a hosted service”.

but at the same time, they want people to be able to use the software for free (esp. at the start), to kick-start the network effect.

In other words, open-core business models want to have their cake and eat it. If you are able to make lots of money off said software, we want a piece of it after the fact. But we dont want to take on the risk of actually looking to build a business and compete on the same.

There's nothing wrong with making money and being profitable. But they have to justify investments taken with greed. This license change is motivated by greed, not by "making money" fairly.

Would anyone have given mongo a look if it was a fully proprietary technology? They would have gone bust years ago.

Many large orgs just say no to viral licenses, and in choosing AGPL, you put blockers to adoption.

Open core releases some of the project under permissive license, and keeps some private or under a permissions license.

We are all still trying to figure out how we can have sustainable open source where people can be paid to work on it full time

Do you have suggestions for alternative funding/support models? What is open core being replaced by from your perspective?

Personally I prefer the Adam Jacob trademark business model but it's not that proven and it can't be retrofitted.

There is certainly a difference between AGPL and BUSL style licenses. One of the new projects I'm using as some of their code with a BUSL style, but still open core primarily

It's not a technical blocker, it's a psychological blocker

Maybe the problem lies more with overreaching and trying to cash out?

At the same time, founders take money to build their idea into something more than they could do with a small team. An big companies are risk averse, having a small staff or being susceptible to "hit by a bus" failure is often a deal breaker

GPL + CLA = bad. If you contribute to GPL Redis and transfer the copyright to your contributions to the Redis company, they can switch to whatever license they want.

SSPL + no CLA = interesting, I would love to see the Redis company open source their hosting stack because they are accepting external contributions.

Or plan to make money with other people's love and free-time.

Article doesn't mention it, but supposedly Microsoft uses novel algorithms and multi threading to achieve an order of magnitude improvement in throughput.

Now if they can commercialize it with Azure, it should be a credible alternative to Redis Enterprise hosting.

It’s a stack they are looking for but keep missing right under their nose.

I don't know if you were referring to the total install size of apps or to the licence or maybe just how annoying Mono was, but nowadays you can compile down to one binary, optionally with the runtime included. That makes it simpler for Linux sysadmins than Java or even Python, IMO.

It has nothing to do with the technical merits of the technology, but with suspicions of the intentions of the company behind it and a desire not to create a dependency on them.

It's an important disclaimer as someone might read this and go write another tool in Python + Tkinter (with terrible results).

Isn't the point of CLAs that you can re-license contributors' contributions?

Either way you can see contributions to add more commands here: https://github.com/microsoft/garnet/pulls?q=is%3Apr+add+comm...

With that said, I'm slightly skeptical of/worried about Garnet but the reason is different - it received a bit too much hype soon after going public and I'm concerned it will be subject to corporate politics that often plague projects like that.

The company now known as Redis did not invent Redis, it started as a company trying to make money hosting other peoples' work. After it finally hired the creator of Redis, it specifically promised not to do what it has just done (move away from three-clause BSD as the license for Redis core) at least twice.

In the development cycle from 7.0.0 until a few days ago, Redis isn't even the majority contributor to the codebase. The largest single contributor is from Tencent. (All of this is in the article.)

If Redis had been doing all the development, had not promised it wouldn't move away from the license, then I might agree that people have little to complain about.

But this situation isn't as you've suggested here where a community is all about "take, take, take" from a company that's been doing all the work. The company was founded on the idea of trying to do what it now complains about Amazon doing, and their claims that cloud companies do not contribute is clearly false -- just look at the code contributions.

I don’t typically ask people to RTFA because that’s against the rules, but you would have known all of the above if you bothered to read the article.

It’s like complaining that there are too many implementations on GitHub of the same thing.

You're spot on. People are bellyaching that the world doesn't operate according to their arbitrary rules.

Perhaps I'd be happier in a geocentric universe, but it doesn't make a non-geocentric universe bad per se.

At the same time big corps use it as carte blanche to basically pirate software in a legal way, while following the letter of the licence.

Going back to the open core/demo versions (aka Shareware/Public Domain/Trials) is the only sustainable way to make a living.

aka, just sell software, rather than make it open source.

What is being balked at is the idea that you can use open-source as a foot-in-the-door marketing and growth hack, which you then reap after some level of popularity/network effect is reached. Some call it bait and switch.

Blaming big corps for "leeching" is just self-serving. They are doing exactly what the license allows them to do - a license for which was chosen at the start to allow for it! If you expected to be paid to make this software, don't opensource it.

The community has been doing the heavy lifting over the years and Redis Inc has been trying to reap the benefits off of that by providing the software as a service. Which the community was fine with. Turns out other companies with deeper pockets for infrastructure can do the same. Now Redis Inc is trying to save their broken by design business model by changing the license. This casts a whole lot of doubt on the future utility and licensing of the Redis project. And this is what the community balks at.

I'm sure that (FL)OSS core/demo versions is not the ONLY sustainable way to make a living. There is no need for hyperboles.

You don't even need to author software to sustainably make a living. Don't limit yourself.

Eh no. What an overly broad generalization to read. Whether it is enough to make a living is another question, but that does not mean one must paint all of the communities the same color.

You seem to believe that all open source projects are in this category. That is not the case. You also seem to believe that there is always one company doing the most work and everyone else is just leeching off. That is also not the case.

They bought an open source project, and now that the original founder has stepped away they're trying to squeeze it for all they can.

The "big corps" that you claim are using it to "pirate software in a legal way" (a) have been contributing to the formerly open source redis project, and (b) are now specifically forking it to keep maintaining it as open source.

By using BSD license Antirez has freely given it to the whole world, not the name Redis but the code. No matter how big the corporations, the cloud providers are just using that code the way Antirez intended when he used the BSD license. You can't blame the cloud providers for that.

> Supermarket bills cannot be paid with pull requests.

But one can become famous by writing quality open source software and this fame can be used to get very high paying jobs.

Nor with increasingly unnecessary and niche features aimed at "enterprise" customers, it seems.

One could probably even argue that buying the rights to the name of a popular permissively licensed project is a terrible way to pay said bills.

It's "buy the naming rights to an already popular piece of open source software and try to make a quick buck"

I think it is valid to find this immoral. The solution is pretty simple though: do not contribute to open source projects that require you to sign a CLA.

And I think Open Source is based on the very few who decide to take it upon themselves to be the ones spearheading a specific project/task and share it with everyone else. Maybe it's not every single time me, sometimes it's you, sometimes it's Lucy or Mark, and that's how the roll keeps rolling for everyone.

So if a project goes down and nobody comes up to replace it, either it wasn't worth much or this is the time nobody took it upon themselves to do it (yet).

People who use open source are very entitled. They'd be very angry also if the license was changed to GPL or AGPL.

I doubt most of this people have meaningful contributions to FOSS.