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.
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.
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.
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).
Which is why Microsoft's new drop-in replacement works with all those things. It could gain traction - who knows.
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.
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.
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.
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.
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.
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.
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.
AWS takes most of the profits whilst contributing relatively nothing back
We’ll see what happens though. If redis Inc (that never created redis) wins over AWS, GCP and others (who also never created redis). Both contributed to its maintenance, as GitHub clearly shows. We’ll see which fork wins out.
I've called AWS's hiring of a single developer a token hire that they then go on to write flowery PR posts about to camouflage their predatory relationship with OSS vendors.
For concrete numbers they contributed 165/12111 commits for a total of a 1.36% of the commits.
Whilst that qualifies as a valuable contribution to any project, it's also dwarfed by the 350M investment in Redis Labs and doesn't absolve AWS from being a called a "leacher" by helping themselves to the majority of the profits whilst contributing relatively nothing back.
It’s funny that you would use commits to quantify investment from AWS, but you’d use $ to buy shares in future profits to quantify investment from redis labs. Why not use the same yardstick for both?
Either way, it doesn’t matter. Not one bit. Everyone who put in effort into redis did it knowing the license. There’s nothing wrong in relicensing future commits. There’s nothing wrong with forking. There’s nothing wrong in using whichever fork works better for you.
You’re insisting up and down that AWS and others were leeching because they didn’t own the copyright to redis. I’ve never heard this interpretation of OSS before, but sure maybe you’re right. But we’ll see which fork comes out on top a year from now.
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.
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.
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.
It's lose/lose!
Code contributions from amazon would've been leeched by other parties using redis as well - something which amazon is accepting (and probably encouraging).
Basically Redis Inc is the one making the fork, which retains the Redis name since they purchased it from antirez.