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.
I feel copyleft licenses look more favourable at this point of time. What’s the value of more free/business friendly licenses if you can’t guarantee that the same license will apply for all the future releases? Looks more like a bait and switch policy.
Am I right in understanding that the relicensing was possible because of the CLA, not just because of the BSD license? Would a permissively licensed project that didn't use a CLA be vulnerable in the same way?
A key concern is that BSD isn't viral, so anyone can take BSD Redis and fork it into a commercial offering. If you want to, you can. The Redis trademark prevents anyone but Redis the company from calling their fork "Redis".
A CLA may impact relicencing, it depends on the terms. A simple CLA may only say "I am the owner of the code and I release it under $LICENSE". The current Redis CLA also has a copyright grant, which gives Redis the company greater rights.
“Viral” just means that the license has a “no additional restrictions” clause, not that you can’t make a commercial offering out of it. That’s why GPL and AGPL don’t really solve the problem.
And the problem with the trademark model is that AWS, and especially Microsoft, already have established brand recognition with the people who sign the big SaaS and support contracts. The people who know what a Redis is are just nerds with no money, the real big shots do everything in Microsoft Excel.
A permissively licensed project without a CLA would be similarly vulnerable, because the BSD license allows them to make releases that include your code under a stricter license. To prevent them relicensing you would need both a strong copyleft in the license and no CLA/copyright assignment (like e.g. Linux - which can't even move to GPLv3 even if they wanted to, because it would be simply impossible to get all contributors' permission).
No, since you can include BSD-licensed code in non-free software with just an attribution. The only difference between relicensing Redis from BSD+CLA to SSPL and BSD to SSPL is that the former would've had a more detailed REDISCONTRIBUTIONS.txt.
The copyright owners of a GPL software can do whatever they want with future versions, even going proprietary. The problem is that all the owners must agree on that. That's why some GPL software only accepts contributions by people that give copyright to a single maintainer entity. An example is FSF's copyright transfer, which to be fair is more nuanced than that and has also other purposes.
All this outcry about license switch coming from "community" feels funny. After all, if there is the "community" then they can take the last open-source version and keep developing it themselves, right? But most "communities" are about "take, take, take", not "work, work, work". They often upset only because someone declared they aren't going to work for free any more.
Author of the article here. There may be some scenarios where there's a company just tossing code over the wall under a FOSS license and people complain when it stops. This scenario is not that.
The company now known as Redis did not invent Redis, it started as a company trying to make money hosting other peoples' work. After it finally hired the creator of Redis, it specifically promised not to do what it has just done (move away from three-clause BSD as the license for Redis core) at least twice.
In the development cycle from 7.0.0 until a few days ago, Redis isn't even the majority contributor to the codebase. The largest single contributor is from Tencent. (All of this is in the article.)
If Redis had been doing all the development, had not promised it wouldn't move away from the license, then I might agree that people have little to complain about.
But this situation isn't as you've suggested here where a community is all about "take, take, take" from a company that's been doing all the work. The company was founded on the idea of trying to do what it now complains about Amazon doing, and their claims that cloud companies do not contribute is clearly false -- just look at the code contributions.
to answer my own question, i didn't realize tencent had their own cloud offering with all the major software available a service, guess they/him just do general development and bug fixes.
In this case the community is the biggest contributor to Redis. The ones that "take, take, take" is Redis the company. Your comment seems way out of place in this light.
Good. So now Redis Inc is in trouble because they have to replace community work with their own. If community does most of the work, then what's the problem?
The problem is too many people are announcing OSS forks so it’s hard to align development efforts and users are confused. No one’s begging Redis Labs (which didn’t create Redis in the first place and only took over the brand with VC money when it was already popular) or whatever they’re called now to keep the bug fixes rolling. They only account for 20-50% of recent development anyway (50% if you attribute all “unknown” contributors to them), with the other 50% from (predominantly Chinese) cloud companies allegedly “pirating” their software, according to some.
I don’t typically ask people to RTFA because that’s against the rules, but you would have known all of the above if you bothered to read the article.
Yeah, it is incredible how the whole free software movement turned into a bunch of entitled folks that want to be paid for their work, while refusing to put down any penny for the folks that make their tooling possible in first place.
At the same time big corps use it as carte blanche to basically pirate software in a legal way, while following the letter of the licence.
Going back to the open core/demo versions (aka Shareware/Public Domain/Trials) is the only sustainable way to make a living.
aka, just sell software, rather than make it open source.
What is being balked at is the idea that you can use open-source as a foot-in-the-door marketing and growth hack, which you then reap after some level of popularity/network effect is reached. Some call it bait and switch.
Blaming big corps for "leeching" is just self-serving. They are doing exactly what the license allows them to do - a license for which was chosen at the start to allow for it! If you expected to be paid to make this software, don't opensource it.
None of what you say is happenening in this case. Unless by "entitled folks" you mean Redis Inc.
The community has been doing the heavy lifting over the years and Redis Inc has been trying to reap the benefits off of that by providing the software as a service. Which the community was fine with. Turns out other companies with deeper pockets for infrastructure can do the same. Now Redis Inc is trying to save their broken by design business model by changing the license. This casts a whole lot of doubt on the future utility and licensing of the Redis project. And this is what the community balks at.
You keep making comments about this, as if Redis was build from scratch by the company that is now making it closed source.
They bought an open source project, and now that the original founder has stepped away they're trying to squeeze it for all they can.
The "big corps" that you claim are using it to "pirate software in a legal way" (a) have been contributing to the formerly open source redis project, and (b) are now specifically forking it to keep maintaining it as open source.
Supermarket bills don't get paid by broken business models either. If Redis Inc never existed, Redis the software wouldn't be much worse for it. I'm starting to wonder who the entitled is in the first place.
> rigthfull owners of Redis and the author has freely given ownership to them
By using BSD license Antirez has freely given it to the whole world, not the name Redis but the code. No matter how big the corporations, the cloud providers are just using that code the way Antirez intended when he used the BSD license. You can't blame the cloud providers for that.
> Supermarket bills cannot be paid with pull requests.
But one can become famous by writing quality open source software and this fame can be used to get very high paying jobs.
Eh no. What an overly broad generalization to read. Whether it is enough to make a living is another question, but that does not mean one must paint all of the communities the same color.
The problem is companies externalising development work on the boring parts of their software as "community edtions" and the like. That is a very distinct category of open source project and the only one that any of these discussions revolve around.
You seem to believe that all open source projects are in this category. That is not the case. You also seem to believe that there is always one company doing the most work and everyone else is just leeching off. That is also not the case.
I for one don't like it when companies do a bait-and-switch. It's fine to develop proprietary software, the problem is when you grow a user/customer base based on the fact that your software is open source and then turn it proprietary.
So I take it you endorse the Amazon-backed fork? Amazon too strives to be self-sufficient, and has moved on from Redis because the factors are no longer conducive to its goals.
If it's legal, it's not piracy. It is merely availing oneself of an opportunity. If the authors meant to license the software differently, they should've done so.
I'm sure that (FL)OSS core/demo versions is not the ONLY sustainable way to make a living. There is no need for hyperboles.
You don't even need to author software to sustainably make a living. Don't limit yourself.
That doesn't seem like a very reasonable takeaway from an article which describes almost too many people announcing that they will take the last open-source version and keep developing it themselves for everyone else to use.
If you only take, obviously there is no reason to complain. Now the problem is rather when contributors (those who "give", not those who "take") have to sign a CLA. Then the company who gets their copyright takes their work for free, to later use it in a non open-source project (assuming they changed the license, like Redis did).
I think it is valid to find this immoral. The solution is pretty simple though: do not contribute to open source projects that require you to sign a CLA.
Using the code later in a non open-source project can happen also with MIT/Apache licensed code. Even without CLA. Does it mean that company that does it is immoral?
If you use MIT/Apache code that doesn't enforce a CLA, the contributor keeps the copyright on their contributions. So no, that's not immoral, that's part of the license the contributor chose for their contribution (the contributor could make a PR and license their contribution with e.g. GPL: that would be their right).
What is considered immoral is to take the copyright from the contributors without giving any compensation.
That is not the problem with the CLA (of course you can fork). The problem with the CLA is that the company then uses the contributed code just like if it was their own, even though they did not pay for it.
Developers should be aware of that and, personally, I think contributors should never accept to sign a CLA. If the project requires a CLA, don't contribute.
Yep, that's exactly it. Of course it makes sense: making requires several orders of magnitude more effort than using. But if a project changes/goes down, the community often just moves elsewhere, nothing major lost from their perspective.
And I think Open Source is based on the very few who decide to take it upon themselves to be the ones spearheading a specific project/task and share it with everyone else. Maybe it's not every single time me, sometimes it's you, sometimes it's Lucy or Mark, and that's how the roll keeps rolling for everyone.
So if a project goes down and nobody comes up to replace it, either it wasn't worth much or this is the time nobody took it upon themselves to do it (yet).
That's a dumb take. That completely ignores opportunity cost of such actions. You can't just spin up a fork like that; there's barriers to entry, network effects, etc which prevent that from being a simple solution.
One thing I think people underappreciate is license compatibility - the projects which bundled BSD redis very likely can't bundle SSPL redis without changing their own license, or not at all if some other components are licensed with license not compatible with SSPL
This is actually the good news as it makes it all but certain there will be well maintained Open Source Redis alternative.
Because tencent consistently won Pwn2own and other CTF competitions until their government turned protectionist/isolationist and disallowed them from disclosing 0days to the world?
Yeah but if you’re going to the trouble of switching, probably pick something that actually outperforms Redis/Redis Cluster. Which basically leaves you with Garnet.
Redict is a pointless endeavor. Just stick with Redis 7.2 before the licensing change. Maybe change the binary name if it makes folks feel better.
Maybe it's good for GitHub, GitLab, etc. to be as open and liberal as possible with its definition of open source, but I think there is definitely an argument to be made that businesses making source available without actually open-sourcing it should pay to have it hosted. GitHub didn't become proactive about asking users to add licenses to repos until far into its existence, and there's plenty of code there that doesn't have an explicit license, but I think participating in the open source community should actually require that your source is open. License proliferation is already an issue, but adding non-open source to GitHub seems especially dangerous to me. The license should be highlighted in bright red with a big note saying that users are not allowed to do what they will with the source code.
As many others pointed out before, Redis Labs did not create the project,
they started to provide Redis as a hosted solution just like other cloud providers, and with time gained control.
Redis Labs is not the only contributors to the project, Tencent and AWS contribute as well.
For Redis Labs the open source license was a distribution channel
which they benefited tremendously.
I'm not an AWS fanboy but they operate some hosted solution significantly better than
the companies building the products, at least the core offerings, this is what happened with Elastic and MonogDB.
It is Redis Labs prerogative to change the license, but they can also build a product around Redis
that will drive customers to them instead of AWS, an offering that will be hard to replicate.
IMHO making a business that is "reselling" server capacity that was bought from AWS and trying to make a profit, can come back and bite you.
It reminds me of the berkely db situation, where they(sleepycat software at the time, but now I think it is owned by oracle) changed the license to try and sell it, and everyone just kept using the last bsd licensed version.
Far more involved people are in this thread, but my 2c. Forking of software isn't a big issue, but of the community is. If new software was R++ which company will close and original Redis is now in hands of the community everyone would have been OK. The community is built organically and has contributed a lot over the years. Now, it will have to be built again where the efforts would be diluted in multiple forks till they gravitate toward one. Maybe AWS, Tencent, MS will back one and we'll have to settle on a version backed by corporates.
I love passion projects as much as anyone, but there is a reason they are hobbies, and people need to keep a day job. Eventually it does get tiring to do support for free.
Edit:
Ok. I was talking OSS generally. I guess Redis is being bad actor if they are taking OSS work and running away with it to get the money, and not compensating the contributors. That is very wrong. I don't know history on Redis and assumed it was the contributors that founded the company.
I think the main issue is bait and switch. You start with a license, get lots of external contributors who are working for free, get ecosystem built around it for free and then change because you want to be paid.
Does it matter if you intended to do something nefarious all along, or if you just now saw an opportunity to be nefarious? All that matters is that you are doing something nefarious.
I'm not sure how nefarious this Redis move was. I guess I was assuming any move from 'free', to 'paid', will be met with some outcry regardless of how seamless they can pull it off.
Or in other words, it is always a messy transition?
I'd love to be corrected here, but my understanding is that the enterprise support and pro features model can be a pretty good business.
Big deployments generally need really good support and help to overcome scaling challenges. Who better than the library maintainers to offer that, and your customers have deep pockets.
Then on top of that, you run a business which basically creates proprietary Pro and Enterprise versions of a product which has tooling to operate the project at scale or in high uptime environments.
Then you offer your own cloud versions of the product as well (which I think Redis has been doing).
But in none of these cases are you creating a disincentive for anybody to use/adopt your product. You're simply creating value around the pain points.
I agree. People here always seem to react badly to companies that provide something for free and now want to make a bit of money. It’s weird because they themselves work in tech and have to earn a living to put food on the table. Having no way of making money isn’t sustainable.
Then don't make an open source hobby if you want to pay the bills with it. Or accept you're going to have to be a consultant for the project to make $$. I don't expect jack shit back for my open source contributions nor do I care if Amazon uses it.
I see valkey getting a lot of attention recently, as it is a newly founded alternative. What is the major differences over using TiKV which has been around for many years? https://www.cncf.io/projects/tikv/
I'm disappointed that FOSS discussions like this always devolve into profit-focused arguments.
It's no wonder our "freedoms" in the software world have slowly but steadily been shifting to look exactly like our "freedoms" in the physical world: artificial scarcity apportioned by the few using their leverage over systems which put you in a steel cage if you don't play along.
And here we are, arguing with each other using the terms of those who seek to enslave us to their control. The fact that these billion and trillion dollar tech companies even exist is a testament to our failure.
I'm actually sympathetic to the cloud provider angle. As of right now, that is the natural trajectory. The majority of high-value customers are going to go through a cloud provider.
Maybe some kind of new license is in order. Open source, but preventing cloud redistribution. I don't know, I can imagine the issues with that as well. You want AWS out, but you probably still want the small up-and-coming CI/CD tool in.
I see that it is. So then I don't see what the hoopla is about at all.
The software is all there. Some dickheads forked a proprietary version. They got the name, which will be their consolation prize in their voyage to irrelevance; nice knowing you.
I believe that the hoopla is about the CLA. It feels immoral for an open source project to accept contributions but require a CLA, and later change the license for all those contributions that were never compensated.
If a GPL-ed project requires copyright transfers and then spins a proprietary version, it makes sense for people to be upset.
But Redis was BSD or BSD-like, no? Proprietary forks can happen with or without CLA, so it is moot.
I would say rather the opposite. If a developer contributes to a BSD (or similar) licensed program (under that same license of course), then at that point they are letting anyone anywhere do whatever they want with the code, as long as copyright notices are preserved. Then, if someone forks a proprietary version of the program (in a way that complies with that developer's license for those files) and that developer gets upset and tries to revoke the copyright license, that developer is the bad actor, not the forkster.
In the context of BSD-like permissive licenses, requirments for CLA, I think, would only be a form of legal safeguard against such situations, where people change their mind.
Am I insane or can't a company just fork it from before the license change? I mean, what even needs to change in it? I assume 95% of people were just using it for the features it's had since the beginning anyway.
The question - just like always in cases like this - is which forks will get long-term support. So just like with Terraform, it's probably a good option to stay on the last open source Redis version and wait to see how things shake out, assuming that there are no critical security vulnerabilities in that version of Redis. Alternatively, be prepared to jump around between a few forks if one turns into a dead end. Or move to something else altogether, but that's a much bigger undertaking.
"Getting Jeff'd" is only an existential crisis if your goal is to own the majority of the pie. Postgres's contributors come from a bunch of different companies who all manage to make enough money off of Postgres to pay them [0]. That is the only financial metric that really matters for funding a FOSS project.
The problem with these companies is that they actually were trying to make large returns for shareholders rather than simply earn enough to keep paying the developers.
They wont get totally cut out though - Jeff Bezos will send the bugs they find while servicing their $10mil a year service contract to the raggy startup of five to fix over a weekend between their 3 jobs while sustaining themselves on the most expensive food they can afford - a bowl of discount ramen.
I wonder if there is a use case for an open source permissive license that also cannot be changed. Several companies have started off with MIT in infancy and then switch to something else later when successful to improve monetization.
I mean, I get it, everyone wants to become billionaire, but best to be honest about it up front.
Why don’t we try to fix the “cannot be used for bezos yacht”-licenses instead of shunning the numerous companies of especially databases who want to do good in a meaningful way? Source available is good, better than proprietary which is what we get with aws, but still not enough. People are legitimately afraid of rug pulls, like sneaking in essential features into paid offerings. I think a lot of the skepticism comes from those unknowns.
Afaik the non-discriminatory use is the only ideological hard line. I guess people can debate that forever, like with GPL and copyleft and such. But my edgy take is that most people don’t really care about deep ideology yet want something that promotes a healthy hacker- and small-business friendly open source ecosystem. Ideally, a simple, well-understood license that restricts “re-selling your product” and not much more, that you can slap on a project without a legal team, just like with the MIT license.
> that you can slap on a project without a legal team
The thing is, this kind of license is only really relevant to the kinds of projects that do have legal teams.
If you're writing a hobby project you probably shouldn't waste time worrying about feeding the AWS machine, because the odds that you'll get noticed and used are tiny. Just pick GPL or MIT and be done with it.
If you're participating in a large decentralized project like Postgres, then having a big player like Amazon providing managed hosting is actually a huge plus because you get lots of contributions from the big players [0]. There's very little downside for a project like this, and lots of upside.
The only type of FOSS project that needs an "AWS can't use this" license is a project that is driven by a single for-profit company which decided to make their business model "provide a managed solution layered on top of AWS". Unsurprisingly, it's hard to compete with AWS on price when you're using AWS itself as your vendor, so these companies tend to be the ones that switch licenses to tell AWS they're not allowed to compete.
These companies almost certainly have their own legal counsel and they represent a tiny minority of FOSS projects, so it's not obvious to me that we need a new standardized anti-AWS license. Maybe we should instead acknowledge that "managed-hosting-supported FOSS database" is an impossible business model and try something different next time.
> The thing is, this kind of license is only really relevant to the kinds of projects that do have legal teams
So you want to advocate that every future database / infrastructure company needs to burn part of their runway to hire lawyers to do the repetitive work of making sure they can both try to be open and try to continue to exist? Plus we, the users, get to try to decode reams of legalese instead of using a convenient three-letter handle for an industry standard, like GPL or MIT? This does not seem ideal..
> Maybe we should instead acknowledge that "managed-hosting-supported FOSS database" is an impossible business model and try something different next time.
The business model these companies chose was fundamentally broken. It's only fundamentally broken for a specific class of backend tooling.
I believe that future database/infrastructure projects should continue to use the FOSS licenses we all know and love and find a sustainability model that works without compromising the freedoms that make free software free. Postgres, Linux, SQLite, the BSDs, and many other projects in similar spaces have led the way.
People need to make money somehow. Developers who spend years creating, maintaining, and continually improving an open source database (or other project) used by millions deserve compensation. This doesn't apply as much to Redis Labs since they swooped in much later, but the general principle of trying to monetize your project with source-available licenses doesn't feel unethical to me.
You're right that it's probably not a great business model most of the time, but what is a good business model to collect some of the value you've produced from dedicating years of your life to something loved by millions of people? It's certainly less sketchy than monetizing a free service with ads, or something.
> People need to make money somehow. Developers who spend years creating, maintaining, and continually improving an open source database (or other project) used by millions deserve compensation.
Look at the list of contributors to Postgres that I linked to. The vast majority of them are employed to work on Postgres, some by big tech companies, others by smaller managed hosting providers and consultancies.
That is a sustainable funding model for an open source database project. What isn't sustainable is building a business around the idea that only your company will ever profit off of (and thereby fund) the FOSS project. The whole point of FOSS is that both the work and the gains are shared with the whole community.
> This doesn't apply as much to Redis Labs since they swooped in much later, but the general principle of trying to monetize your project with source-available licenses doesn't feel unethical to me.
Yes, monetizing with a proprietary license, whether source available or not, doesn't seem unethical to most people outside of Free Software ideologues.
“The licensing model isn't unethical but competing ones are” isn’t why open source licenses became popular over proprietary (including source available) licenses, the fact that they commoditized the underlying software, enabled competing orojects evolved from the same codebase on essentially equal terms (which also allowed a competing project to fully replace the original if the original at some point failed the community) and, as hosted offerings became more common, the zero licensing friction for hosted solutions, that's what did it.
It does mean charging monopoly rents for a hosted service isn't a viable way to recover development costs and pay returns to VCs, but until fairly recently, no one was trying to do VC-backed startups around single open-source products with that as their whole business plan, and the arguments as to why that would be a bad idea were well developed by the mid-1990s
There is no requirement to make money to have a successful open source project.
That being said. Monetizing open source is fine so long as people are up front about from the beginning. People are upset because switching the license is effectively changing the rules in the middle of the game.
It is like going out to a restaurant and in the middle of your meal they change policy from having free refills to charging per cup. Either policy is fine, but changing policies is a scumbag move. A lot of people would have never sat down to eat there if the extra drinks weren't going to be free. Especially if free drinks was the sole reason a lot of them were going there.
> Developers who spend years creating, maintaining, and continually improving an open source database (or other project) used by millions deserve compensation.
Redis Labs can start by compensating its external contributors (Tencent, Amazon, Alibaba among them) if they care about fairness this much.
There's many things that I don't like about how open source works, but non-discriminatory licensing is not one of them.
In fact, the concept of the four freedoms as necessary parts of a more fundamental freedom is one of the things that I value the most about the free software/open source world.
In hindsight, I think that the probability that things turned out the way they did in this regard was relatively low, but the ideological drive of GNU and RMS made the world see the problem from a philosophical perspective rather than a practical one (even among people that don't fully agree with RMS/GNU/FSF).
The best idea I've come up with is a license which only grants the rights to a natural person to use the software otherwise it is identical to the MIT, GPL or AGPL, whatever your cup of tea is.
If you're a corporation then you need to buy a license.
Certainly not a new idea. As recently as early 1990s I licensed shareware that had terms requiring corporations to pay for a license with different fees and/or restrictions as those for individual, non-commercial users. Somehow this ideal was lost. Today, software authors seems allegiant to so-called "tech" companies, not to individual, non-commercial end users. As a non-commercial end user, I would prefer to use versions of open source software that are _not_ receiving contributions from so-called "tech" companies. But I never see software licenses that say, in so many words, "If you are Amazon, Google, etc., then you need to contact the author for a commercial license." I used to think back in the 1990s that open source software was aimed at least in part at giving individuals an option to use software outside the control or influence of large corporations. This type of software does not feel as if it has the same goal today. It feels like it is literally _made for_ those large companies, not individual, non-commercial end users. Software authors seem delighted to engage with the companies, but generally prefer to avoid engagement with non-commercial end users.
No, a non-commercial license is not a natural born person only license. If you're a human you get to use the GPL to your hearts content. If you're a corporation you do not.
It's not a hard concept to understand, but it does mean people can't steal from the commons so they spend a lot of time trying to not understand it.
I would have to look at the terms to understand. Your comment just reminded me of those sharware-era non-commercial licenses. That's all. Did not intend to suggest the license you mentioned is similar or the same in any other respect than having different license terms for commercial entities versus other users.
This could be an interesting idea, but how would this constrain incorporating the licensed software in a larger piece of software? Either as a library, or a component like a Docker image?
Would it be "viral" in the sense that, if I want to publish software that internally uses a Docker container running software with such a license, my own software can be used only by natural persons?
The GNU project has failed at getting source code to users so badly that despite owning a half dozen GPL based devises I have no access to the source code of any of them.
At this point listening to them is at best pointless and at worst actively harmful. This is what happens when the last time you worked at a real job was some time in the 1980s.
There exist shared-source licences which do this (https://prosperitylicense.com/ is almost what you describe, but it's the one I can recall of the top of my head), but you can't (by definition) have a open source license like this.
That's not what AWS is doing. AWS is selling management services. The fact that managed DBs are as popular as they are says this is a significant value add.
Well yeah technically the product is free but the value comes largely from unpaid labor. That needs to change if we want a healthy small business sector around larger open source products. It’s not based in opinion or ideological conviction on my end, but rather watching this frictionous and awkward transformation to BSL-style licenses happen over and over with small-mid-size companies who are building valuable products and want to be as open as possible while running a business.
> The fact that managed DBs are as popular as they are says this is a significant value add.
Indeed, and that’s a good thing, because it means a path to a sustainable business model is feasible! However, if you subsidize the product (make it free and open) in order to make it back in management fees, then you need legal rights to it. It could be “you have to use $PROJECTs own management product” but that’s quite narrow thinking. It’s a win-win for everyone else if mega-players like aws can provide their own management but they will have to rev-share with the project owner, on their terms. That’s a battle-tested model that works in all kinds of sectors, with much smaller actors.
And that's also how DB companies try to monetize. So a hyperscaler offering this directly really undermines your entire business. In the past you could offer a Enterprise version with support, but with the move to the cloud that market is shrinking and Amazon is eating the new market themselves
Perhaps we need a different way to fund database development (not necessarily a single company monetizing it).
If the service you provide is hosting DBs, you are are at an inherent disadvantage competing with hosted db offerings form your potential customers' cloud provider. Even if your product is technically superior in every way, you are another entity they have to do business with (billing, support, contracts, security evaluations, etc.), which adds friction, and either you host on your own infrastructure, which means higher network latency, and network costs to get data to and from your customer's cloud, or you have hosting options that run inside all the major cloud providers, in any regions your customers use, which means you (or your customer) ends up paying the hyperscaler for the infrastructure, and you have the added complexity of having to know how to manage it on multiple cloud platforms. And there there is also the fact that it is much more difficult for you to build integration with the cloud's IAM or other services.
Basically, most cloud customers would rather use a service that is part of the cloud platform than from another provider. Ideally, instead of competing with the hyperscalers, they would sell some service to the hyperscalers that have the ir own hosted services. But I don't know how to get there.
As a brief sidenote, AFAICT this isn't what happened with the hashicorp license change, for them it seems like the pressure largely came from startups, not the big cloud companies.
> Perhaps we need a different way to fund database development (not necessarily a single company monetizing it).
We have several in use by long-running open source database projects that have not felt a need to jump on proprietary source-available licensing, even though firms like AWS are indeed using their code and selling services.
AWS (and other big firms with hosted services) are also sponsoring those DBs with code and/or money, but in many cases the basic model predates the big push to the cloud, and other downstream businesses were doing that before AWS and other cloud hosts.
What you're sort of proposing is cloud SaaSaaS. AWS would build out hooks for providers to manage the DBs they sell so they look like part of AWS. The main problem is AWS already has most of the services most of their customers want, so there isn't a big market opportunity.
> And that’s also how DB companies try to monetize
Open source DBs have been around a while, though. A minority of them trying to pay the bills with monopoly rents on hosted services is… much newer. Its how VC-backed DB-as-central-tech startups try to monetize, and, yeah, if you are going to do that, you need a proprietary license.
But don’t expect people to treat your DB like an open source DB, then, either. You can be Oracle instead of Postgres, but you can’t also expect to get treated like Postgres, instead of Oracle.
Define "fix". By definition you cannot have an open source licence which says "cannot be used for bezos yacht". Either you accept that, and don't rely on exclusivity for income (which really what the whole relicensing thing is about), or you don't open source your code (and accept that not being open source is a problem for some people). Open source + exclusivity for income is an unstable state, and really only works if no-one else competes with you (e.g. a specific niche), or you have some other means to enforce it (e.g. Red Hat limiting access to source to its customers, and not renewing contracts if they share the code).
It’s early. Everyone is confused. If I could define it, I would have provided a defintion.
At this stage, it’s about acquiring requirements and looking at prior art. And being humble about the solution space. No? If you don’t think there’s any problem today, then argue that point.
> By definition you cannot have an open source licence which says "cannot be used for bezos yacht".
By definition by what definition? There are already disagreements about what open source is, long before these business models. The problem solving comes first, and then there may or not be a debate whether about whether the solution fits better into an existing definition or a new one.
> Either you accept that […] or you don't open source your code
But why? Is this an intrinsic duality or an anccidental/historical one? Or is it about preventing scope creep of the open source term? The latter is easy to solve - don’t call it open source. Or at least defer the debate.
No, it is not, it is decades in, in a well-understood area. Some VC-backed firms (and the VC’s backing them, who see this as critical beyond the immediate firms) want to trade on the idea and popularity of open source without its substance because open source as has has been known for decades is not a viable foundation for the kind of business model that they would like, but has at the same time secured the kind of mindshare in the market that makes it difficult for proprietary software to achieve the kind of rapid ramp-up that provides the timing and combination of returns they want. So they’ve decided to spend a lot of effort making everyone feel confused at some ginned up new threat to open-source, which is not a threat to open source, not something that open source community hasn’t known about for decades, but just a problem for a bait-and-switch business model in which software gains traction trading on the cachet of open source and then rakes in monopoly rents that avoiding is one of the benefits to users of open source licensing.
They want users to see them like Postgres, but they want to milk users like Oracle. That’s the problem – a marketing problem for proprietary software vendors. The attempt to sell confusion is an attempt to conceal that that is all the problem is.
Dislike of VCs as much as the next guy, but is this a representative picture? Many companies I’ve seen have been genuinely interesting, like SurrealDB, CockroachDB and Hashicorp. Are you saying it’s all a long bait and switch game?
In some cases I wouldn't be surprised, in others sure maybe the founders did believe in open source at some point (there are definitely individuals who claim to have never changed their opinion, but their writings would suggest otherwise), but either they've left (voluntarily or not) or simply they gave away control to others who are only in it to make money.
As always, Chesterton's fence applies: all of the 10 points of the OSD were widely debated at the time (as was its predecessor, the Debian Free Software Guidelines), so it's worth explaining why the issues raised then no longer apply.
Right. It’s a public benefit org based in CA. I very much appreciate what they do, but I don’t think they own or should own the term. In either case, it’s a moot point because it’s just a term definition. The important thing is to find a good model that promotes the same or very similar benefits we get from traditional OSS but in an evolving world.
> Define "fix". By definition you cannot have an open source licence which says "cannot be used for bezos yacht"
FOSS acceptance is a grey area. Something has been tried with the AGPL, which is FOSS, however, it has been deemed not to provide adequate protection by companies creating similar products (while, ironically, being considered poisonous by companies using them), so the SSPL was created, but it hasn't been accepted as FOSS license because its intent was unclearly defined (http://lists.opensource.org/pipermail/license-review_lists.o...).
I think you'll find that the vast vast majority of us don't care about the whole "cannot be used for bezos yacht" problem when we contribute to free software.
I contribute with no expectation of monitory gain and absolutely zero desire for some random foundation or company that's part or almost always created later to make any money. If some contributors want to make money become consultants the "amazon problem" isn't a real one.
I love when Amazon or Google or whoever starts working with a project I'm touching it means it will normally get high quality contributions.
OP's "cannot be used for bezos yacht" problem is about discriminatory licenses. If you don't care that eg Amazon can use your software, there is nothing at odds with what OP sees as a problem (discrimiatory licenses that violate points 5 or 6 of the OSD[0]).
I work a normal job.... Open source is a couple of hours a week at most. It's a hobby for me some months I do nothing other I crush bugs like it was my job.
The problem is that big OSS database projects have teams of paid developers working on them and they want to make their money back. You can do this by offering paid support or a hosted offering. Having someone like Amazon take your product and build their own hosted version really cuts into that revenue.
Now, Redis was AFAIK pretty much just written by antirez and maybe it could have stayed that way, but even exceptional individuals clearly want to move on eventually and you'll likely need a team of maintainers. Distributed data products are complex and need people who contribute more than nights and weekends.
The best open source software is developed by unpaid people. Even the ones with companies around them, the best work is done in the first phase when everyone is still unpaid.
The "cuts into their revenues" part usually mostly affects their ability to keep developing the non open source parts anyway, their SaaS dashboard, their billing, etc.
Take redis, you could never change it again and it's fine. There's no need to support anyone, it's complete software that stands on its own.
> Source available is good, better than proprietary
“Source available” is a subcategory of proprietary, not “better than proprietary”.
> But my edgy take is that most people don’t really care about deep ideology
I think most people that orefer open source to proprietary software either care about the business benefits open-source provides over proprietary (including source-available) software or have an ideological affinity for Free Software, occasionally both.
The problem is that in the minds of FOSS people, you might as well try to argue that you want more proprietary software.
The "major platform hijacks our code for the web" is a valid concern, but the FOSS people have always kinda gone "well fuck you for having these concerns". That's... I guess fine enough when the majority of FOSS wasn't part of a SaaS stack, but now that the majority of big name libraries and tools are, it's becoming clearer and clearer that the OSD is just too lacking for those concerns.
To be clear, this isn't a defense of SSPL or similar anti-Bezos licenses (the best one I've seen is the BSL, which transforms into a traditional OSS license after X years if you want my opinion), moreso an observation that there's a clear need here that can't be met by OSD. Paying developers on top of the FOSS model is hard; doing support favors entrenched suppliers because of the CYA problem (this is why AWS has the advantage they do) and I'm pretty sure that even if you do the support model, it usually just doesn't pan out.
The main reason 90% of these licenses suck is far moreso because lawyers will draft contracts and licenses in such a way for you that they'll always give you the advantage. The SSPL being borderline impossible to comply with is by design for example.
I'm much more sympathetic to a company that starts out with this kind of license than one who changes the license after accepting contributions under a more permissive license, which is basically a bait and switch on those developers. It's even worse when the company previously promised not to do such a thing, as is the case with redis. And this is especially bad because the company that is now called Redis didn't even create the database, they took over an existing project.
I’m usually pretty ambivalent when a company decides to move to a license like BUSL. Sure it’s not “free” - but practically it only affects the likes of AWS from freeloading while making extraordinary profits. Especially true when a given company started the project. I understand why some hold strong feelings on the principles of OSS. My perspective is we’ll have fewer nice things if we allow the likes of AWS to cannibalise successful services.
But I feel no such sympathy for Redis nee Labs. It was never their project. They took over stewardship and then effectively stole the project for themselves. They’re not even the dominant contributor to the core product.
Seems similar to what Elastic did few years ago [1]. I kinda understand their motivation. It's not theirs originally, but they had antirez working on it for 5 years as their employee. They are making some contributions [2], I wish GH had a way to see such an insight by company affiliation. On the other hand, AWS and likes can easily fork pre-license-change version and spin it into its own product. However, I am fairly certain that AWS Elasticache is already such a thing – their own fork that diverged enough from the upstream and they are not eager to share.
So I view it as every major cloud provider with redis offering has its own fork. Except that Redis Labs also owns the original name. But it can go on as a stand alone project, like MariDB was spawn off after MySQL acquisition by Oracle.
AWS did not launch their own spinoff alone, but instead joined the Valkey project by the Linux Foundation[0], alongside many other major contributors:
> Industry participants, including Amazon Web Services (AWS), Google Cloud, Oracle, Ericsson, and Snap Inc. are supporting Valkey. They are focused on making contributions that support the long-term health and viability of the project so that everyone can benefit from it.
Seems like a good alternative to a single company's spinoff: Many major providers working on this same project should result in everyone benefiting from it.
I agree with your points min general but want to share my experience and maybe some counterpoint.
Being a customer of the redis labs' hosted solution, we noticed several issues:
- RLs solution is way more cost effective than AWS's
- RLs solution is not even close to elasticache in its ability to scale
- when issues occur the organization internally moves incredibly slowly so simple issues can turn into prolonged outages
Moving to this licensing model will make it possible for them to better invest in these things. That said, given the quality of their offering and lack of investment in the actual redis platform, why would anyone continue to use redis after the license change? The cloud providers can fork off their own version and never look back!
I think they're shooting themselves in the foot here.
I'm pretty sure ElastiCache has been around longer than Redis Labs too, so it's not like AWS undercut them, plus RL got a ton of free market research from it
In this case that’s true and why I said I don’t think it applies here. Typically it does though.
Open source services are in a weird spot. They spend tonnes of money developing it and big providers are able to cannibalise as soon as something becomes popular at very little cost to themselves.
I think we do need something between fully free and fully closed where cloud providers pay some kind of licensing. It’s a problem worth solving.
Do we need to "FIX" opensource? I am being serious here. It seems like people aren't getting it. Open Source is about openess and the ability to modify. Yes, people can lose money to cloud provider hosting but why does an Open Source project need to make a lot of money?
I say alot because its not like they can't still make money. They can still consult, they can still offer support or hosting but because theyre not making millions they want a "new" license.
Its stupid. you solve the itch then your done unless your doing maintance. people making open source software like paid software, constantly adding new features and changing things to justify their existance. You dont need millions in devs if your just solving a core problem.
I wonder if software really deserves its own economics.
If you haven't read Hal Varian's Information Rules, I highly recommend it. Check the publication date, then read it anyway, then reflect on the publication date when you're done. I found it very worthwhile.
Yes, this is a great read. After that many years it still influences me. However it is not that kind of book you read before going to bed. It requires intense studies to take something out of it.
Such a business model exists and it's extremely well proven, and it powers the majority of major open source software: build a proprietary product or service, and open source any component that is more of a cost than it is a unique selling point of your system.
Do you need a faster compiler, or a better OS, or some cluster operator just to get your widget factory working? Don't build those in house, instead find others with the same problems and create an open source project together to work on them.
But don't try to sell open source software. It's essentially impossible to do that, it has been tried time and time again and success is rare, and huge success is basically unheard of (RedHat being probably the one single exception).
> Such a business model exists and it's extremely well proven, and it powers the majority of major open source software: build a proprietary product or service, and open source any component that is more of a cost than it is a unique selling point of your system.
Sure, it is the commoditize your complement strategy [0]. But that doesn't help get complex open source products to market, it only helps with tooling.
Maybe you are right and there's no way to directly pair the freedoms of OSS with the capitalism of VC backed startup.
Maybe we instead need a model where FOSS is not about profits for anybody, and is just a passion of love, from a large community of amateurs doing it for the technology and fun.
Projects could still be funded by community users, but "venture funding"? That's how projects turn to shit.
I agree, but what I think is curious about the whole situation is that you can also see it strictly as a market failure.
It's a very pure example where parties in competition each that have a use for some kind of software can shortsightedly develop their own versions of it in-house, but that duplicates a lot of effort. They'd be better off getting together with their competitors and collaborating on a shared version that suits their needs, avoiding duplicating effort and all benefiting from each others' contributions. They could do this by direct collaboration or by funding an independent organization that fulfills their needs.
Sure, this can go badly if there's a large difference in scale between the different parties and some can muscle others around. But it and similar models do work out at the scale of the Linux Foundation, Khronos, down to Mastodon, GitLab, Blender, Krita, Forgejo, even arguanly projects like Bitcoin Core.
There isn't the structures to facilitate this kind of regime shift. But there should be.
In such a world most of the open source software you’re used to wouldn’t exist (or would be much less complete) and you’d be forced to work with and use proprietary systems most of the time.
>In such a world most of the open source software you’re used to wouldn’t exist
As part of that world, I also want livable wages and work-life balance for developers, so they can work on their passion FOSS off-call. And for students and programming enthusiasts to be more passionate about FOSS. Like in the 90s before the corporates took over FOSS.
If some FOSS still wouldn't exist then, I'm fine with that.
Developers need a salary to pay the bills. Let's say that covers the first 40 hours of the week.
Those who are searching for significance outside their day job offer free labor as their "hobby". Maybe 10 hours a week?
For projects that want to move forward with some velocity it makes sense to make some of that development into paid day-jobs.
As projects get very large, there's a fair amount of overhead in just "keeping up". That erodes the 10 hours quickly. Further reducing the time to contribute.
So where is all this cash to pay employees coming from? Certainly not end users (as anyone who's tried funding an OSS project from users knows.) No, it comes from commercial companies (MS, Amazon et al) or venture capital.
This is the cognitive dissonance that underpins OSS development. The very people OSS treat as the "enemy" are the people funding OSS in the first place. As much as say RMS rails against big tech, Linux and the rich Linux economy system only exist at the level they do -because- of big tech.
Of course, I painting with a broad brush, and there are exceptions, but the point remains. It's turtles all the way down, and those turtles are not funded by users.
Those turtles didn't need to use funding pre-doc-com-boom, they were passion projects and people with time devoted to the "cause" of FOSS.
>This is the cognitive dissonance that underpins OSS development. The very people OSS treat as the "enemy" are the people funding OSS in the first place. As much as say RMS rails against big tech, Linux and the rich Linux economy system only exist at the level they do -because- of big tech
Perhaps that's the problem: that they exist "at the level they do", meaning most of it is corporate focused, and not enthusiast and user focused.
Even ourselves, as devs, evaluate FOSS as to whether it's "useful" for our corporate/startup needs. This wasn't exactly the case, or at least not the main case for a FOSS project.
Gnome, for example, wasn't created to give RH and co a desktop shell for corporate installs...
The ‘cause’ of oss? I doubt many people ever were dedicated to a cause outside of GNU diehards. For most other people it was about curiosity or fun, a hobby etc.
>> Those turtles didn't need to use funding pre-doc-com-boom, they were passion projects and people with time devoted to the "cause" of FOSS.
Except they kinda did. The foundations of FSF are born by academics working at institutions, getting paid salaries. The were devoting time certainly, and certainly in the case of RMS with passion and cause, but that work was definitely funded - usually by the university.
>> Perhaps that's the problem: that they exist "at the level they do", meaning most of it is corporate focused, and not enthusiast and user focused.
I think we can drop the term "enthusiast". It implies tiny niche group with little practical value. I'm thinking of classic car "enthusiasts" who spend all their time under the car, and precious little driving it.
So let's talk about users. Users want full-featured reliable software. I would suggest all software, if successful, is user focused. (To he honest, I'm not sure what you have in mind with "corporate focused".) Firefox, to pick one project at random will seemingly live or die based on the individual user experience.
Equally take databases - there are s plethora of options to suit every use case. Need big powerful fast enterprise scale - Postgres is for you. Need small footprint with easy install - try Firebird. And a gazillion others. Surely such quality is a good thing?
>> Gnome, for example, wasn't created to give RH and co a desktop shell for corporate installs...
Um. Sure it was. It was designed to offer a gui desktop on top of Linux. Who did they think would use it if not Linux distributions? Given that for decades "the year of Linux on the desktop" was a meme, I'm not sure it's fair to claim that distributions using Gnome to create desktops for business users was a surprise.
The historically 'good' open source companies like Sun got bought but the ones that weren't like Oracle. The selling support model alone does not seem evolutionarily fit for the market.
Now we have these VC-backed 'open source' companies that have a playbook wherein they appear open source at first. But when you dig deeper, you find that the heart of the thing is a closed binary.
The investors are going to want to be paid back somehow. And the business model of VC means that one of two things happens:
1. The company finds a way to 100x the return. Which, if you're a customer, might be a scary prospect.
2. The company makes an amount somewhat lower and, while it would be a good business for a non-VC company, they're considered a zombie by their investors. So, they are killed leaving you as a customer in a bad position.
I therefore trust non-VC backed companies substantially more to keep alignment with their customers long-term.
A workable model could be for instead companies that have legally-enforceable promise not to enshitify their closed sourced product. So that the product will always be aligned with the paying customer. The customer cannot be made the product at a future date.
Sun was mainly a hardware business; you bought their workstations and servers. And oh, they also had this unix-y thing that came with that. Later software did become a bit more important with Java and MySQL and all of that, but it was still primarily hardware company.
I think it's pointless to even compare it to the Redis company; just about everything is different.
You go homeless so Bezos can make his yacht a foot longer.
I find it amazing how much money is being spent to ensure open source code doesn't end up in the hands of users and how many people are blaming the ones trying to increase user freedom.
Their definition of "fair, reasonable, and nondiscriminatory terms" seems... incredibly vague, and with a big chicken-and-egg problem for the first license.
> If the licensor advertises license terms and a pricing structure for generally available commercial licenses, the licensor proposes license terms and a price as advertised, and a customer not affiliated with the licensor has bought a commercial license for the software on substantially equivalent terms in the past year, the proposal is fair, reasonable, and nondiscriminatory.
My thesis is that when you don't have the pressure of VC funding (gotta hit the revenue numbers you promise to investors sooner or later), alignment between the business and the OSS community isn't as tough to find.
I'd agree with that. Your message sounded to me like you thought VC funding was desirable for software projects. I wonder why we can't just fund software like a regular business- why look for venture returns?
That works great! I think the best money to get to run a business comes from customers. Bootstrapping is great.
However, just like fewer homes would be owned if you didn't have mortgages, less software companies would exist without VC. It's basically a subsidy from the rich, endowments and pensions, to the rest of us (consumers because we get stuff for free, developers because it increases the demand and thus salaries for us).
I think VC is a net benefit to the world in terms of software delivered and companies built. I think OSS is a net benefit to the world because of the explosion of possible ideas and the leverage it lets developers have as they build on it.
I would love to see these two huge innovations in building software work together well. Haven't seen it yet, hence my original comment.
This is very good use case of micro-transactions. If AWS makes $100 off Redis, they should be pay back X% to Redis project, from which the money is distributed to contributors based on how important their contributions were. Also Redis project is also supposed to pay back to the software components and 3rd party libraries it uses, so C project gets a fair share of the pie contributed back to them as well.
To me Redis has always seemed like a Trojan Horse for developers. The first impression is its this simple key-value database, so easy to use. Oh wait... it's also a cache, nice! Let's cache all the things too! And look... all the cool kids are are using it too, so it must be cool, meanwhile the old Unix mantra of make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features. ( http://www.catb.org/~esr/writings/taoup/html/ch01s06.html ). Fast forward 10 years and you need to download it's Enterprise Whitepaper ( https://redis.com/solutions/use-cases/caching/ ) to make the right caching decisions.
Where this is coming from is having worked on a project where Redis was being used as a database and a cache, on different ports. And of course most of the dev team hadn't read the the manual because Redis "is simple and just works". And of course someone forgot to actually configure the Redis instance that was supposed to be a cache to actually _be_ a cache. And someone else thought the instance that was supposed to be a cache but wasn't was actually a database. And yet another had used TTL caching to solve all their performance issues. And pretty soon mystery bugs start showing up but sadly no one can actually REASON about what the whole thing is doing any more, but there's no time to actually clean up the mess because it's a startup struggling to stay afloat.
And I remember asking "why didn't you memcached for caching?" and the response was "Dude! No one is using memcached any more". So the technical decision for Redis was based on "what's cool right now".
Anyway... I feel a bigger rant brewing so I'll stop here.
I think it's rather features were added to Redis out of the experience and craft, not just to "lure future users into a pit", I doubt antirez would have that in mind.
But I think you described right the social behaviors of certain/common types of users.
Nothing wrong with Memcached but at high loads weird issues will crop up with it too and if you don't have an understanding of how slabs work in Memcached (I doubt your average dev does) you are going to have a hard time reasoning with it as well. Eventually someone will say "why didn't you just use redis for caching?".
Whoaaaa I’d love some details on this reaction, do you have any stories or anecdotes to share? I have to say I’ve never hit its limits so I’ve never lost trust in it
We got hit by [0] and so had to pin to an older version (we didn't raise the issue).
Also, just look at the amount of open bugs and their age [1]
They also recommend using swap for some reason, however if your memory usage reaches the point where swap is being used the performance is so bad that the machine may as well be dead.
It's been nothing but trouble, which is a shame because the changes they've done to redis have crossed my mind too.
We'll probably move to Scylla.
Whoa, very biased article (especially for LWN). Only cites media coverage; no links supporting that Amazon, MSFT, Google, etc. were in fact EEE’ing (or at best, behaving unethically) with each of these projects.
It even suggests cloud providers did contribute, and uses bad data (git commits “by employer” w/o dataset) that basically contradicts their argument.
I may be biased, as I saw Amazon doing exactly what this article claims “maybe they weren’t”. But statements like this seem intentionally misleading, and easily disproven:
“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.”
MongoDB is still “source-available”, and on the same GitHub repo I’ve used since 2010. The SSPL only impacts cloud-providers, and has exceptions for cloud providers who release their source code.
The OSI doesn’t get to define open-source. Neither do I, but at least I was part of the community for ~20 years…
It impacts all people who manages mongodb for somebody else, which is a lot of hosting providers (many of which probably do not care about the licence and are too small to get caught)
From you people who know a lot about Redis, help me out here: For my Web site code (for my startup), I needed a key-value store. Soooo, it looks like I could use Redis for that.
But instead, wrote a little code using two instances of a Microsoft .NET collection class. Simple code. Plenty fast. Welcome programming exercise using .NET classes. Cheap -- no ongoing charges and no chance of charges in the future. And, no concerns about what might happen from politics, business, some remote service, etc.
Question: What am I missing by using my little DIY (do it yourself, roll your own) solution and avoiding Redis, work of other people, or a service from Amazon Web Services, etc.????
It's thread safe so that if my startup is more successful than I'm assuming then I'll be free to do less on how to exploit parallelism from several servers. As it is, the code I wrote serialized access to the key-value store I wrote. Sooo, that could be a performance bottleneck.
I should review network address translation (NAT) and affinity of one user to some one server, instance of Microsoft's IIS (Internet information server), thread of execution, etc.
Thanks! LTS and Kestrel are new to me! Just did a first Google search on them. Thanks!
I'm the self-funded, sole/solo founder. So, I pay attention to the business, e.g., getting and pleasing the users, and also the computing. If successful, then getting paid for running ads, accounting, taxes, lawyers, floor space, employees, etc.
So, for now, concentrating on
pleasing the users.
Part of that is some
original applied math.
Users won't be aware of
any math, but the math
should be secret sauce
and an unfair advantage.
So, am also concentrating
on applying the math.
For the software, trying to
keep that simple.
Had a disaster, but before that
had the Web site running:
Mid tower case ($40 with a
$20 rebate), $65 motherboard,
8 core AMD processor
with a 4.0 GHz standard clock
($100 at Amazon),
Windows 7 Professional,
some 4.x version of .NET, IIS,
ASP.NET, ADO.NET. As I understand it, .NET CORE came later and is more restrictive.
My project is only for a Web site; users will get to the site only via the Internet and a standard Web browser. E.g., I'm making no use of anything mobile. So, the project has no mobile app.
Am highly motivated (1) to stay with just Windows, soon Windows Server,
and (2) to keep down, to zero, the investment of time to program on Linux, IoS, Android, etc. -- hope never to write any code for any of them. That is, I can get paid only from revenue from the business; while I have to write the code, and it's fun to do, that's all a business expense; I can't get paid for writing code. I'm assuming that Microsoft and Windows have a foundation plenty sufficient for my business objectives.
I have yet to move to a later version of .NET: Okay, I should, but, still, not looking forward to the effort.
To me, the 4.x version of .NET I used looked fine. For another outrage, I wrote in the .NET version of VB (Visual Basic) and wrote no C, C++, or C#. I really like VB.NET, regard it as a nicely designed, implemented, documented language with plenty of features for what I need.
For what I wrote, the UI (user interface)
is simple and traditional --
billions of people will understand it
at zero effort, immediately. There is a huge range, world, universe of Web page design features I didn't use.
The timings I did show that the site is astoundingly fast, fast enough that if can keep the computing on average 50% busy 24/7, then standard ad rates will generate some gratifying revenue.
An 8 core processor with a 4.0 GHz clock is no toy, is a lot of computing.
Recently heard about Amazon and their AWS
(Amazon Web Services) wanting
the TLS (Transport Layer Security) version 1.2. Soooo, I checked, saw that
I was using version 1.1, that 1.2 was available, so picked 1.2.
What I'm doing now is dirt simple:
Have 1000+ Web pages of Windows and .NET
documentation, so wrote just ~300 lines of Rexx code to extract the page titles from the HTML tags
<title> ... </title>
and make a TOC (table of contents) I can read into my favorite editor KEDIT and search -- then one keystroke to KEDIT will have Firefox display the Web page.
Want to do some more system
management, get the site running
again, do some revisions,
do some marketing, and go live.
In short, my CEO-business hat has me think, for the foundation of .NET, it's good on features, is now old and likely quite reliable for the old features I will use, and seems plenty fast -- soooo, I know, I should be ashamed, that's good enough!
Almost everything you wrote is factually wrong, but I'm not prepared to write an A4 equivalent length rebuttal. It seems you have not been even tangentially keeping track of any developments after... 2015.
> It seems you have not been even
tangentially keeping track of any
developments after... 2015.
You are attacking me personally or the
content of my writing?
For your date 2015: A key to my Web site
is some math, and it is original with me,
from my research, and, thus, fully up to
date! Uh, I'm able to do such math partly
because I hold a Ph.D. in applied math
from a world famous university; for more,
I've published peer-reviewed papers in
applied math, saved FedEx with some
applied math for the BoD, taught applied
math in some famous universities, both
graduate and undergraduate, and, oh yes,
published peer reviewed original research
in artificial intelligence. Also taught
computer science at Georgetown University.
There was a LOT going on in the Internet
and the Web, HTML, SQL, etc. long before
your 2015: Gee, there was a nice
introduction to developing Web sites in
Jim Buyens, 'Web Database Development,
Step by Step: .NET Edition', ISBN
0-7356-1637-X, Microsoft Press, Redmond,
Washington, 2002.
Yup, that's 2002, long before your 2015!
That book is an example of excellent
technical writing. There are 15 chapters
with nice introductions to each of VB.NET,
ASP.NET, ADO.NET, database and SQL, one
chapter for each, plus more -- all from
2002!
The book does not emphasize how to use
JavaScript to make Web pages that jump
around for no good reason, make users
angry and leave, and hurt the ad revenue.
Net, in simple terms, what is new and
important about my work is my original
math; nearly all the rest of the tools
used and features implemented goes back to
the last century.
For some irony, and also a good lesson,
consider Hacker News and its functionality
and user interface, both that go back
largely or entirely to the last century.
Uh, for "developments" since your 2015,
for the back end, that has my original
math which is fully up to date, and for
the front end, i.e., the user interface,
in general, in simple terms, for my Web
pages, each new technique would be
something more users don't understand and
that, thus, might hurt the success of the
site.
Let's see, since your 2015:
Pizza is really OLD, and Pizza Hut is
worth $38 billion.
Hamburgers are really OLD, and McDonald's
is worth $193 billion. Burger King, $34
billion.
My 1986 Chevy S-10 Blazer had good
electronic fuel injection, no other digital
electronics, and standard sealed beam
headlights which for me made it as up to
date as I want -- for anything since
then, for me it's useless or annoying,
more to buy, and more to maintain so I
don't want it.
No, no, not at all: I admit, accept that no doubt Redis has a lot more functionality than the few pages of code I wrote.
My question was: My code looks like it will do what I need done, but maybe I'm missing something, i.e., maybe Redis has some features that very likely I should have?
If want to expand the question to other people, what is the chance that usually Redis is overkill, more functionality, code, complexity, considerations, ..., than needed? I don't know so am asking.
Or, I had a 2 wheel drive car, but did I miss a lot not having a 4 wheel drive car that I nearly always used in only two wheel drive?
You may need data persistence (keep the data live while you restart your process), cross-instance coherencies could be nice too, automatic data expiration too.
Thanks. My project had an interruption, and I'm getting back to the code.
My code that needs a key-value store is simple, short, just uses two instances of a .NET collection class.
I need NAT (network address translation) to keep affinity of each user with their one execution instance of my code, but I suspect that is automatic with Microsoft's IIS (Iinternet Information Server) that the code uses.
For persistence, the code needs that only long enough for each user connection. And for performance, I don't need sharding across several servers acting like a cluster -- maybe that is some of what Redis supports.
It appears that .NET has more functionality and performance potential (user connections per minute) than my project needs, so I'm trying not to try to master everything Google, Facebook, Amazon, a big bank, Walmart, etc. might need! So far, I'm pleased with .NET.
So we as developers don’t have to scramble to replace redis in our SAAS apps and web based software.
This is more about preventing AWS from eating their lunch by providing redis-as-a-service, without paying any sort of compensation to the redis developers.
Redis’ blog post: https://redis.com/blog/redis-adopts-dual-source-available-li...
I feel like there’s an argument that these kind of licensing terms are almost beneficial to ‘big cloud’ because the cost/effort of all of these arrangements might dissuade smaller companies from trying to compete in the hosting and managed-services business.
Meaning that Microsoft is "paying to play" with Redis Ltd... while I have not seen any announcements from AWS or GCP.
Microsoft would never just announce something like this on a whim.
Both the internet and open-source enable alternative employment and funding models that up until now might have not have been sufficiently explored.
Sounds like that's basically what happened here, too, except not with Google. I'm not sure why.
Again, it's chump change, these companies drop that kinda money all the time in aquihires..
It sounds like a very bad deal for the likes of Amazon et al. The likes of Amazon offer Redis alongside memcache just because cloud adopters might want to use a memory cache service,but there is no value in buying trademarks for it.
I mean, just take a quick look how Amazon offers managed RDBMS, and how the specific DB is just an afterthought behind a compatible interface.
People seem to think that just because some company has cash that they should mindlessly spend it on things that add absolutely no value.
Plus some great projects don’t even get (monetary) contributions from large corporations. I think because it could weaken their legal position.
Redis is great as an off-the shelf component, but it's not exactly rocket science to re-implement for a big corporation. So redis doesn't really have any leverage in my opinion.
Then their cloud-specific solutions are the up-sell (and lock-in).
I don't think so. The only thing they need to let their customers know is that they offer a memory cache service that is compatible with this or that interface. Whether it's Redis, memcache, Garnet, or whatever it might be, it matters nothing at all. All they need to do is ensure clients can consume their service, and that is it.
This whole thing sounds like a desperate cash grab that fails to argue any point on why it's in anyone's best interests to spend small fortunes on nothing at all.
Which is why Microsoft's new drop-in replacement works with all those things. It could gain traction - who knows.
I suspect in the long run, Amazon will eventually "pay" the licensing fee for customers that demand "Redis". But they will push everyone else towards their in-house fork of Redis that they brand MemoryDB or whatever. You will pay more for the Redis licensed version and AWS will steer you away from it, but it will be there if you are adamant.
This is already happening with Aurora, which has Postgres and Mysql compatible versions. If your company is big enough for special pricing, then you know they want you on Aurora. The pricing discounts for Aurora are insane (50%+) compared to what you might get on a traditional Postgres of equivalent size (20%). They will probably do this with MemoryDB and Redis eventually. Redis is available if you really need it. But this other thing that they maintain is discountable to half the cost of the other one and it becomes a pretty obvious choice.
It’s a community effort and this is just as rude to the community that built it as they are claiming SaaS vendors are being to them by not “giving back”.
This idea that you are owed reciprocity for publishing free software is about as logically sound as expecting compensation from someone when you give them a gift.
Ironically this happened because the community was using the BSD license instead of the GPL, when the former allows someone to fork the code under a different license.
If the big cloud providers wanted to stick it to them, they would create their own fork of the code under the GPL and make substantial contributions to it so that one becomes the main one.
(I don’t know enough to be in either camp.)
When authors pick a license, it's a serious act. It's not a joke like hey I pick BSD but mind you, I don't really want you to follow the terms! Make sure to don't fork or change license. LOL. A couple of years ago somebody forked Redis and then sold it during some kind of acquisition. The license makes it possible, and nobody complained. Now Redis Inc. changes license, and other parties fork the code to develop it in a different context. Both things are OK with the license, so both things can be done.
A different thing is what one believes to be correct or not for the future of some software. That is, if I was still in charge, would I change license? But that's an impossible game to play, I'm away from the company for four years and I'm not facing the current issues with AWS impossible-to-compete-with scenario. I don't know and I don't care, it does not make sense to do such guesswork. What I know for sure is that licensing is a spectrum. I release code under the MIT or BSD, but that's just me. I understand other choices as well. What I don't understand is making the future of open source in the hands of what OSI says it's correct and wrong. Read the terms of the license, and understand if you are fine with them.
This is a false equivalency. No one is defining "creator" as "wrote all of the thing". When describing a project/product as a whole, there's a clear, massive difference between "creator" and "contributor".
Let's say you get a small patch merged into the Linux kernel, would you then call yourself "one of the creators of Linux"? The vast majority of people would not find this remotely acceptable!
How about proprietary software and employment arrangements. Let's say a Microsoft intern gets a few lines of code merged into SQL Server. Would you call them "one of the creators of SQL Server"?
Extending this logic to other words, would you say a company with N employees actually has N founders? No, because these words mean different things.
But if you think AWS would have any shred of ethics when it comes to a topic like this, you’re much more optimistic than I am.
Basically Redis Inc is the one making the fork, which retains the Redis name since they purchased it from antirez.
Doesn't AWS employ Madelyn Olson? I mean, AWS have paid for Redis development.
Not exactly a leech.
But they wont be able to leech Redis's future contributions. Knowing AWS they'll most likely create a fork to continue raking in most of the profits in the short-term.
> Yep still the biggest leachers
Redis was literally licensed for people to do whatever they want. That's not leeching.
So whilst their previous license allowed AWS to leech off them, it's now been relicensed to prevent them from profiting off their future investments without compensating anything back.
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.
We’ll see what happens though. If redis Inc (that never created redis) wins over AWS, GCP and others (who also never created redis). Both contributed to its maintenance, as GitHub clearly shows. We’ll see which fork wins out.
I've called AWS's hiring of a single developer a token hire that they then go on to write flowery PR posts about to camouflage their predatory relationship with OSS vendors.
For concrete numbers they contributed 165/12111 commits for a total of a 1.36% of the commits.
Whilst that qualifies as a valuable contribution to any project, it's also dwarfed by the 350M investment in Redis Labs and doesn't absolve AWS from being a called a "leacher" by helping themselves to the majority of the profits whilst contributing relatively nothing back.
It’s funny that you would use commits to quantify investment from AWS, but you’d use $ to buy shares in future profits to quantify investment from redis labs. Why not use the same yardstick for both?
Either way, it doesn’t matter. Not one bit. Everyone who put in effort into redis did it knowing the license. There’s nothing wrong in relicensing future commits. There’s nothing wrong with forking. There’s nothing wrong in using whichever fork works better for you.
You’re insisting up and down that AWS and others were leeching because they didn’t own the copyright to redis. I’ve never heard this interpretation of OSS before, but sure maybe you’re right. But we’ll see which fork comes out on top a year from now.
If you don't want others to monetize your work, don't license it under a license permitting them exactly that.
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.
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 !
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.
Yes, but there’s another explanation. Repeating the same mistake countless times and expecting a different outcome is naivety.
I suppose I’m not understanding the point of your position. Software authors cannot fix a licensing mistake by changing the past, but they can use a different license moving forwards.
Code contributions from amazon would've been leeched by other parties using redis as well - something which amazon is accepting (and probably encouraging).
It's lose/lose!
The "Free for all except mega cloud corps" license changes are to disrupt this status quo which currently sees the mega cloud corps with impenetrable moats from capturing most of the value of OSS products others spend their resources into building, AWS are then able to use their war chest profits to out resource, and out compete them, using their own code-bases against them.
It's unfortunate organizations need to resort to relicensing stop this predatory behavior, but its clear in AWSs 20+ year history they're not going to change their behavior on their own.
Some projects require signing copyright transfer before making commits (legal document claiming that you are a) copyright holder and b) you transfer those rights to them ie CLA [0]) so single entity holds whole copyrights.
They usually have a GHA that checks it when proposing PRs.
It doesn't look like redis has any of this.
So they run RedisLabs purely on trademark + admin rights on GH on redis/redis.
If that's the case then they also cannot legally change licence of code that's already there because they're not sole copyright holders of that code.
ps. as a side note that's why ie. SQLite doesn't allow external contributions at all, even though their code is Public Domain – because they can legally claim full copyright/authorship.
[0] https://en.wikipedia.org/wiki/Contributor_License_Agreement
Public domain isn't the only form of free software. You can literally use it in exactly the same way as you did before. Nothing has been taken away from you.
Does this address your concern?
One of the well known flaws of capitalism, in the 'bad, but everything else is worse' sense.
AWS employee Madelyn Olson was a committer on Redis since 2019. Since 2020, she was on the core team of maintainers.
> If you're looking for a primer on what is going on with Redis and why its license change matters, this is the article to read. As someone close to the situation, this is the best summary I've seen.
I like free money as much as the next guy, but VC isn’t it.
(And also I'd argue most of redis' value to users was already in place before the VC backed company got involved)
Where the value is or was is pure sophistry. You don't have a crystal ball, just like everyone else.
All this discussion is envious bellyaching from those that are probably leeches themselves. They just want the free gravy train running for themselves.
From my point of view managed databases only really make sense for toy projects, if you’re using these things at scale it’s much more economical to buy some servers and hire some people of your own, and use plain pre-VC Redis. But big corporations seem to have some kind of a fetish for lighting money on fire, and the fight here is fundamentally over in whose fireplace to do it.
it is more expensive to buy managed, but you offload work. I would imagine toy projects are more cash constrained, and makes more sense to rent cheap servers and roll your own.
On the other hand, larger scale projects would rather pay to offload the work of managing and scaling redis.
Large scale projects can take advantage of economies of scale and hire ops people. I’ve found cloud support pretty lacklustre compared to having someone to talk to face-to-face who understands the whole stack for your particular application.
Of course conventional corporate wisdom says waste as much as you like on services as long as you keep payroll down, that may be a bigger challenge than any of the technical ones.
Redis organization doesn't pay any sort of compensation to developers who contribute to redis source code. I do not see any difference here.
Are we really counting contribution based on LoC? Haven't we over the decades decided that isn't valid? Guess every person that makes this claim should once again have their performance based on LoC...
Some simple examples, I'm not saying this is the case though. What if most of Amazon's contributions are high impact contributions where most of Redis orgs are simply maintenance or feature pushes. What if the same is true for a 1% contributor?
By your own statement doesn't Tencent then have a larger claim to redis that Amazon or Redis does?
I think they didn't include the LoC in the article as anything other than a broad estimate of contributions, perhaps for lack of any better measurements.
If they contributed to 5% of the code, and the code is open-source, then yes?
But the developers licensed the software at no charge. What kind of compensation are they entitled to then?
Sounds like a case of sellers remorse/take-backsies one of the problems that open source was aiming to solve.
I wonder how many bellyachers here contributed to Redis vs. just leeched. (Not a rhetorical question.) How many are just in the peanut gallery (just like I).
If I put in a commit, what is redis going to pay me for executing my code?
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
Amazon, Google, MS, and all the rest easily have the talent and resources to create a Redis replacement with code that already exists. They'll do so because it is to their advantage to not charge for the license fees Redis now wants.
> Amazon, Google, MS, and all the rest easily have the talent and resources to create a Redis replacement with code that already exists.
And they most possibly will. Goodbye, and thank you for the fish!
I mean, they've already changed licensing for parts of the project twice in 6 years. I have zero faith that they won't pull a Vader and change the terms of the agreement again.
> continue to be supported and maintained (and improved!)
I'd guess that > 99% of any "improvements" Redis the company make, will affect < 1% of users.
As has been pointed out numerous times, it's essentially "done" in terms of functionality - but as a VC funded company they have to constantly do "something", so they'll keep adding niche upon niche features, giving the resume padders at other VC companies something sparkly and new to spend their budgets on.
Meanwhile 99% of people just need a fast key/value store, and maybe half of those need it to be distributed/replicated, and maybe a third need it to run some kind of scripting (Lua) to do "in-db" operations atomically.
With the addition of native TLS several years ago redis is, for 99% of users "functionally complete".
Sure, new TLS versions will come along and need support, kernel or library features they use will adapt or have improvements, etc, but I think you're vastly over estimating the amount of "improvements" to expect that will impact the vast, vast majority of users.
> preventing AWS from eating their lunch by providing redis-as-a-service, without paying any sort of compensation to the redis developers
Look I hate AWS more than most people would find reasonable, and even I'll admit they're not the "bad guys" in this scenario.
The project was released as BSD licensed, so AWS could if they wanted, fork it, and offer a service based on that, and make any fixes/improvements just in their service offering.
They didn't. They had paid staff contributing back to the redis project, for a number of years. This was literally the goldilocks project of the OSS world:
Numerous massive tech companies who all have the financial ability to simply run their own fork, and the legal right to do so (due to BSD-3), willingly contributing to the maintenance of the project.
As I've said before, the story of what's happened to Redis (and HashiCorp stuff) is likely to become a warning to the tech community in general: if an OSS project you rely on transfers control from it's founder(s) to a company, you probably need to consider continuing with a fork from the last open version, because apparently "(try to) monetise popular open source" is the newest way to win the douchebag villain award given to MBAs at VC funded companies.
Or, even simpler, if the project is not contributed to some open source foundation, and does not have copyleft license - it's a trap.
https://docs.keydb.dev/docs/cluster-tutorial/
I wished they'd release some of their "Pro" stuff and/or internal-only features.
If redis thinks you're making too much money using redis, they'll relicense it so you have to pay them to do whatever you are doing
You can find his contributor for both at:
* https://github.com/apache/kvrocks/graphs/contributors
* https://github.com/redis/redis/graphs/contributors
* 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)
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...
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.
The linked license file is moby's https://github.com/moby/moby/blob/master/LICENSE
I don't get it; does the new license prohibit it from being distributed thus, or is this a philosophical "need"?
> 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
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.
https://wiki.debian.org/Docker
Docker is dyeing on linux podman will be the only one that remains.
A related problem I've seen from other complaints made elsewhere is that podman does things just slightly different enough than Docker that it's not a true drop-in replacement.
We've seen that before; where distro maintainers declared software too dangerous/prematurely dead for a while. All it resulted in was community hosted repositories for the old software. (Read: this is why avconv failed.)
Red Hat at least had the muscle to force podman onto some people, but not everyone.
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.
Those are pretty standard kernel modules for enabling userspace networking, which if you were using podman in rootless mode you need (along with another userspace networking package, slirp4netns). "Drop in replacement" does not mean there's not configuration to get it set up, it means it has the same APIs as another system.
I've been using containers for almost 10 years and with almost no fanfare switched to podman 100% like a year ago. Just because you expected to have to do nothing at all doesn't mean it doesn't work.
Am sure you can get over the kernel module tun creation and other limitations by using something like --privileged but at that point, why not just use docker if you are going to run containers "insecurely".
And for the sake of this argument, drop-in replacement means I can take my tools and move them over to the alternative with little to no extra work needed on my part.
Because at least you can tell that it's insecure, rather than insecurity being the default?
Also the "secure" defaults don't matter much if you have to manually jump through hoops in sysctl and modprobe to get things to work. Infact I could even argue that this introduces the risk of having an insecure server by misconfiguration.
I could be convinced Docker-on-headless-servers has been dying a while but the desktop variants are alive and well
And besides, that issue with root feels overblown in the era of single-user systems and servers as cattle.
Uh. No.
https://andrewkelley.me/post/redis-renamed-to-redict.html
I am keenly looking on to see if the people involved in Redict see it the same way. As a user of Redis, I would like to switch to one of these open-source forks, and to be honest one which is "done" and focused on maintenance, bug fixes etc. rather than new features sounds more attractive.
And ftr, in my eyes, a project being created/initiated by ddevault is an asset, certainly not a liability.
He changed the license, moved the code, chosen the name and the direction all on his own without consulting anyone in the community.
His history had made me like that he forked it, but his actions and behavior towards the maintainers of Redis and absolute unwillingness to meet in the middle to collaborate really puts a hold on Redict being more than a fleeting thought.
Linux Foundation, core contributors to Redis and what seems to be the majority of the community is rallying around Valkey, so I don't see Redict going anywhere except in a niche subset of users.
The premise of Redict is to create a fork which is driven by a grassroots community rather than a commercial interest, and which is safe from this kind of rug-pull in the future and to press back against this broader trend of rug pulls by commercial vendors of free software. I invited collaborators from the start at every level, going out of my way not to instill Redict as a hostile takeover but as a community-led effort to create a future for Redis which is protected by copyleft. I talked with the people behind Valkey from the start of Redict and extended them a role in shaping everything from the direction and governance and infrastructure and tooling from day one, provided that we could find common ground on the license. Hell, @madolson, the primary force behind Valkey, signed up for a Codeberg account so that she could be made an admin on the Redict repository before placeholderkv even existed. She was removed only when it became clear that she was committed to her own fork and it didn't seem prudent to us to give admin rights to someone who wasn't contributing.
Redict was not refusing to collaborate or meet in the middle. The raison d'etre of Redict was to be a copyleft home for the Redis codebase, and if we could have found agreement on that then every other detail was always clearly indicated as subject to consensus and we proactively reached out to build that consensus, but were refused by madolson and the commercial interests that wanted to be in charge of their own fork rather than participate in a grassroots project.
Even the consensus they wanted on the license choice was, in the end, the consensus of the four commercial vendors. We tried to find a way of participating in this consensus-making process, but it wasn't made for us. Calls we made in public to use a copyleft license were met with resounding support on GitHub, to no avail.
Don't mistake four commercial vendors and the Linux Foundation for a community. I wish them the best of luck, and acknowledge that a corporate-led home for Redis is probably what some people are looking for. That said, I'm not okay with this narrative that Redict was not cooperating with the community, because it's just factually wrong and hurtful to boot.
I pity the fool(s).
The BSD license in particular seems like a particularly bad way to run a business.
But the switch from AGPL to SSPL didn't do either of those things.
AWS still built DocumentDB to compete with Mongodb, and didn't use any SSPL OR AGPL code in the implementation (at least according to their FAQ[1]). And AFAIK AWS isn't paying mongo any royalties.
[1]: https://aws.amazon.com/documentdb/faqs/
Well, yeah, its mostly a bad plan, because while it can block competition with your code, it doesn’t block substitution with other code that provides the same function, and if you aren’t one of the big cloud providers, competing in the same function market with bundled services from the big cloud providers, whether or not it is the same underlying code, is the actual problem you face when your monetization is based around “sell a hosted service”.
but at the same time, they want people to be able to use the software for free (esp. at the start), to kick-start the network effect.
In other words, open-core business models want to have their cake and eat it. If you are able to make lots of money off said software, we want a piece of it after the fact. But we dont want to take on the risk of actually looking to build a business and compete on the same.
There's nothing wrong with making money and being profitable. But they have to justify investments taken with greed. This license change is motivated by greed, not by "making money" fairly.
Would anyone have given mongo a look if it was a fully proprietary technology? They would have gone bust years ago.
Many large orgs just say no to viral licenses, and in choosing AGPL, you put blockers to adoption.
Open core releases some of the project under permissive license, and keeps some private or under a permissions license.
We are all still trying to figure out how we can have sustainable open source where people can be paid to work on it full time
Do you have suggestions for alternative funding/support models? What is open core being replaced by from your perspective?
Personally I prefer the Adam Jacob trademark business model but it's not that proven and it can't be retrofitted.
There is certainly a difference between AGPL and BUSL style licenses. One of the new projects I'm using as some of their code with a BUSL style, but still open core primarily
It's not a technical blocker, it's a psychological blocker
Maybe the problem lies more with overreaching and trying to cash out?
At the same time, founders take money to build their idea into something more than they could do with a small team. An big companies are risk averse, having a small staff or being susceptible to "hit by a bus" failure is often a deal breaker
GPL + CLA = bad. If you contribute to GPL Redis and transfer the copyright to your contributions to the Redis company, they can switch to whatever license they want.
SSPL + no CLA = interesting, I would love to see the Redis company open source their hosting stack because they are accepting external contributions.
Or plan to make money with other people's love and free-time.
Article doesn't mention it, but supposedly Microsoft uses novel algorithms and multi threading to achieve an order of magnitude improvement in throughput.
Now if they can commercialize it with Azure, it should be a credible alternative to Redis Enterprise hosting.
It’s a stack they are looking for but keep missing right under their nose.
I don't know if you were referring to the total install size of apps or to the licence or maybe just how annoying Mono was, but nowadays you can compile down to one binary, optionally with the runtime included. That makes it simpler for Linux sysadmins than Java or even Python, IMO.
It has nothing to do with the technical merits of the technology, but with suspicions of the intentions of the company behind it and a desire not to create a dependency on them.
It's an important disclaimer as someone might read this and go write another tool in Python + Tkinter (with terrible results).
See: https://github.com/microsoft/garnet
Isn't the point of CLAs that you can re-license contributors' contributions?
(That's not meant a gotcha, I just don't really know how this stuff works)
Either way you can see contributions to add more commands here: https://github.com/microsoft/garnet/pulls?q=is%3Apr+add+comm...
With that said, I'm slightly skeptical of/worried about Garnet but the reason is different - it received a bit too much hype soon after going public and I'm concerned it will be subject to corporate politics that often plague projects like that.
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:
https://github.com/opendistro-for-elasticsearch/sample-code/...
https://github.com/opensearch-project/OpenSearch-Dashboards/...
The superiority AWS was slinging when they "bravely" took the mantle looks terrible in retrospect
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.
Just use this pre-V1 public beta software I stumbled upon instead.
The narrative that opensearch is some kind of unsafe abandonware is clearly nonsense when you read the commit log: https://github.com/opensearch-project/OpenSearch/commits/mai...
All I can say is, sure, if you want elastic use elastic.
…but opensearch is fine. I use it and have no problem with it.
"It lacks so many improvements and advancements since the ancient version it was forked at"
to "opensearch is some kind of unsafe abandonware"?
Would love to learn the thought process here.
…but I mean, I’m not really up for playing the “pedantically correct about what he/she said” game with you.
Instead how about you comment on the point I’m actually making, which is:
opensearch is perfectly fine for most people.
For most people, there is no meaningful distinction between elastic and opensearch.
Opensearch is a healthy project which regularly receives updates and is widely used in production in large deployments.
If you have any meaningful or compelling argument why any of those three things is not true by all means, I’d love to hear about it.
> 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.
That was the comment I replied to. If you thought OpenSource was pre-V1 public beta software I'm not sure why you're even opining on this.
> 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.
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)
> Even basic things like autocompleting queries have been WIP for half a decade now.
It's an open-source project. If this bothered you for half a decade, you could always submit a patch.
Apparently it didn't bother enough other people that no one cared to send a patch.
1. I'm not using Mac-jail-OS
2. I'm not insane to even remotely consider the possibility of using Windows
So, yea, I'm using OpenSearch.
A CLA may impact relicencing, it depends on the terms. A simple CLA may only say "I am the owner of the code and I release it under $LICENSE". The current Redis CLA also has a copyright grant, which gives Redis the company greater rights.
And the problem with the trademark model is that AWS, and especially Microsoft, already have established brand recognition with the people who sign the big SaaS and support contracts. The people who know what a Redis is are just nerds with no money, the real big shots do everything in Microsoft Excel.
https://www.fsf.org/bulletin/2022/fall/copyright-assignment-...
The company now known as Redis did not invent Redis, it started as a company trying to make money hosting other peoples' work. After it finally hired the creator of Redis, it specifically promised not to do what it has just done (move away from three-clause BSD as the license for Redis core) at least twice.
In the development cycle from 7.0.0 until a few days ago, Redis isn't even the majority contributor to the codebase. The largest single contributor is from Tencent. (All of this is in the article.)
If Redis had been doing all the development, had not promised it wouldn't move away from the license, then I might agree that people have little to complain about.
But this situation isn't as you've suggested here where a community is all about "take, take, take" from a company that's been doing all the work. The company was founded on the idea of trying to do what it now complains about Amazon doing, and their claims that cloud companies do not contribute is clearly false -- just look at the code contributions.
I don’t typically ask people to RTFA because that’s against the rules, but you would have known all of the above if you bothered to read the article.
It’s like complaining that there are too many implementations on GitHub of the same thing.
You're spot on. People are bellyaching that the world doesn't operate according to their arbitrary rules.
Perhaps I'd be happier in a geocentric universe, but it doesn't make a non-geocentric universe bad per se.
At the same time big corps use it as carte blanche to basically pirate software in a legal way, while following the letter of the licence.
Going back to the open core/demo versions (aka Shareware/Public Domain/Trials) is the only sustainable way to make a living.
aka, just sell software, rather than make it open source.
What is being balked at is the idea that you can use open-source as a foot-in-the-door marketing and growth hack, which you then reap after some level of popularity/network effect is reached. Some call it bait and switch.
Blaming big corps for "leeching" is just self-serving. They are doing exactly what the license allows them to do - a license for which was chosen at the start to allow for it! If you expected to be paid to make this software, don't opensource it.
The community has been doing the heavy lifting over the years and Redis Inc has been trying to reap the benefits off of that by providing the software as a service. Which the community was fine with. Turns out other companies with deeper pockets for infrastructure can do the same. Now Redis Inc is trying to save their broken by design business model by changing the license. This casts a whole lot of doubt on the future utility and licensing of the Redis project. And this is what the community balks at.
They bought an open source project, and now that the original founder has stepped away they're trying to squeeze it for all they can.
The "big corps" that you claim are using it to "pirate software in a legal way" (a) have been contributing to the formerly open source redis project, and (b) are now specifically forking it to keep maintaining it as open source.
Supermarket bills cannot be paid with pull requests.
By using BSD license Antirez has freely given it to the whole world, not the name Redis but the code. No matter how big the corporations, the cloud providers are just using that code the way Antirez intended when he used the BSD license. You can't blame the cloud providers for that.
> Supermarket bills cannot be paid with pull requests.
But one can become famous by writing quality open source software and this fame can be used to get very high paying jobs.
Nor with increasingly unnecessary and niche features aimed at "enterprise" customers, it seems.
One could probably even argue that buying the rights to the name of a popular permissively licensed project is a terrible way to pay said bills.
How is it terrible?
Eh no. What an overly broad generalization to read. Whether it is enough to make a living is another question, but that does not mean one must paint all of the communities the same color.
You seem to believe that all open source projects are in this category. That is not the case. You also seem to believe that there is always one company doing the most work and everyone else is just leeching off. That is also not the case.
It's "buy the naming rights to an already popular piece of open source software and try to make a quick buck"
I, for one, will take the risk, reap the benefits and move on when factors are no longer conducive to my goals.
I'm sure that (FL)OSS core/demo versions is not the ONLY sustainable way to make a living. There is no need for hyperboles.
You don't even need to author software to sustainably make a living. Don't limit yourself.
I think it is valid to find this immoral. The solution is pretty simple though: do not contribute to open source projects that require you to sign a CLA.
What is considered immoral is to take the copyright from the contributors without giving any compensation.
Developers should be aware of that and, personally, I think contributors should never accept to sign a CLA. If the project requires a CLA, don't contribute.
And I think Open Source is based on the very few who decide to take it upon themselves to be the ones spearheading a specific project/task and share it with everyone else. Maybe it's not every single time me, sometimes it's you, sometimes it's Lucy or Mark, and that's how the roll keeps rolling for everyone.
So if a project goes down and nobody comes up to replace it, either it wasn't worth much or this is the time nobody took it upon themselves to do it (yet).
People who use open source are very entitled. They'd be very angry also if the license was changed to GPL or AGPL.
I doubt most of this people have meaningful contributions to FOSS.
This is actually the good news as it makes it all but certain there will be well maintained Open Source Redis alternative.
https://cyberscoop.com/pwn2own-chinese-researchers-360-techn...
Redict is a pointless endeavor. Just stick with Redis 7.2 before the licensing change. Maybe change the binary name if it makes folks feel better.
Redis Labs is not the only contributors to the project, Tencent and AWS contribute as well.
For Redis Labs the open source license was a distribution channel which they benefited tremendously.
I'm not an AWS fanboy but they operate some hosted solution significantly better than the companies building the products, at least the core offerings, this is what happened with Elastic and MonogDB.
It is Redis Labs prerogative to change the license, but they can also build a product around Redis that will drive customers to them instead of AWS, an offering that will be hard to replicate.
IMHO making a business that is "reselling" server capacity that was bought from AWS and trying to make a profit, can come back and bite you.
Nothing wrong with charging for support.
I love passion projects as much as anyone, but there is a reason they are hobbies, and people need to keep a day job. Eventually it does get tiring to do support for free.
Edit:
Ok. I was talking OSS generally. I guess Redis is being bad actor if they are taking OSS work and running away with it to get the money, and not compensating the contributors. That is very wrong. I don't know history on Redis and assumed it was the contributors that founded the company.
I'm not sure how nefarious this Redis move was. I guess I was assuming any move from 'free', to 'paid', will be met with some outcry regardless of how seamless they can pull it off.
Big deployments generally need really good support and help to overcome scaling challenges. Who better than the library maintainers to offer that, and your customers have deep pockets.
Then on top of that, you run a business which basically creates proprietary Pro and Enterprise versions of a product which has tooling to operate the project at scale or in high uptime environments.
Then you offer your own cloud versions of the product as well (which I think Redis has been doing).
But in none of these cases are you creating a disincentive for anybody to use/adopt your product. You're simply creating value around the pain points.
It's a company surprising everyone by pocketing the money from other people's hard, unpaid work.
Incidentally the most effectively way to stall a project according to the CIA is to have a huge guiding committee with clearly diverging interests.
Redis will win because it's focused on its users. It's competitors will lose. Like OpenSearch, like OpenCL etc.
It's no wonder our "freedoms" in the software world have slowly but steadily been shifting to look exactly like our "freedoms" in the physical world: artificial scarcity apportioned by the few using their leverage over systems which put you in a steel cage if you don't play along.
And here we are, arguing with each other using the terms of those who seek to enslave us to their control. The fact that these billion and trillion dollar tech companies even exist is a testament to our failure.
Maybe some kind of new license is in order. Open source, but preventing cloud redistribution. I don't know, I can imagine the issues with that as well. You want AWS out, but you probably still want the small up-and-coming CI/CD tool in.
The software is all there. Some dickheads forked a proprietary version. They got the name, which will be their consolation prize in their voyage to irrelevance; nice knowing you.
Meanwhile, what everyone uses marches on.
But Redis was BSD or BSD-like, no? Proprietary forks can happen with or without CLA, so it is moot.
I would say rather the opposite. If a developer contributes to a BSD (or similar) licensed program (under that same license of course), then at that point they are letting anyone anywhere do whatever they want with the code, as long as copyright notices are preserved. Then, if someone forks a proprietary version of the program (in a way that complies with that developer's license for those files) and that developer gets upset and tries to revoke the copyright license, that developer is the bad actor, not the forkster.
In the context of BSD-like permissive licenses, requirments for CLA, I think, would only be a form of legal safeguard against such situations, where people change their mind.
Yes you're right, I thought it was a copyleft license.
But now it is source-available with a CLA. Which in my opinion is a good reason to fork. I would definitely not contribute for free to such a project.
The article mentions half a dozen such forks. So not insane, maybe just a bit lazy ;).
The problem with these companies is that they actually were trying to make large returns for shareholders rather than simply earn enough to keep paying the developers.
[0] https://www.postgresql.org/community/contributors/
Support is usually for big corporate clients, and the Cover Your Ass principle works in full force there.
"No one ever got fired for choosing IBM".
I mean, I get it, everyone wants to become billionaire, but best to be honest about it up front.
Afaik the non-discriminatory use is the only ideological hard line. I guess people can debate that forever, like with GPL and copyleft and such. But my edgy take is that most people don’t really care about deep ideology yet want something that promotes a healthy hacker- and small-business friendly open source ecosystem. Ideally, a simple, well-understood license that restricts “re-selling your product” and not much more, that you can slap on a project without a legal team, just like with the MIT license.
The thing is, this kind of license is only really relevant to the kinds of projects that do have legal teams.
If you're writing a hobby project you probably shouldn't waste time worrying about feeding the AWS machine, because the odds that you'll get noticed and used are tiny. Just pick GPL or MIT and be done with it.
If you're participating in a large decentralized project like Postgres, then having a big player like Amazon providing managed hosting is actually a huge plus because you get lots of contributions from the big players [0]. There's very little downside for a project like this, and lots of upside.
The only type of FOSS project that needs an "AWS can't use this" license is a project that is driven by a single for-profit company which decided to make their business model "provide a managed solution layered on top of AWS". Unsurprisingly, it's hard to compete with AWS on price when you're using AWS itself as your vendor, so these companies tend to be the ones that switch licenses to tell AWS they're not allowed to compete.
These companies almost certainly have their own legal counsel and they represent a tiny minority of FOSS projects, so it's not obvious to me that we need a new standardized anti-AWS license. Maybe we should instead acknowledge that "managed-hosting-supported FOSS database" is an impossible business model and try something different next time.
[0] https://www.postgresql.org/community/contributors/
So you want to advocate that every future database / infrastructure company needs to burn part of their runway to hire lawyers to do the repetitive work of making sure they can both try to be open and try to continue to exist? Plus we, the users, get to try to decode reams of legalese instead of using a convenient three-letter handle for an industry standard, like GPL or MIT? This does not seem ideal..
> Maybe we should instead acknowledge that "managed-hosting-supported FOSS database" is an impossible business model and try something different next time.
The business model these companies chose was fundamentally broken. It's only fundamentally broken for a specific class of backend tooling.
I believe that future database/infrastructure projects should continue to use the FOSS licenses we all know and love and find a sustainability model that works without compromising the freedoms that make free software free. Postgres, Linux, SQLite, the BSDs, and many other projects in similar spaces have led the way.
You're right that it's probably not a great business model most of the time, but what is a good business model to collect some of the value you've produced from dedicating years of your life to something loved by millions of people? It's certainly less sketchy than monetizing a free service with ads, or something.
Look at the list of contributors to Postgres that I linked to. The vast majority of them are employed to work on Postgres, some by big tech companies, others by smaller managed hosting providers and consultancies.
That is a sustainable funding model for an open source database project. What isn't sustainable is building a business around the idea that only your company will ever profit off of (and thereby fund) the FOSS project. The whole point of FOSS is that both the work and the gains are shared with the whole community.
Yes, monetizing with a proprietary license, whether source available or not, doesn't seem unethical to most people outside of Free Software ideologues.
“The licensing model isn't unethical but competing ones are” isn’t why open source licenses became popular over proprietary (including source available) licenses, the fact that they commoditized the underlying software, enabled competing orojects evolved from the same codebase on essentially equal terms (which also allowed a competing project to fully replace the original if the original at some point failed the community) and, as hosted offerings became more common, the zero licensing friction for hosted solutions, that's what did it.
It does mean charging monopoly rents for a hosted service isn't a viable way to recover development costs and pay returns to VCs, but until fairly recently, no one was trying to do VC-backed startups around single open-source products with that as their whole business plan, and the arguments as to why that would be a bad idea were well developed by the mid-1990s
That being said. Monetizing open source is fine so long as people are up front about from the beginning. People are upset because switching the license is effectively changing the rules in the middle of the game.
It is like going out to a restaurant and in the middle of your meal they change policy from having free refills to charging per cup. Either policy is fine, but changing policies is a scumbag move. A lot of people would have never sat down to eat there if the extra drinks weren't going to be free. Especially if free drinks was the sole reason a lot of them were going there.
Redis Labs can start by compensating its external contributors (Tencent, Amazon, Alibaba among them) if they care about fairness this much.
In fact, the concept of the four freedoms as necessary parts of a more fundamental freedom is one of the things that I value the most about the free software/open source world.
In hindsight, I think that the probability that things turned out the way they did in this regard was relatively low, but the ideological drive of GNU and RMS made the world see the problem from a philosophical perspective rather than a practical one (even among people that don't fully agree with RMS/GNU/FSF).
If you're a corporation then you need to buy a license.
It's not a hard concept to understand, but it does mean people can't steal from the commons so they spend a lot of time trying to not understand it.
Would it be "viral" in the sense that, if I want to publish software that internally uses a Docker container running software with such a license, my own software can be used only by natural persons?
Not because you are distributing it, but because only natural persons can run the software.
At this point listening to them is at best pointless and at worst actively harmful. This is what happens when the last time you worked at a real job was some time in the 1980s.
That's not what AWS is doing. AWS is selling management services. The fact that managed DBs are as popular as they are says this is a significant value add.
Well yeah technically the product is free but the value comes largely from unpaid labor. That needs to change if we want a healthy small business sector around larger open source products. It’s not based in opinion or ideological conviction on my end, but rather watching this frictionous and awkward transformation to BSL-style licenses happen over and over with small-mid-size companies who are building valuable products and want to be as open as possible while running a business.
> The fact that managed DBs are as popular as they are says this is a significant value add.
Indeed, and that’s a good thing, because it means a path to a sustainable business model is feasible! However, if you subsidize the product (make it free and open) in order to make it back in management fees, then you need legal rights to it. It could be “you have to use $PROJECTs own management product” but that’s quite narrow thinking. It’s a win-win for everyone else if mega-players like aws can provide their own management but they will have to rev-share with the project owner, on their terms. That’s a battle-tested model that works in all kinds of sectors, with much smaller actors.
If the service you provide is hosting DBs, you are are at an inherent disadvantage competing with hosted db offerings form your potential customers' cloud provider. Even if your product is technically superior in every way, you are another entity they have to do business with (billing, support, contracts, security evaluations, etc.), which adds friction, and either you host on your own infrastructure, which means higher network latency, and network costs to get data to and from your customer's cloud, or you have hosting options that run inside all the major cloud providers, in any regions your customers use, which means you (or your customer) ends up paying the hyperscaler for the infrastructure, and you have the added complexity of having to know how to manage it on multiple cloud platforms. And there there is also the fact that it is much more difficult for you to build integration with the cloud's IAM or other services.
Basically, most cloud customers would rather use a service that is part of the cloud platform than from another provider. Ideally, instead of competing with the hyperscalers, they would sell some service to the hyperscalers that have the ir own hosted services. But I don't know how to get there.
As a brief sidenote, AFAICT this isn't what happened with the hashicorp license change, for them it seems like the pressure largely came from startups, not the big cloud companies.
We have several in use by long-running open source database projects that have not felt a need to jump on proprietary source-available licensing, even though firms like AWS are indeed using their code and selling services.
AWS (and other big firms with hosted services) are also sponsoring those DBs with code and/or money, but in many cases the basic model predates the big push to the cloud, and other downstream businesses were doing that before AWS and other cloud hosts.
Open source DBs have been around a while, though. A minority of them trying to pay the bills with monopoly rents on hosted services is… much newer. Its how VC-backed DB-as-central-tech startups try to monetize, and, yeah, if you are going to do that, you need a proprietary license.
But don’t expect people to treat your DB like an open source DB, then, either. You can be Oracle instead of Postgres, but you can’t also expect to get treated like Postgres, instead of Oracle.
It’s early. Everyone is confused. If I could define it, I would have provided a defintion.
At this stage, it’s about acquiring requirements and looking at prior art. And being humble about the solution space. No? If you don’t think there’s any problem today, then argue that point.
> By definition you cannot have an open source licence which says "cannot be used for bezos yacht".
By definition by what definition? There are already disagreements about what open source is, long before these business models. The problem solving comes first, and then there may or not be a debate whether about whether the solution fits better into an existing definition or a new one.
> Either you accept that […] or you don't open source your code
But why? Is this an intrinsic duality or an anccidental/historical one? Or is it about preventing scope creep of the open source term? The latter is easy to solve - don’t call it open source. Or at least defer the debate.
No, it is not, it is decades in, in a well-understood area. Some VC-backed firms (and the VC’s backing them, who see this as critical beyond the immediate firms) want to trade on the idea and popularity of open source without its substance because open source as has has been known for decades is not a viable foundation for the kind of business model that they would like, but has at the same time secured the kind of mindshare in the market that makes it difficult for proprietary software to achieve the kind of rapid ramp-up that provides the timing and combination of returns they want. So they’ve decided to spend a lot of effort making everyone feel confused at some ginned up new threat to open-source, which is not a threat to open source, not something that open source community hasn’t known about for decades, but just a problem for a bait-and-switch business model in which software gains traction trading on the cachet of open source and then rakes in monopoly rents that avoiding is one of the benefits to users of open source licensing.
They want users to see them like Postgres, but they want to milk users like Oracle. That’s the problem – a marketing problem for proprietary software vendors. The attempt to sell confusion is an attempt to conceal that that is all the problem is.
As always, Chesterton's fence applies: all of the 10 points of the OSD were widely debated at the time (as was its predecessor, the Debian Free Software Guidelines), so it's worth explaining why the issues raised then no longer apply.
By the "Open Source Definition":
https://opensource.org/osd/
FOSS acceptance is a grey area. Something has been tried with the AGPL, which is FOSS, however, it has been deemed not to provide adequate protection by companies creating similar products (while, ironically, being considered poisonous by companies using them), so the SSPL was created, but it hasn't been accepted as FOSS license because its intent was unclearly defined (http://lists.opensource.org/pipermail/license-review_lists.o...).
I contribute with no expectation of monitory gain and absolutely zero desire for some random foundation or company that's part or almost always created later to make any money. If some contributors want to make money become consultants the "amazon problem" isn't a real one.
I love when Amazon or Google or whoever starts working with a project I'm touching it means it will normally get high quality contributions.
[0] https://opensource.org/osd
Now, Redis was AFAIK pretty much just written by antirez and maybe it could have stayed that way, but even exceptional individuals clearly want to move on eventually and you'll likely need a team of maintainers. Distributed data products are complex and need people who contribute more than nights and weekends.
The "cuts into their revenues" part usually mostly affects their ability to keep developing the non open source parts anyway, their SaaS dashboard, their billing, etc.
Take redis, you could never change it again and it's fine. There's no need to support anyone, it's complete software that stands on its own.
“Source available” is a subcategory of proprietary, not “better than proprietary”.
> But my edgy take is that most people don’t really care about deep ideology
I think most people that orefer open source to proprietary software either care about the business benefits open-source provides over proprietary (including source-available) software or have an ideological affinity for Free Software, occasionally both.
The "major platform hijacks our code for the web" is a valid concern, but the FOSS people have always kinda gone "well fuck you for having these concerns". That's... I guess fine enough when the majority of FOSS wasn't part of a SaaS stack, but now that the majority of big name libraries and tools are, it's becoming clearer and clearer that the OSD is just too lacking for those concerns.
To be clear, this isn't a defense of SSPL or similar anti-Bezos licenses (the best one I've seen is the BSL, which transforms into a traditional OSS license after X years if you want my opinion), moreso an observation that there's a clear need here that can't be met by OSD. Paying developers on top of the FOSS model is hard; doing support favors entrenched suppliers because of the CYA problem (this is why AWS has the advantage they do) and I'm pretty sure that even if you do the support model, it usually just doesn't pan out.
The main reason 90% of these licenses suck is far moreso because lawyers will draft contracts and licenses in such a way for you that they'll always give you the advantage. The SSPL being borderline impossible to comply with is by design for example.
Unity was like that before they screwed it up, I have heard of other systems as well but not sure since it's not my cup of tea.
If they approved SSPL they'd probably have to lay off a staff member or two.
But I feel no such sympathy for Redis nee Labs. It was never their project. They took over stewardship and then effectively stole the project for themselves. They’re not even the dominant contributor to the core product.
So I view it as every major cloud provider with redis offering has its own fork. Except that Redis Labs also owns the original name. But it can go on as a stand alone project, like MariDB was spawn off after MySQL acquisition by Oracle.
[1] https://news.ycombinator.com/item?id=25776657
[2] https://github.com/redis/redis/graphs/contributors?from=2019...
> Industry participants, including Amazon Web Services (AWS), Google Cloud, Oracle, Ericsson, and Snap Inc. are supporting Valkey. They are focused on making contributions that support the long-term health and viability of the project so that everyone can benefit from it.
Seems like a good alternative to a single company's spinoff: Many major providers working on this same project should result in everyone benefiting from it.
https://www.linuxfoundation.org/press/linux-foundation-launc...
Being a customer of the redis labs' hosted solution, we noticed several issues:
- RLs solution is way more cost effective than AWS's
- RLs solution is not even close to elasticache in its ability to scale
- when issues occur the organization internally moves incredibly slowly so simple issues can turn into prolonged outages
Moving to this licensing model will make it possible for them to better invest in these things. That said, given the quality of their offering and lack of investment in the actual redis platform, why would anyone continue to use redis after the license change? The cloud providers can fork off their own version and never look back!
I think they're shooting themselves in the foot here.
Its not cost effective if the service causes extended outages as you mentioned later.
Open source services are in a weird spot. They spend tonnes of money developing it and big providers are able to cannibalise as soon as something becomes popular at very little cost to themselves.
I think we do need something between fully free and fully closed where cloud providers pay some kind of licensing. It’s a problem worth solving.
I say alot because its not like they can't still make money. They can still consult, they can still offer support or hosting but because theyre not making millions they want a "new" license.
Its stupid. you solve the itch then your done unless your doing maintance. people making open source software like paid software, constantly adding new features and changing things to justify their existance. You dont need millions in devs if your just solving a core problem.
A grand unified theory of software goods funding, if you will.
If you haven't read Hal Varian's Information Rules, I highly recommend it. Check the publication date, then read it anyway, then reflect on the publication date when you're done. I found it very worthwhile.
Do you need a faster compiler, or a better OS, or some cluster operator just to get your widget factory working? Don't build those in house, instead find others with the same problems and create an open source project together to work on them.
But don't try to sell open source software. It's essentially impossible to do that, it has been tried time and time again and success is rare, and huge success is basically unheard of (RedHat being probably the one single exception).
Sure, it is the commoditize your complement strategy [0]. But that doesn't help get complex open source products to market, it only helps with tooling.
Maybe you are right and there's no way to directly pair the freedoms of OSS with the capitalism of VC backed startup.
0: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
Projects could still be funded by community users, but "venture funding"? That's how projects turn to shit.
It's a very pure example where parties in competition each that have a use for some kind of software can shortsightedly develop their own versions of it in-house, but that duplicates a lot of effort. They'd be better off getting together with their competitors and collaborating on a shared version that suits their needs, avoiding duplicating effort and all benefiting from each others' contributions. They could do this by direct collaboration or by funding an independent organization that fulfills their needs.
Sure, this can go badly if there's a large difference in scale between the different parties and some can muscle others around. But it and similar models do work out at the scale of the Linux Foundation, Khronos, down to Mastodon, GitLab, Blender, Krita, Forgejo, even arguanly projects like Bitcoin Core.
There isn't the structures to facilitate this kind of regime shift. But there should be.
As part of that world, I also want livable wages and work-life balance for developers, so they can work on their passion FOSS off-call. And for students and programming enthusiasts to be more passionate about FOSS. Like in the 90s before the corporates took over FOSS.
If some FOSS still wouldn't exist then, I'm fine with that.
Developers need a salary to pay the bills. Let's say that covers the first 40 hours of the week.
Those who are searching for significance outside their day job offer free labor as their "hobby". Maybe 10 hours a week?
For projects that want to move forward with some velocity it makes sense to make some of that development into paid day-jobs.
As projects get very large, there's a fair amount of overhead in just "keeping up". That erodes the 10 hours quickly. Further reducing the time to contribute.
So where is all this cash to pay employees coming from? Certainly not end users (as anyone who's tried funding an OSS project from users knows.) No, it comes from commercial companies (MS, Amazon et al) or venture capital.
This is the cognitive dissonance that underpins OSS development. The very people OSS treat as the "enemy" are the people funding OSS in the first place. As much as say RMS rails against big tech, Linux and the rich Linux economy system only exist at the level they do -because- of big tech.
Of course, I painting with a broad brush, and there are exceptions, but the point remains. It's turtles all the way down, and those turtles are not funded by users.
>This is the cognitive dissonance that underpins OSS development. The very people OSS treat as the "enemy" are the people funding OSS in the first place. As much as say RMS rails against big tech, Linux and the rich Linux economy system only exist at the level they do -because- of big tech
Perhaps that's the problem: that they exist "at the level they do", meaning most of it is corporate focused, and not enthusiast and user focused.
Even ourselves, as devs, evaluate FOSS as to whether it's "useful" for our corporate/startup needs. This wasn't exactly the case, or at least not the main case for a FOSS project.
Gnome, for example, wasn't created to give RH and co a desktop shell for corporate installs...
Except they kinda did. The foundations of FSF are born by academics working at institutions, getting paid salaries. The were devoting time certainly, and certainly in the case of RMS with passion and cause, but that work was definitely funded - usually by the university.
>> Perhaps that's the problem: that they exist "at the level they do", meaning most of it is corporate focused, and not enthusiast and user focused.
I think we can drop the term "enthusiast". It implies tiny niche group with little practical value. I'm thinking of classic car "enthusiasts" who spend all their time under the car, and precious little driving it.
So let's talk about users. Users want full-featured reliable software. I would suggest all software, if successful, is user focused. (To he honest, I'm not sure what you have in mind with "corporate focused".) Firefox, to pick one project at random will seemingly live or die based on the individual user experience.
Equally take databases - there are s plethora of options to suit every use case. Need big powerful fast enterprise scale - Postgres is for you. Need small footprint with easy install - try Firebird. And a gazillion others. Surely such quality is a good thing?
>> Gnome, for example, wasn't created to give RH and co a desktop shell for corporate installs...
Um. Sure it was. It was designed to offer a gui desktop on top of Linux. Who did they think would use it if not Linux distributions? Given that for decades "the year of Linux on the desktop" was a meme, I'm not sure it's fair to claim that distributions using Gnome to create desktops for business users was a surprise.
The historically 'good' open source companies like Sun got bought but the ones that weren't like Oracle. The selling support model alone does not seem evolutionarily fit for the market.
Now we have these VC-backed 'open source' companies that have a playbook wherein they appear open source at first. But when you dig deeper, you find that the heart of the thing is a closed binary.
The investors are going to want to be paid back somehow. And the business model of VC means that one of two things happens:
1. The company finds a way to 100x the return. Which, if you're a customer, might be a scary prospect.
2. The company makes an amount somewhat lower and, while it would be a good business for a non-VC company, they're considered a zombie by their investors. So, they are killed leaving you as a customer in a bad position.
I therefore trust non-VC backed companies substantially more to keep alignment with their customers long-term.
A workable model could be for instead companies that have legally-enforceable promise not to enshitify their closed sourced product. So that the product will always be aligned with the paying customer. The customer cannot be made the product at a future date.
I think it's pointless to even compare it to the Redis company; just about everything is different.
0: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
I find it amazing how much money is being spent to ensure open source code doesn't end up in the hands of users and how many people are blaming the ones trying to increase user freedom.
> If the licensor advertises license terms and a pricing structure for generally available commercial licenses, the licensor proposes license terms and a price as advertised, and a customer not affiliated with the licensor has bought a commercial license for the software on substantially equivalent terms in the past year, the proposal is fair, reasonable, and nondiscriminatory.
However, just like fewer homes would be owned if you didn't have mortgages, less software companies would exist without VC. It's basically a subsidy from the rich, endowments and pensions, to the rest of us (consumers because we get stuff for free, developers because it increases the demand and thus salaries for us).
I think VC is a net benefit to the world in terms of software delivered and companies built. I think OSS is a net benefit to the world because of the explosion of possible ideas and the leverage it lets developers have as they build on it.
I would love to see these two huge innovations in building software work together well. Haven't seen it yet, hence my original comment.
A Microsoft Research, open source, performant, almost RESP compatible alternative (according to them)
https://github.com/valkey-io/valkey
And not to forget Redict, also a fork, that is maintained by drew devault
https://codeberg.org/redict/redict
Where this is coming from is having worked on a project where Redis was being used as a database and a cache, on different ports. And of course most of the dev team hadn't read the the manual because Redis "is simple and just works". And of course someone forgot to actually configure the Redis instance that was supposed to be a cache to actually _be_ a cache. And someone else thought the instance that was supposed to be a cache but wasn't was actually a database. And yet another had used TTL caching to solve all their performance issues. And pretty soon mystery bugs start showing up but sadly no one can actually REASON about what the whole thing is doing any more, but there's no time to actually clean up the mess because it's a startup struggling to stay afloat.
And I remember asking "why didn't you memcached for caching?" and the response was "Dude! No one is using memcached any more". So the technical decision for Redis was based on "what's cool right now".
Anyway... I feel a bigger rant brewing so I'll stop here.
But I think you described right the social behaviors of certain/common types of users.
https://github.com/Snapchat/KeyDB
[EDIT] whoops, didn't read the article, went immediately to comments for recommendations since that's what HN is good at IMO.
Also, just look at the amount of open bugs and their age [1]
They also recommend using swap for some reason, however if your memory usage reaches the point where swap is being used the performance is so bad that the machine may as well be dead.
It's been nothing but trouble, which is a shame because the changes they've done to redis have crossed my mind too. We'll probably move to Scylla.
[0] https://github.com/Snapchat/KeyDB/issues/465
[1] https://github.com/Snapchat/KeyDB/issues
It even suggests cloud providers did contribute, and uses bad data (git commits “by employer” w/o dataset) that basically contradicts their argument.
I may be biased, as I saw Amazon doing exactly what this article claims “maybe they weren’t”. But statements like this seem intentionally misleading, and easily disproven:
“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.”
MongoDB is still “source-available”, and on the same GitHub repo I’ve used since 2010. The SSPL only impacts cloud-providers, and has exceptions for cloud providers who release their source code.
The OSI doesn’t get to define open-source. Neither do I, but at least I was part of the community for ~20 years…
From you people who know a lot about Redis, help me out here: For my Web site code (for my startup), I needed a key-value store. Soooo, it looks like I could use Redis for that.
But instead, wrote a little code using two instances of a Microsoft .NET collection class. Simple code. Plenty fast. Welcome programming exercise using .NET classes. Cheap -- no ongoing charges and no chance of charges in the future. And, no concerns about what might happen from politics, business, some remote service, etc.
Question: What am I missing by using my little DIY (do it yourself, roll your own) solution and avoiding Redis, work of other people, or a service from Amazon Web Services, etc.????
https://learn.microsoft.com/en-us/dotnet/standard/collection...
It's thread safe so that if my startup is more successful than I'm assuming then I'll be free to do less on how to exploit parallelism from several servers. As it is, the code I wrote serialized access to the key-value store I wrote. Sooo, that could be a performance bottleneck.
I should review network address translation (NAT) and affinity of one user to some one server, instance of Microsoft's IIS (Internet information server), thread of execution, etc.
This will save you a lot of headache and get the best experience.
I'm the self-funded, sole/solo founder. So, I pay attention to the business, e.g., getting and pleasing the users, and also the computing. If successful, then getting paid for running ads, accounting, taxes, lawyers, floor space, employees, etc.
So, for now, concentrating on pleasing the users. Part of that is some original applied math. Users won't be aware of any math, but the math should be secret sauce and an unfair advantage. So, am also concentrating on applying the math.
For the software, trying to keep that simple.
Had a disaster, but before that had the Web site running: Mid tower case ($40 with a $20 rebate), $65 motherboard, 8 core AMD processor with a 4.0 GHz standard clock ($100 at Amazon), Windows 7 Professional, some 4.x version of .NET, IIS, ASP.NET, ADO.NET. As I understand it, .NET CORE came later and is more restrictive.
My project is only for a Web site; users will get to the site only via the Internet and a standard Web browser. E.g., I'm making no use of anything mobile. So, the project has no mobile app.
Am highly motivated (1) to stay with just Windows, soon Windows Server, and (2) to keep down, to zero, the investment of time to program on Linux, IoS, Android, etc. -- hope never to write any code for any of them. That is, I can get paid only from revenue from the business; while I have to write the code, and it's fun to do, that's all a business expense; I can't get paid for writing code. I'm assuming that Microsoft and Windows have a foundation plenty sufficient for my business objectives.
I have yet to move to a later version of .NET: Okay, I should, but, still, not looking forward to the effort. To me, the 4.x version of .NET I used looked fine. For another outrage, I wrote in the .NET version of VB (Visual Basic) and wrote no C, C++, or C#. I really like VB.NET, regard it as a nicely designed, implemented, documented language with plenty of features for what I need.
For what I wrote, the UI (user interface) is simple and traditional -- billions of people will understand it at zero effort, immediately. There is a huge range, world, universe of Web page design features I didn't use.
The timings I did show that the site is astoundingly fast, fast enough that if can keep the computing on average 50% busy 24/7, then standard ad rates will generate some gratifying revenue.
An 8 core processor with a 4.0 GHz clock is no toy, is a lot of computing.
Recently heard about Amazon and their AWS (Amazon Web Services) wanting the TLS (Transport Layer Security) version 1.2. Soooo, I checked, saw that I was using version 1.1, that 1.2 was available, so picked 1.2.
What I'm doing now is dirt simple: Have 1000+ Web pages of Windows and .NET documentation, so wrote just ~300 lines of Rexx code to extract the page titles from the HTML tags
<title> ... </title>
and make a TOC (table of contents) I can read into my favorite editor KEDIT and search -- then one keystroke to KEDIT will have Firefox display the Web page.
Want to do some more system management, get the site running again, do some revisions, do some marketing, and go live.
In short, my CEO-business hat has me think, for the foundation of .NET, it's good on features, is now old and likely quite reliable for the old features I will use, and seems plenty fast -- soooo, I know, I should be ashamed, that's good enough!
I know of no such, and you gave no examples.
> It seems you have not been even tangentially keeping track of any developments after... 2015.
You are attacking me personally or the content of my writing?
For your date 2015: A key to my Web site is some math, and it is original with me, from my research, and, thus, fully up to date! Uh, I'm able to do such math partly because I hold a Ph.D. in applied math from a world famous university; for more, I've published peer-reviewed papers in applied math, saved FedEx with some applied math for the BoD, taught applied math in some famous universities, both graduate and undergraduate, and, oh yes, published peer reviewed original research in artificial intelligence. Also taught computer science at Georgetown University.
There was a LOT going on in the Internet and the Web, HTML, SQL, etc. long before your 2015: Gee, there was a nice introduction to developing Web sites in
Jim Buyens, 'Web Database Development, Step by Step: .NET Edition', ISBN 0-7356-1637-X, Microsoft Press, Redmond, Washington, 2002.
Yup, that's 2002, long before your 2015!
That book is an example of excellent technical writing. There are 15 chapters with nice introductions to each of VB.NET, ASP.NET, ADO.NET, database and SQL, one chapter for each, plus more -- all from 2002!
The book does not emphasize how to use JavaScript to make Web pages that jump around for no good reason, make users angry and leave, and hurt the ad revenue.
Net, in simple terms, what is new and important about my work is my original math; nearly all the rest of the tools used and features implemented goes back to the last century.
For some irony, and also a good lesson, consider Hacker News and its functionality and user interface, both that go back largely or entirely to the last century.
Uh, for "developments" since your 2015, for the back end, that has my original math which is fully up to date, and for the front end, i.e., the user interface, in general, in simple terms, for my Web pages, each new technique would be something more users don't understand and that, thus, might hurt the success of the site.
Let's see, since your 2015:
Pizza is really OLD, and Pizza Hut is worth $38 billion.
Hamburgers are really OLD, and McDonald's is worth $193 billion. Burger King, $34 billion.
My 1986 Chevy S-10 Blazer had good electronic fuel injection, no other digital electronics, and standard sealed beam headlights which for me made it as up to date as I want -- for anything since then, for me it's useless or annoying, more to buy, and more to maintain so I don't want it.
No, no, not at all: I admit, accept that no doubt Redis has a lot more functionality than the few pages of code I wrote.
My question was: My code looks like it will do what I need done, but maybe I'm missing something, i.e., maybe Redis has some features that very likely I should have?
If want to expand the question to other people, what is the chance that usually Redis is overkill, more functionality, code, complexity, considerations, ..., than needed? I don't know so am asking.
Or, I had a 2 wheel drive car, but did I miss a lot not having a 4 wheel drive car that I nearly always used in only two wheel drive?
You may need data persistence (keep the data live while you restart your process), cross-instance coherencies could be nice too, automatic data expiration too.
But if you do not, then it is ok!
My code that needs a key-value store is simple, short, just uses two instances of a .NET collection class.
I need NAT (network address translation) to keep affinity of each user with their one execution instance of my code, but I suspect that is automatic with Microsoft's IIS (Iinternet Information Server) that the code uses.
For persistence, the code needs that only long enough for each user connection. And for performance, I don't need sharding across several servers acting like a cluster -- maybe that is some of what Redis supports.
It appears that .NET has more functionality and performance potential (user connections per minute) than my project needs, so I'm trying not to try to master everything Google, Facebook, Amazon, a big bank, Walmart, etc. might need! So far, I'm pleased with .NET.