It wasn’t clear to me until I read their blog, that redis will remain free to use in their “community edition”, which will continue to be supported and maintained (and improved!)
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.
Well, except for the fact that "redis" the organization didn't create redis and isn't even the main developer of redis. The origin of Redis the company is literally as a hosting provider for the open source redis that they didn't create.
Amazon / Google / Microsoft made a massive mistake by not hiring Antirez, it's chump change for them to throw him $1-2M a year at him so he can work on Redis for them full time.
This makes me think - is it actually bad for Amazon/Google/Microsoft, that they now have to pay a licensing fee to Redis?
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.
Yes, this seems likely since there is almost no way that an announcement from Microsoft would happen so quickly. There were months of back and forth of licensing meetings prior to this with Redis Labs and Microsoft.
Microsoft would never just announce something like this on a whim.
they don't have to pay. they offer a Redis-compatible service. whatever it is, nobody knows, and almost nobody cares. (sure, in practice they just forked it. but it was not AGPL-like when the fork happened, so ... c'est la vie)
This. Why not support the projects a company uses in ways that go beyond the traditional ways of hiring employees in the form of physical bodies that defy traffic jams to spend large parts of their day in a physical building? There are some larger companies that employ open-source or third-party developers of course, but it seems to me that if your product is built around a technology or framework, it would make sense to invest directly in that project – share a developer resource as it were – instead of hiring an extra person in-company and make sure your use case and reliance is covered in the future.
Both the internet and open-source enable alternative employment and funding models that up until now might have not have been sufficiently explored.
This is actually pretty common. My company did exactly that with an Apache project founder. I know of several others. They still work on their own project, but have to shift priorities.
Sounds like that's basically what happened here, too, except not with Google. I'm not sure why.
> He sold the trademark to some random company. Amazon / Google / Microsoft could have thrown him $30M for that and put Redis in an OSS Foundation.
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.
I mean I love redis, but Amazon Google and Microsoft all probably have readily available in memory key/value stores at hand. Throw a little money and they can make it redis compatible, so we wouldn't have to re-write any code.
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.
It's all about branding and name recognition: they all profit from Redis via their cloud offerings. They have a strong incentive to support it and to have it as a viable open source project. Similar to other key opensource infrastructure.
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.
AWS has been pushing MemoryDB, which is redis compatible storage, works with the redis clis and supports Redis features.
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.
VMware (Pivotal, if I remember correctly, which was part of VMware) hired him for a while, about a decade ago. They did a huge mistake as well, because they didn't take advantage of him at all.
*one of the creators. Being the first committer doesn’t mean he wrote all of the thing that is today called Redis.
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.
> 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 think everybody here understand that you legally can fork bsd code under a new license. I think you and them differ in what you think is morally correct to do for an open source maintainer in the specific context of the redis project.
When I chose BSD for Redis, I did it exactly for these reasons. Before Redis, I mostly used the GPL license. Then my beliefs about licensing changed, so I picked the BSD, since it's an "open field" license, everything can happen. One of the things I absolutely wanted, when I started Redis, was: to avoid that I needed some piece of paper from every contributor to give me the copyright and, at the same time, the ability, if needed, to take my fork for my products, create a commercial Redis PRO, or alike. At the same time the BSD allows for many branches to compete, with different licensing and development ideas.
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.
I totally agree. Still I hope that many great projects under BSD and MIT will keep being actively developed under that very license, but I also enjoy the freedom of knowing that I can do more or less what I please with the code.
> *one of the creators. Being the first committer doesn’t mean he wrote all of the thing that is today called Redis.
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.
It doesnt matter if they would've or not. Presumed innocent until proven guilty (via action). Using this as an argument doesn't work to justify redis inc's actions.
I think your use of innocence is referring to your perceived ethical and moral compass, so while you have a theoretical point about guilty and innocent, your argument isn’t based on legality of actions which ultimately is all that matters.
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.
Yep still the biggest leachers. Token hires and flowery PR campaigns doesn't entitle them to most of the profits of other vendors products or absolve them of their predatory behavior.
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.
Redis Labs was a long time sponsor for the full-time development of Redis then later compensated the creator of Redis for their rights to Redis Technology and branding who was ended up retiring from technology to write Sci-Fi books. By contrast AWS takes most of the profits whilst contributing relatively nothing back, making them the biggest leacher and the primary motivation for the relicensing to prevent mega corps with unfettered access to their future contributions that AWS repackages to compete against them.
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.
During an all-hands around 2008 I asked AWS leadership whether AWS was going to open source their technologies the answer was we're thinking about it. 16 years later it has not happened, nor it will given the record ;(
You buy the trademark/name from the original author. I'm the case of GPL or other assigned work licenses, you sell the baseline copyright and they can change it.
AWS, along with Google and others have created a fork already. It’s very rude of you to call someone a token hire when they’re high up in the contributors list (#7 all time). Denigrating their work for no reason other than to “win” an internet argument.
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.
> It’s very rude of you to call someone a token hire when they’re high up in the contributors list (#7 all time).
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.
That's fair in isolation, but one can justifiably argue that a repeated pattern of behavior is clearly predatory.
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.
Have any major software company ever created a successful software from the ground up ? No, they all base their work on some language ! They are predatory !
Wait, does any language team ever created a successful implementation from the ground up ? No, they all base their work on some hardware people ! They are predatory !
Wait, does any hardware manufacturers ever created a successful product from the ground up ? No, they all base their work of some software ! They are predatory !
Not even remotely the same situation at all. It's not about using some other existing language/hardware/software and building something on top of it.
Rather, it's a question of cloud vendors repeatedly building open source competing drop-in re-implementations of external db/cache/search products when those original products switch away from FOSS licenses to survive, despite the cloud vendor being a million times larger and better resourced than the original db/cache/search developers. The cloud vendors aren't building something on top of these products (like your examples), but rather they are aiming to competitively replace these products and capture the mindshare of their communities.
This strategy allows the cloud vendor to skip the hard steps of developing a unique product from scratch, designing a client/server protocol from scratch, building a community from scratch, and so many other things.
Separately, the cloud vendors do also build their own unique db/cache/search products, but they just don't ever make them source-available or self-hostable when they do so -- let alone FOSS. That is what makes the pattern of behavior predatory: the big cloud vendors use their dominant positions to bring non-FOSS products to the market, while using FOSS re-implementations to destroy competitors who dare move away from FOSS themselves.
None of the 3 examples you described above are in any way related to this scenario.
To repeat a comment by another user upthread: hence the relicensing.
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.
Yes, they paid. And they can use the code they paid for. But it doesn't give them right to leech of any future code written by someone else IN THE FUTURE.
Calling it leech isn't right, because what makes aws any different from another user? Just because they're selling the hosting, doesnt make it any different to a regular user.
Code contributions from amazon would've been leeched by other parties using redis as well - something which amazon is accepting (and probably encouraging).
And considering Redis Inc hasn't contributed the majority of the code, they won't be able to leech off other people's code because why on earth would anyone contribute to this trainwreck!
AWS are the largest leeches of OSS, syphoning off most the profits and contribute relatively nothing back towards the OSS projects they rent seek from.
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.
It is not owned by the company. You are free to create your own fork of the code with all the attendant benefits, including monetization, if applicable.
Who owns the copyrights? According to the article, since 7.0.0, 24.8% of commits are from Tencent, 19.5% from Redis, 6.7% from Alibaba, 5.2% from Huawei, 5.2% from Amazon.
I wonder if there is a qualitative analysis of the commits. Aka, it changed a line of comment vs it introduced a new feature or refactored and increased long term viability, etc.
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.
If you own the copyrights you had money to spend at some point. Other than that unless you are one of the contributors you are leeching, just different flavors of leeching.
How does buying a copyright to a name, literally just being able to call it "Redis" equate to purchasing the code contributions that individual contributors make? They bought the rights to the name, not the project, the project was open-source until the license change and belongs to society as a whole.
Your confusing copyrights with trademarks. The project belongs to the authors (perhaps in shares depending on the jurisdiction where it is being copied/derived) not the society. The options that were licensed under BSD generally remain licensed under BSD unless someone revoked that license. It does not seem that the latter has happened.
I agree, I didn't make any argument against that, I just don't see the difference between <party with money that bought a name and sells the free work of others> and <party with money that didn't buy a name and sells the free work of others>. My only argument here is that there's not much difference between AWS and Garantia Data from my limited understanding of the situation.
It was bsd licensed. The code that you received before is still covered by the bsd license. You can pretty much do anything you want with that code except misrepresent yourself as the author.
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.
We don't know what they got. Perhaps some of them were paid to create the contributions. And, in any case, that's OK. The contributors knew or should have known the impact of the license. They could've picked a more restrictive/free license, depending on your point of view. I guess they can still revoke the license. They have not given up their copyrights and the license is arguably not irrevocable.
Often, as that's what rentiers are. Generally bad for society. And have captured many regulatory processes and got tons of tax breaks for producing nothing.
One of the well known flaws of capitalism, in the 'bad, but everything else is worse' sense.
Not that capitalism is the perfect economic scheme, but rentiers exist in many economic regimes. Communism probably has more rentiers than capitalism, i.e. many people take more than they contribute.
> 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.
AWS was directly funding Redis development, from the article, they are one of the top contributors, they even employed one of the core redis maintainers full time to work on Redis.
All the Redis users have is a license to use and an expectation. An expectation is a belief that Santa will bring presents, that's all.
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.
And the license allows them to fork it. Which is what they are doing. Open Source working exactly as it should. I just want to be sure the facts are understood. Amazon has many faults and there are plenty of reasons to dislike and not use them. But leeching off of Redis Labs is not one of them.
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.
> From my point of view managed databases only really make sense for toy projects
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.
Toy project are both cash and time constrained, but they’re at a scale where managed is cheap enough because they want to get you hooked.
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.
In my experience using redis, one of its better attributes is how easy it is to manage and scale. I've never scaled it to say, Facebook levels, but at that scale, I'm not sure managed services make much sense either.
Yes, it is ludicrous. My company uses hosted databases and "droplets" from DigitalOcean. Their pricing is absolutely absurd. I always wondered how they stay in business, but now I know.
Right, now count in contributions from other cloud providers: tensent, huawei, alibaba and you'll find out that they contributed much more, than actual redis-employed developers
I'm not for or against in this case. I'm anti what Redis the company is doing but I don't give a crap otherwise.
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?
> Are we really counting contribution based on LoC?
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.
> 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.
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.
Not sure what you meant. Is it wrong for Chinese companies or AWS to develop Redis or is it great, or something in-between?
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).
The alternative is to write it yourself or commission it, so let's be honest, it is about the cost. When you don't know what something is about, it's about money
Whether it's gratis or not isn't the issue. Some people used Redis not only because it's free of cost, but also because it's open source. It's not anymore.
It is open source up until Redis 7.4. Why does it matter to you (someone that cares about it being open source) if future versions created by this specific company are not? You (or someone else) can fork it and continue the work in an open manner. AFAIAC that is the literal purpose of open source.
I don't understand what your point is. I'm saying that it doesn't matter that the community edition is still free of charge, because it's the fact that it's not open source anymore that's the issue. What part of that are you responding to?
I suppose they're getting at why was it important that Redis was open source to you? Under the assumption someone else would be responsible for free updates?
The problem with this is, it's virtually impossible to compete against the FOSS trunk that your now-closed-source software branched off of, or FOSS clones of it. Low-end proprietary UNIXes got wiped out by GNU/Linux and the BSDs, for example.
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.
Would be nice if Redis wasnt eating Lua's lunch and would make a big (public) donation to https://www.lua.org/donations.html#donation (Maybe they do, but it wasn't something i could find evidence of)
> that redis will remain free to use in their “community edition”,
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.
>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.
Contributing to a foundation may be a trap too. If you assign your copyrights to a foundation, in many jurisdictions you no longer have control of the code you wrote. That means they could license the code in a way that you wouldn't do.
Yes, but that's where the "foundation" part comes in. If it's one whose charter explicitly states that it exists to support open-source software development, it is legally unable to do otherwise.
Yeah. As usual whenever something like this happens, there’s an endless supply of blatantly misleading FUD by open source license purists. Let’s not pretend that Redis has become unusable by….all but a few organisations selling hosted Redis solutions. The people who are “rushing” to replace Redis are probably doing so in a way that isn’t on their boss’s radar, and it’ll stay that way because their bosses would probably tell them to go do more important things.
For the first time, I know our (Apache Kvrocks, an alternative to Redis on Flash) committer Binbin Wang committed nearly 25% of the commits to the newer Redis version.
* 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)
Yeah some folks are built different. I’ve a colleague who once every few weeks opens random files and notices weird patterns, I’ve no idea how his mind works but boy does it work.
Why does the fix work like that - only checking for this one scenario when you decrement by type max? [1]
In Solidity, where it's a serious security risk, before the language performed overflow checks itself, library authors would perform the arithmetic operation and then e.g. check if the result is larger than the original value in the case of a positive subtrahend [2].
Neal Gompa opened a discussion on the Fedora development list, noting the license change and the need to remove Redis from Fedora.
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.
Docker Engine is the name for the compiled binaries, right? The licensing situation for them must be more complicated than suggested by that LICENSE file.
A bit reductionist. IIRC the main reason Docker was phased out because Red Hat wanted to push rootless, daemonless containers, which required CGroups v2, which Docker didn't want to support for the longest time. Since both versions of CGroups can't be enabled simultaneously, and no distro wanted to go without Docker (or at least Docker-like) functionality, CGroups v2 was left in permanent stasis, and so Red Hat started Podman to break the deadlock. There were a laundry list of other technical disagreements (mostly around security) but that was the primary one.
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.
No? Sorry if that's a bit cynical, but Docker is only dying in the opinion of distro maintainers. By this metric, it's been dying for the past 8 years, but everyone is still talking about Docker, not podman.
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.)
Yeah I don't think Docker is the type of tool the typical engineer cares enough about to go out of their way to learn something new, no matter how much better or simpler it may be. I guess it's like git; even though most devs only have a surface level knowledge, dethroning it would require convincing people to learn a new system, and that's not gonna happen no matter how good it is.
Red Hat at least had the muscle to force podman onto some people, but not everyone.
idk, I actively dropped docker as soon as I reasonably could. podman is an objectively better tool by nearly every metric and it has an almost exact 1:1 CLI tool, so there's not really a learning curve besides a few configuration differences
Sometimes I get the feeling all the folks touting podman as a drop-in replacement for docker are doing it in bad faith.
Every few years I try to replace my containers managed through docker-compose and it's always a sure miss. Before podman gained official support for the docker-compose spec, there was an unofficial podman-compose project that sort of worked save for a few podman incompatibility bugs here and there.
So I was delighted to try out the "official" docker-compose for podman. Quickly learned that there's no such package, the official podman-compose is just the same docker compose package, you just use it with podman the same way you would with docker. Despite this glaring inconsistency I decided to give podman a try (if you are going to install docker compose on your system might as well just use docker). Noped out when I tried to create a VPN with a podman container and it was failing requiring me to enable a kernel module (TAP or TUN can't remember exact error) to create a vpn.
Anyone who says podman is a drop-in replacement for docker never used docker much for anything more than running hello-world. I would only recommend podman over docker for someone who's new to containers and has never heard of docker before.
> Noped out when I tried to create a VPN with a podman container and it was failing requiring me to enable a kernel module (TAP or TUN can't remember exact error) to create a vpn.
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.
Podman doesn't expose an interface for enabling kernel modules. The error message is intentionally intended to discourage users from doing administration on systems, just like the other similar messages you'll get about trying to use "privileged" ports (<1024).
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.
>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".
Because at least you can tell that it's insecure, rather than insecurity being the default?
Secure defaults and containers is kind of an oxymoron.
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.
The page suggests podman in a small info box (one that people might skip, because it feels like the Wikipedian "this article has issues" box), but it also tells you how to install real Docker. Docker has name brand recognition, and even if it wasn't in Debian's official repos, it would be installed from Docker's own repos. This wiki isn't popular enough for this to matter anyway, people are likely googling for "docker debian" and are finding instructions for real Docker. I don't feel like Docker is dying.
And besides, that issue with root feels overblown in the era of single-user systems and servers as cattle.
docker-cli is still open source (Apache 2.0) and being distributed in most flavors of Linux. Docker the company does not own all the source code. But like redis they are free to build their own non open source products around this code base.
I liked Andrew Kelleys perspective on this: let's treat Redict as a rename of the Redis project, and the project now called "Redis" a weird commercial fork of Redict.
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.
This article lists the other contenders for the title of new Redis, and I think Redict is going to be the least successful thanks to its founder, niche hosting site, and the hostile AGPL licence.
The problem is Drew is being really hostile towards the actual maintainers and core contributors of Redis who are looking to move on towards an actual open source fork.
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.
Hey, this is really not how it went down and I'm kind of upset that it's being read this way.
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.
You are correct. The issue is that any [X]GPL license has bad reputation in business environments. They see it as a big legal risk that will require constant legal supervision over the technical usage of GPL-licensed code.
Poor little things that do not want to share anything want to work as little as possible. If only we could collectively diminish our commons to make life easier for companies.
Isn't this the reason why AGPL has started to get more popular? Everyone has to play by the very strict rules except the copyright holder, who can do whatever they want, but the community still benefits from the core software being open source.
The BSD license in particular seems like a particularly bad way to run a business.
The whole move to new "open-core" licenses started with the most famous (infamous?) AGPL project - MongoDB. The AGPL is not what companies like this want (Mongo, Elastic, Redis etc). They don't want AWS's code: AWS is already providing that. They want AWS to pay them royalties or stop competing.
> They want AWS to pay them royalties or stop competing.
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.
> But the switch from AGPL to SSPL didn’t do either of those things.
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”.
Well, I was using AWS more as a catch-all term for cloud. They never actually offered a managed MongoDB service, but other like IBM and Oracle did (or still do?). I'm not sure what impact this had exactly, whether those services were discontinued or if they are now paying Mongo for them - but surely they had a significant impact one way or the other.
> They want AWS to pay them royalties or stop competing.
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.
They dont't want AWS royalties. They wanna be able to command higher margins. Since AWS has lower costs and prices, Redis can't compete with good margins. The royalties are just a way to increase AWS costs, so that they raise their prices and give Redis the ability to keep high prices and margins, while still remaining attractive to customers (which don't have a cheaper choice anymore).
They want to make ludicrous profits on the software others have built for them.
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.
Yeah, it feels like this pattern of “ship an open source product, get popular, try to backtrack” ignores the fact that the only reason you got popular in the first place was the open source aspect.
Would anyone have given mongo a look if it was a fully proprietary technology? They would have gone bust years ago.
OP, OpenSearch, OpenTofu all seem to indicate the jury is still out on this one. I still see many smaller projects using open core. Three I started using recently ( llama-index, langfuse, qdrant ) are in this category.
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
I get it. If there are alternatives that overall would be better (including their technical merits and how easy it is to introduce them to a commercial company) then use them. No one is forced to buy dual-license.
If you’re happy with paying a few maintainers, a support staff, and some salespeople the cash flow necessary for being a successful endeavor is a whole lot different than if you’ve raised $350 million.
Maybe the problem lies more with overreaching and trying to cash out?
For sure, there is a problem in startup culture that looks down upon lifestyle companies. Devtools and developer focused products often get caught up in this.
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
That’s very true. Business is very much a balancing act in that sense. Sometimes raising money is the reason you succeed, but it can equally well be why you fail (especially if you’d be happy running a smaller company but take on investors that want you to be hungrier).
some kind of GPL + no CLA = good. If you contribute to GPL Redis, the Redis company cannot relicense your work, because they own it as much as you do.
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.
Microsoft's Garnet has the best chance of replacing Redis, the OSS project and the hosting company.
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 very unfortunate but classic myopic view of a hopefully smaller part of Linux community. Where-as .NET in reality is often easier to contribute to than a random project they are using with owner having ego issues.
It’s a stack they are looking for but keep missing right under their nose.
You must be confusing .NET (formerly .NET Core) with .NET Framework. Which is forgivable, because MS is terrible at naming things. The former stack is a joy to work with since some QoL changes a few years ago—as long as you don't need both a GUI framework and Linux support, in which case you're pretty screwed. (Our app is still on .NET Framework for that reason.)
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.
No such confusion is going on. Most Linux people won't touch the Microsoft .NET stack with a 20 foot pole, whether it's called .NET Core or .NET Framework.
Or Apple's Swift for that matter. Or Oracle's MySQL or Java. Or more recently Redis.
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.
AvaloniaUI and Uno are pretty great! There is also new actively maintained fork of GtkSharp as well as many other bindings. Honestly, it's as good as it gets in many other alternatives which don't have the advantages of .NET.
It's an important disclaimer as someone might read this and go write another tool in Python + Tkinter (with terrible results).
I think the point BartjeD wants to make is that due to the nature of MIT licensing, they could run away with your contributions anyway, even without a CLA. Furthermore, Redis didn't have a CLA if I remember correctly and the relicensing is solely based on the what the previously used BSD license allows.
Is that true? If I contribute to a MIT-licensed project without a CLA, my contributions can't just be re-licensed to some proprietary license, can it? Wouldn't my contributions remain MIT, even if they re-license all other parts of the project to some proprietary license?
Isn't the point of CLAs that you can re-license contributors' contributions?
MIT and BSD are so liberal that anyone can commercialize the work. All they have to do is attribute your parts to you, and not demand a warranty of you.
CLAs in those cases may be more to cover their ass in case of disputes about authorship, the future of the project, or in case they forget attribution.
Interesting, I thought the point of not wanting CLAs was not giving them the ability to relicense your code under a more restrictive license (i.e. SSPL), not to keep them from running away with it.
It should be a simple task to add that command and it is widely used. It sounds more like a business decision to not add it. It is not unusual that cloud providers make it difficult to delete data for various reasons.
As it currently stands, it is as difficult to get data onto Azure - you're supposed to manually deploy a container yourself to whichever cloud provider you are using, there is no "Managed Garnet" solution yet (but given hype it will probably arrive at some point).
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.
I was of course talking about a managed service. And the problem with deleting data exists in several Azure producs like Cosmos DB, Table storage, App Insights and so on.
AWS also forked ElasticSearch into their “OpenSearch” DBaaS. It caused some issues at my last job because OpenSearch limited us to a particular version of the NEST .NET library that was missing some newer functionality. Real bummer and feels like a step in the wrong direction given all we’ve accomplished in tech over the last 20 years.
It lacks so many improvements and advancements since the ancient version it was forked at, but because AWS already has an org's payments details, teams often refuse to look at Elasticsearch.
Even basic things like autocompleting queries have been WIP for half a decade now:
Teams should refuse to look at Elasticsearch. It's license is SSPL and they ship free and non-free features in the same binary. It's a ticking time bomb to run it in your company.
Also you can just keep your data in postgres and use paradedb and stop having to deal with dramatically more expensive infrastructure and the JVM.
The reality is that open search will be (if it is not already) more widely deployed and “battle tested” with bugs that production use raise resolved in it.
Opensearch has been great so far, no issues ever since deploying the very initial forked version. Neither of those links seem like dealbreakers, am I missing something? Is the idea that opensearch is not usable in production because of missing autocomplete?
> Is the idea that opensearch is not usable in production
No one said it's not usable in production.
> because of missing autocomplete?
We have an operations team that wants to do searches across 200+ fields for an embedded device's logs. The engine supports it just fine, but what kind of UX is it to expect them to do manual lookups of the fields available?
People with simple use cases of course can't imagine how important discovery features are.
Of course those aren't all the parity gaps, a random sampling of the ones I banged my head against:
- No Log Stream view, also critical for observability operations with any semblance of a reasonable UX
- No wildcard type, critical for machine generated logs having sane searchability. Searches are literally broken otherwise by false negatives.
- No nested fields in visualizations, can't visualize properly structured logs.
- Can't change indexes on visualizations, need to recreate the entire visualization.
- Can't use underscores at the start of a field name.
- Doesn't support auto refreshing fields which again, is terrible for embedding device logging
Elastic moved past basic search since the days OS forked it at, and now it's a genuinely nice choice for observability.
There's a literal report I wrote on the gaps there to justify going to Elastic before giving up on our slow RFP process. Every gap no matter how small is representative of what's wrong with OpenSearch: they don't have 1/10th the incentive to actually put comparable resources to Elastic behind it.
Especially when you have people lining up to make excuses based on the fact they're clueless about the gaps between them. Literal droves of people using it to provide a middling search experience to their users just don't see anything wrong with it.
Query autocomplete is a feature of the Kibana web interface, not of the ElasticSearch database itself. Which isn't to say that it isn't useful, but it's more of a niche utility than a core feature of the stack.
Maybe you're unaware OpenSearch covers Kibana's functionality via OpenSearch-Dashboards? Just like the rest of X-Pack under OpenDistro pre-name change
It's not exactly a niche utility for observability unless you plan on hand searching hundreds of fields. But of course see my other comment for a list of the other observability fumbles they've made.
Elastic chose a pretty great time to start to give observability attention, and OS didn't keep up there. Meanwhile search is becoming more and more focused on integrating semantic search (which Lucene isn't particularly excellent at)
What I'm getting at here is that there are use cases for ElasticSearch/OpenSearch beyond log collection and analysis; many of them don't involve Kibana at all.
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...