On March 21, Redis Ltd. announced that the Redis "in-memory data store" project would now be released under non-free, source-available licenses, starting with Redis 7.4. The news is unwelcome, but not…
The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider accepting the trial offer on the right. Thank you for visiting LWN.net! |
On March 21, Redis Ltd. announced that the Redis "in-memory data store
" project would now be
released under non-free, source-available licenses, starting with Redis 7.4. The
news is unwelcome, but not entirely unexpected. What is unusual with this situation is
the number of Redis alternatives to choose from; there are at least
four options to choose as a replacement for those who wish to stay
with free software, including a pre-existing fork called KeyDB and the Linux Foundation's newly-announced Valkey project. The question now is which one(s)
Linux distributions, users, and providers will choose to take its place.
Redis has a complicated
backstory. Salvatore Sanfilippo (also known as "antirez") started
the project to use as "a different kind of database
" with a
realtime log-analyzer application called LLOOGG, because MySQL was
not meeting his needs. Instead of creating a relational database, he
designed the project as a simple dictionary database that stored a
key-value pair in memory—its name is a contraction of "remote
dictionary server". It has, of course, matured and accrued many more
features over the years. Redis quickly became popular as part of
the NoSQL movement, and he was hired by
VMware to work on Redis development in 2010. He moved to VMware's
spin-off, Pivotal, in 2013 and continued to work on the project.
Around that time, Redis was growing in popularity, with high-profile use by Twitter and Pinterest, among others, and started to appear in Linux distributions. It was packaged for Ubuntu in the 12.04 (April 2012) release, Fedora 18 (January 2013), and others. Support for Redis was added to Amazon Web Service's (AWS) ElastiCache service in September 2013, which took advantage of, and helped bolster, Redis's popularity.
In early 2013, a startup called Garantia Data started offering Redis
services and positioning itself as a better alternative to "open source
Redis
". Garantia took a first round of funding in November 2013 and floated changing
its corporate name to RedisDB. After some pushback from Sanfilippo, the company renamed
itself Redis Labs, instead, in early 2014. Sanfilippo joined
Redis Labs as the lead for open-source development in 2015. He remained
with Redis Labs until stepping
down in 2020.
In 2018, Redis Labs adopted
a new license for its add-on modules that provide features on top of
the core database. The company chose to use a modified version of the
Apache License, Version 2.0, with an addition called the Commons Clause. This clause
restricted selling the software or charging for services.
The rationale given for the switch was that cloud providers were
"taking advantage of the open source community
" by selling
services based on open-source code they didn't develop. At the time,
the company pledged that Redis "is BSD and will always remain
BSD
".
It was not the only company to start experimenting with use-restrictive licenses. Venture-backed database companies, in particular, were starting to run toward new licenses to try to ensure they could exclusively sell services using the software. MariaDB had created the Business Source License (BSL) for a product called MaxScale in 2016, and MongoDB launched the Server Side Public License (SSPL) in late 2018. Eventually, Redis Labs settled on a dual-license scheme of SSPL and its own Redis Source Available License (RSAL) for its modules.
The company dropped
"Labs" from its name in mid-2021. In announcing the name change,
Redis again committed to open source, and said
that the company renaming "will not affect the
licensing of open source Redis, which has always been and will
continue to be BSD licensed
". The company also put in place a governance
model that would place major decisions about Redis's
"architecture, design, or philosophy
" with a community "core team".
One would expect that team's mandate to include the license for Redis itself.
The governance page is no longer on Redis's web site, but is
available on the Internet Archive's Wayback
Machine. It listed a core team of five members,
three from Redis (Yossi Gotlieb, Oran Agra, and Itamar Haber) as well as
Zhao Zhao from Alibaba and Madelyn Olson from AWS.
On March 20, Redis announced
that "all future versions of Redis will be released with source-available
licenses
", specifically the SSPL and RSAL. Rowan Trollope, Redis CEO,
wrote that maintaining the BSD license was now "at odds with our ability
to drive Redis successfully into the future
". Future versions, in
this case, means Redis 7.4 and later. The announcement's FAQ says
that, following the company's security
policy, security patches will be backported to previous versions under the original three-clause BSD license.
Proponents of use-restrictive licenses like the SSPL and Redis's RSAL have
tried to position this solely as a battle between giant cloud
providers like AWS and open source, where use restrictions are the only
logical alternative and cloud providers are the only losers. In 2019, Redis Labs then-CEO Ofer Bengal was quoted
as saying that there were "many different views
" after Redis adopted
its source-available licenses for Redis modules, but that it was necessary
to compete with cloud providers:
Some people condemned that [license change]. But after the initial noise calmed down — and especially after some other companies came out with a similar concept — the community now understands that the original concept of open source has to be fixed because it isn't suitable anymore to the modern era where cloud companies use their monopoly power to adopt any successful open source project without contributing anything to it.
In the March 20 announcement, Trollope wrote that "cloud service
providers will be able to deliver Redis 7.4 only after agreeing to licensing
terms with Redis, the maintainers of the Redis code
" but, that "nothing
changes for the Redis developer community who will continue to enjoy
permissive licensing under the dual license
".
The choice of the phrase "permissive licensing
" is
misleading. Redis is able to adopt a non-free license scheme for 7.4
and later versions because external developers had granted their contributions under
the permissive BSD license. The terms of the SSPL and RSAL are
incompatible with common usage of the term "permissive" in the open
source community.
It is also hard to reconcile the claims that cloud providers do not contribute with the actual commits to the Redis repository. A quick examination of the commits since the 7.0.0 release using gitdm shows 967 commits over that time period:
Top changeset contributions by employer (Unknown) 331 34.2% Tencent 240 24.8% Redis 189 19.5% Alibaba 65 6.7% Huawei 50 5.2% Amazon.com 50 5.2% Bytedance 19 2.0% NetEase 13 1.3%
BinBin Wang, of Tencent, is responsible for nearly 25% of the commits to the project. Some of the contributors without a readily identifiable employer surely are Redis employees, but it's clear that the company has not been working alone. (Note that some single-digit contributors were omitted.)
So it should be apparent that code contribution is beside the point. Redis is a venture-backed company that has taken more than $350 million in funding over many rounds since 2011. The company, and its investors, seem to have calculated that they can safely move away from open source to try to capture more revenue.
They have some reason to believe this is the case, if MongoDB's results are any guide. The company went public in 2017 and moved to the SSPL a little more than a year later. Shortly afterward, major Linux distributions stopped packaging the database because it no longer met their licensing standards. But, by that time, the company had set its sights on a platform model that would encourage developers (and their employers) to use and pay for MongoDB and ancillary offerings with the as-a-service model. Distributing a source-available version of MongoDB could be seen as a loss-leader strategy to reach developers that the company wagered did not care about open-source.
As Redmonk founder Stephen O'Grady wrote in 2017:
As developers began to assert control over technical selection and direction in increasing numbers, even in situations where a proprietary alternative is technically superior, the sheer accessibility of open source software gave it an enormous market advantage. Choosing between adequate option A that could be downloaded instantly and theoretically superior option B gated by a salesperson was not in fact a choice.
But open source, noted Grady, "is typically less convenient than
service-based alternatives
" and if convenience is the most
important factor then open source has a problem. Especially when
vendors like MongoDB have learned from proprietary vendors that "locking in
customers is good for business
".
Is it good for business? MongoDB has kept growing, adding customers, and brought in $1.68 billion its last fiscal year. That's more than a 30% increase, and its Atlas database service revenue also increased more than 30%, demonstrating that a lot of companies would rather pay to use the service than try to host it themselves. Despite all that, the company is still losing money—more than $345 million in the same time period.
But, investors may be more interested in stock price than actual profit. The company's stock started around $33 a share when it went public, but is now more than $350 a share. Redis's investors would likely be happy if it can produce similar results.
Venture-backed vendors seem to have, as O'Grady wrote
last year, reached a consensus that they can move away from
open source. Especially if they are not "actively opposed by other
commercial interests, foundations and other interested industry
participants
". Here, Redis may have miscalculated the industry
mood.
When Hashicorp adopted BSL for its projects last year, a fork of its Terraform project appeared within days and was embraced by the Linux Foundation under the name OpenTofu. On March 28, the foundation announced that it was supporting Valkey, a direct fork of Redis 7.2.4, with Amazon Web Services (AWS), Google Cloud, Oracle, Ericsson, and Snap named as backers of the effort.
The Valkey fork got its life just a few days after the Redis
license change. Olson wrote
that she and "various former Redis contributors
" had started working on
a fork, using the
original three-clause BSD license, with "placeholderkv" as a temporary
name. Olson, Zhao, Viktor Söderqvist, and Ping
Xie were listed as maintainers. According to Olson this was not an AWS fork of Redis, but "just me
trying to keep the continuity with the community
". KeyDB was considered,
but it has diverged to the point that it "is missing a lot of stuff the
community is used to
".
The KeyDB fork was created in 2019 for technical, rather than licensing,
reasons. The project, which billed itself as "a faster drop in alternative to Redis
" was created by John Sully and Ben Schermel,
who wanted a
multithreaded version and were not able to persuade Redis maintainers
to go in that direction. Sully and Schermel started a company, also
called KeyDB, that offered a proprietary enterprise version. The
entire codebase became fully open source under the three-clause BSD license when KeyDB
was acquired by Snap in 2022.
The problem with KeyDB as a direct alternative is that it hasn't kept up with Redis since
it forked. It still lacks many
features found in Redis 7, and Sully indicated
that there's little time for him to work on issues "not directly
affecting Snap
", though the project "would of course welcome
outside help and we can certainly name additional maintainers if there
is community interest in helping
". On March 22, Sully updated
another issue and said
he was in discussions to "potentially
" add maintainers to bring
KeyDB closer to Redis 7. It's not clear yet whether Valkey will
supplant KeyDB, but Snap's involvement makes that seem likely over the
long term.
Drew DeVault, founder and CEO of SourceHut, has also created
a fork named Redict based on Redis 7.2.4, but chose to use the LGPLv3. In his announcement
post, he said that the choice of license was "a deliberate one which balances
a number of concerns
". DeVault wanted a license that was copyleft but
"as easy as possible for users to comply
" with the license and
to ease integrations with Redis-compatible modules or Lua
plugins that can be used to perform operations within Redis.
He also noted that Redict will have no contributor license agreement
(CLA), but contributors would be asked to verify contributions with a
developer certificate of
origin. Despite his connection to SourceHut, DeVault chose to host Redict on Codeberg to
"provide a comfortable and familiar user experience for anyone comfortable
with the GitHub-based community
" of Redis.
Another kind-of contender is Microsoft's Garnet, announced
on March 18. According to the announcement, it has been in
development by Microsoft Research since 2021. It is a remote
cache-store that can cache and manage the same types of data as Redis and is designed to be compatible with the Redis serialization protocol. Garnet is MIT-licensed, written in .NET C#, and is not
meant to be a direct drop-in replacement. However, its API
compatibility page claims that it can be "regarded as a
close-enough starting point
" that works "unmodified with many
Redis clients
". Many, but not all. For example, one user attempted
to switch a NodeJS application to Garnet, but found that
Redis's FLUSHALL command is not
currently supported. Adding support for missing
APIs on is on the project's roadmap.
Once again, Linux distributions are left with a mess to clean up. Neal Gompa opened
a discussion on the Fedora development list, noting the license
change and the need to remove Redis from Fedora. Jonathan Wright
replied that KeyDB might be a replacement; he had been "loosely working
on packaging
" before the license change. He later said
that KeyDB would be "a step backwards and cause headaches
" for
those looking to replace later versions of Redis. Nevertheless, he wrote
on March 23 that he had pushed builds that were ready for testing for
Fedora and EPEL 8 and 9.
Shortly after the Valkey announcement, Wright
wrote
that he would be packaging it as soon as there is a tagged
release. Wright also said that he is "anticipating valkey becoming the [de facto] replacement for redis in most places.
"
Gompa also raised the issue on openSUSE's Factory discussion list. Dominique Leuenberger replied with a list of 18 packages with dependencies on the redis package in Tumbleweed. The initial discussion mentioned Redict and KeyDB as possible replacements, but Valkey had not been announced yet.
Having to find a replacement to ship in place of Redis is not the only problem for community distributions. Jacob Michalskie called out several services in use by the openSUSE project that will need a Redis replacement, including the Pagure code-hosting software (created and used by Fedora as well) used for code.opensuse.org, and the Discourse forum software.
Debian contributor Guillem Jover filed a Request for Package (RFP) for KeyDB as a potential replacement for Redis. Jover said he was not sure if he was up for sole maintainership, but was happy to give a hand. In an email exchange with Jover, he told me that his company had migrated from Redis 6 to KeyDB and it was a "smooth transition". According to Jover, "KeyDB might be lacking some features compared to Redis 7, but we have neither noticed we miss any or felt we were missing out on anything."
Jover said that it was too early to tell whether the newer forks would continue to be maintained, and that Redict's LGPLv3 licensing "might also be problematic for the ecosystem". In a follow-up email after the Valkey announcement, he said "I think we'll probably go further with packaging KeyDB for Debian at least, if it dies out it can always be removed or transitioned out from there."
It is, of course, too soon to predict whether one or more of the forks will gain significant traction—but it seems likely that Valkey will be a credible alternative. The possibility of a swift fork with widespread community and industry backing should give pause to vendors who expect a smooth path after abandoning open source.
Did you like this article? Please accept our trial subscription offer to be able to see more content like it and to participate in the discussion.
(Log in to post comments)
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.
Redis’ blog post: https://redis.com/blog/redis-adopts-dual-source-available-li...
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.
I believe that Redis has an agreement of sorts with Salvatore Sanfilippo / Antirez, the creator of Redis.
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.
Microsoft announced on the same day as the Redis license change that Azure's managed Redis offering will continue to run against the latest releases: https://azure.microsoft.com/en-us/blog/redis-license-update-...
Meaning that Microsoft is "paying to play" with Redis Ltd... while I have not seen any announcements from AWS or GCP.
I do wonder if Microsoft kicked this all off by telling Redis Ltd that they were willing to pay beforehand.
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)
They have engineering resources to maintain a fork, which they've made. https://github.com/valkey-io/valkey
Microsoft has its own redis alternative: https://github.com/microsoft/garnet
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.
Has anyone asked Filippo if he still wants to work on Redis "for them" though? The fact that he stepped down suggests he doesn't.
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.
Again, it's chump change, these companies drop that kinda money all the time in aquihires..
He worked there for 5 years. It probably didn't feel "random" for him.
> 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.
Same with many open source creators.
Plus some great projects don’t even get (monetary) contributions from large corporations. I think because it could weaken their legal position.
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).
> It's all about branding and name recognition
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.
Not just that - there's a significant ecosystem around Redis. A huge number of client libraries and tools.
Which is why Microsoft's new drop-in replacement works with all those things. It could gain traction - who knows.
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.
Already done. We are talking about a key/value store here. I don't get what all the histrionics is about.
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.
Good products == low valuations it would have stunned the investors if they focused of quality instead of marketing.
*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.
Yep. Precisely. Licenses are working as expected. People that spin this as “stealing” are simply showing their own lack of understanding.
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.
(I don’t know enough to be in either camp.)
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.
Not only that, AWS has been offering redis-as-a-service longer than the "Redis" organization has been.
But if the shoe were on the other foot, AWS wouldn’t hesitate to rip the carpet from under anyone.
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.
This is what I am confused about so what right do they have to enforce AWS from selling Redis when they do not own it?
Trademark, and it's licensed under BSD.
Basically Redis Inc is the one making the fork, which retains the Redis name since they purchased it from antirez.
From what I understand they acquired the rights to redis from antirez sometime after employing him. I assume he received money for this.
The licensing change only applies to their future versions which they own all contributions of which AWS won't be allowed to leech off anymore.
> AWS won't be allowed to leech off anymore.
Doesn't AWS employ Madelyn Olson? I mean, AWS have paid for Redis development.
Not exactly a leech.
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.
Err, after this license change Redis Inc will be the biggest leechers considering they didn't contribute the majority of the code.
> Yep still the biggest leachers
Redis was literally licensed for people to do whatever they want. That's not leeching.
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 ;(
Do you have some data to back this ?
AWS takes most of the profits whilst contributing relatively nothing back
It appears that AWS and friends are not "leeching" at all, according to the LWN article.> By contrast AWS takes most of the profits whilst contributing relatively nothing back
You do understand that AWS profits not off redis but by offering redis as a managed hosting provider.
Microsoft and Google do to, it's just that they're not as popular as AWS.
They're not re-skinning or re-selling Redis, they're selling a separate product - the managed operations for operating and scaling Redis.
You may not appreciate this (most on HN never do - see https://news.ycombinator.com/item?id=9224) But the value is evident to thousands of customers.
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.
> dwarfed by the 350M investment in Redis Labs
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.
> camouflage their predatory relationship with OSS vendors
If you don't want others to monetize your work, don't license it under a license permitting them exactly that.
It’s hard to argue that a use permitted by the original license is „predatory”.
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.
> That's fair in isolation, but one can justifiably argue that a repeated pattern of behavior is clearly predatory.
Yes, but there’s another explanation. Repeating the same mistake countless times and expecting a different outcome is naivety.
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!
It's lose/lose!
Not for redis the company if they follow mongodb’s trajectory
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.
Except Redis was never meant to be “owned” by this company. They are both predatory.
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.
Only one company is allowed to offer it as a service.
I think you are right about AWS leeching OSS.
If you own copyrights you’re not the leech.
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.
I think you're right.
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
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.
Is buying the same as leaching now? Words really do get diluted to the point of meaningless...
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.
The project still belongs to society as a whole! You can fork it too! You just can't profit off their future work.
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 does not belong to the society (whatever that's supposed to mean). It is not in the public domain as far as we know.
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.
Does this address your concern?
It is if the thing they bought had contributions from many other people but pretty much all of them got nothing for it.
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.
I'm sure their lawyers will be looking into it, you probably don't need to be concerned!
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.
> without paying any sort of compensation to the redis developers.
AWS employee Madelyn Olson was a committer on Redis since 2019. Since 2020, she was on the core team of maintainers.
Here's what she wrote about the above article:
> 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.
Which is peanuts compared to the 350 million that the VCs invested. You're totally right, but I think the internal financial pressure is higher.
Ah, so it’s not about open source and moral responsibilities. It’s about the responsibility we all owe to VCs to ensure they make money. Gotcha.
Isn’t that the deal we sign up for when we take VC money?
I like free money as much as the next guy, but VC isn’t it.
Who's we though? The former Garantia data did, but redis users didn't.
(And also I'd argue most of redis' value to users was already in place before the VC backed company got involved)
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.
You’re right of course.
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.
> without paying any sort of compensation to the redis developers.
Redis organization doesn't pay any sort of compensation to developers who contribute to redis source code. I do not see any difference here.
Doesn't Redis Labs employ paid contributors? Does Amazon donate their contributions back to the community?
According to the linked article, Amazon has contributed 5% of the contributions to Redis, while Redis, the company, has contributed 20%.
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.
> Does Amazon donate their contributions back to the community?
If they contributed to 5% of the code, and the code is open-source, then yes?
> 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.
They are not entitled to compensation over their previous work, but you/me/AWS are also not entitled to their _future_ work.
But when you see that currently Redis is mainly developed by Chinese companies or AWS all of this is rather ironic.
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).
5% of contributions is not “mainly” from AWS
Does this mean they aren't accepting external contributions any more?
If I put in a commit, what is redis going to pay me for executing my code?
Absolutely!
I continue to have mixed feelings about this kind of thing.
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
More like you can run Apache except in specific circumstances. People will put up with a lot if there's no alternative.
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?
The copies that were created under BSD still are. Go fork and multiply. You can even make your contributions GPL or commercially licensed.
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.
How to saw off the branch you are sitting on..
> 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!
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)
Isn't this the same with Elastic? Or that was a different situation?
Yes, very similar. ElasticSearch changed licensing, so AWS forked it and created OpenSearch.
> 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.
KeyDB, the multithreaded fork of Redis, is already way faster as a KV store.
Agreed. This a good engineering effort over at Snap. It does clustering too.
https://docs.keydb.dev/docs/cluster-tutorial/
I wished they'd release some of their "Pro" stuff and/or internal-only features.
Do you have an email address or a contact method?
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.
You can find his contributor for both at:
And here is an interesting conversation when Binbin came to the Kvrocks community: https://github.com/apache/kvrocks/pull/1581#issuecomment-163...
* 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].
[1] https://github.com/apache/kvrocks/pull/1581/commits/dc5140dd...
[2] https://github.com/KingdomStudiosIO/contracts/blob/51873b574...
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.
Moby is open source. The licensing situation for Docker Engine is unclear.
https://docs.docker.com/engine/#licensing >The Docker Engine is licensed under the Apache License, Version 2.0. See LICENSE for the full license text.
The linked license file is moby's https://github.com/moby/moby/blob/master/LICENSE
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.
How so?
> need to remove Redis from Fedora
I don't get it; does the new license prohibit it from being distributed thus, or is this a philosophical "need"?
Fedora only includes free software in it's repos:
> If it is proprietary, it cannot be included in Fedora. (Binary firmware is the only exception to this)
https://fedoraproject.org/wiki/Forbidden_items
Proprietary software is distributed through the unofficial RPM Fusion repo
Docker was only phased out in red hat distros because they don't like it and want to push Podman. Others still have docker packaged in their repos.
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.
It's not in Debian and their wiki straight up directs you to podman with a nice big scary warning about dockers root issue.
https://wiki.debian.org/Docker
Docker is dyeing on linux podman will be the only one that remains.
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.
Also containerd and cri-o fit in here somewhere, too.
I could be convinced Docker-on-headless-servers has been dying a while but the desktop variants are alive and well
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.
> that issue with root feels overblown in the era of single-user systems and servers as cattle.
Uh. No.
It's in Debian: https://packages.debian.org/sid/docker.io
That version is so old. I just use Docker's own apt repo to not fall behind.
huh well I'll be damn I thought this had already been resolved back to the mailing list it seems.
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.