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.
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.