The same is true for ES, Mongo, and Grafana (to name a few). If you want to use a restrictive license, start your project with it, period. Don't bait people by giving something for free and then making all sorts of excuses later.
IMHO, small companies and developers ultimately lose here. ES and Mongo still use and rely on AWS for their managed offerings. OpenSearch (mainly pushed by AWS) is vibrant and very alive. Redis will be ditched by distros and die a slow death, and (probably) Valkey will be in the next distro major versions. But we (small companies and devs) now have to spend time migrating and moving things around without any additional value.
Here’s where antirez said he chose BSD because he wanted to allow forks that change the license. [1]
Under BSD, forks that change the license and forks that don’t change the license are both okay, full stop. When antirez chose a BSD license, thinking he might do a proprietary fork later, it wasn’t “bait,” it’s how it works.
But when Redis, the company, said that Redis “has always been and will continue to be BSD licensed” [2], this was an implicit promise about what license the company would use for their own future improvements to Redis. In that sense, what they said is misleading, and maybe that’s bait.
So giving things away for free isn’t wrong, and making a proprietary fork isn’t wrong. It’s promising that you won’t do it and then doing it.
[1] https://news.ycombinator.com/item?id=39863371 [2] https://lwn.net/SubscriberLink/966631/6bf2063136effa1e/
I have always been to afraid to ask this ask this question for fear of appearing stupid. But gotta live and learn. So here goes nothing.
When I learn redis, I spend time and want to amortize that over a long period. When I integrate elastic search into my application, I expect to be able to use it in the same way far into the future.
Relicensing, as you point out, doesn't affect past versions, but it sure does future ones.
Now I have a surprise chore on my plate, to figure out if and how I need to replace the existing component or learn about an alternative.
More than that, my confidence is shaken. Will they make changes in the future requiring more work on my part?
Changing a license is very similar to an increase in price, but even more fundamental in terms of uncertainty. And people hate change.
(I'm explicitly not addressing the impact of a license change on software freedom because I think it is very important to some. But IMO most folks are more interested in free as in beer than free as in speech. I don't know enough to speak to the free as in speech aspect, so won't.)
I think you asked a great question, hope my answer sheds some light.
It's undoubtedly bait and switch.
You have a company that portrays itself as the host of a project that relies on community contributions for maintenance, and all of a sudden that host unilaterally forces a licensing change where all users, including those who have been directly and indirectly contributing to maintain the project, are faced with an invoice-or-lawyer threat.
Yes, the source code is still available. Yes, anyone can pick up the last release and run with it. But it isn't business as usual anymore.
It disrupted day-to-day operations of all companies that have been using the software. Managers of all levels had to hold meetings, internal and across organizations. They had to ask lawyers questions and decide what to do and how to act based on their answers. People scrambled to react to this change.
To make matters worse, this change was overtly designed to extort money from it's users. There is no two ways around it. The first step is a sudden change in licensing terms, and expectedly the second step of sending in the lawyers to collect payments under threat of legal action.
If you start a project, invite people to come along and donate their free time to making it better, building (and benefitting from) a community of people working towards a common goal, suddenly switching that project to proprietary is a bit of a dick move.
Sure, it's legal, but for the people who thought they were collaborating together on something it feels a bit crappy.
> If you want to use a restrictive license, start your project with it, period
There is essentially only one restriction (the other is about formal notices) imposed by the RSAL, and it forbids to "Commercialize the software or provide it to others as a managed service".
> IMHO, small companies and developers ultimately lose here
This is an uninformed opinion. Nothing changes for small companies and developers. Actually, nothing changes even for larger companies, unless they are cloud providers.
Large companies can actually provide Redis as service for internal use ("as a service internally or to subsidiary companies"). Companies are even free to sell support for Redis.
> offering a product or service, the value of which entirely or primarily derives from the value of the Software or Modified version
How do you define how much value your app derives from Redis? If Redis is the primary data store for your app, does it count?
You shouldn't have to do anything: I don't get it I think you're making a choice because you have a preference for non-copyleft licenses in software you use? That's your choice
As far as I know there's nothing that can stop a project from switching license (for for new code only, of course) and this can feel like a deception. There may be a legal/corporate mechanism I don't know about, like a permanent kind of charter, but it seems not.
The best option I can think of is giving control (board seats or copyright assignment or whatever) to trusted institutions like Apache or the FSF or Linux Foundation.
It seems too easy for big "open" endeavours to change their mind after they've built trust and a userbase. It would be great if there was a way to guarantee that that won't happen.
Of course there is. Don't require a CLA and use GPL instead of permissive licenses. Then any derivative work will have to legally be GPL compatible.
While I agree with you on not changing licenses mid-way, what is a small software company supposed to do? What is the Day Zero playbook that balances the desire for growth, creating customer value, and co-existing with the big cloud companies? I'm disappointed about the outcomes for companies like Redis/Elastic who obviously did create much value.
We in the same universe? I've seen nothing but Redis thrown to the wolves for daring to ask for money, at least around here anyway.
Reducing it to purely "asking for money" is not what the criticism is about. The issue is the changing of licensing terms and not the money.
Other open source projects that also have commercial paid products/services include SQLite, Bitwarden, TrueNAS, etc and yet there isn't endless arguments about those projects "asking for money" because their licenses have remained stable and don't change. GPL, AGPL, BSD, public domain, etc. doesn't matter; they didn't change the license.
That's what the whole "rug pull" arguments have been about.[1] One can choose to side with Redis Inc over Amazon but you can't mischaracterize what the debate has been focused on: changing the license.
Did Redis Inc have legal right to do that?!? Yes. But the debate wasn't about their legal right.
The following 2 types of timelines have very different reactions from the community:
- start with SSPL license on day 0 and never change
vs
- start with BSD license and keep it for 15 years and then change to SSPL
[1] 2018-08-22 >, this is Yiftach, CTO and Co-founder of Redis Labs. First, let me assure you that Redis remains and always will remain, open source, BSD license. -- from https://news.ycombinator.com/item?id=17819392
However, I think everyone understands that it's a problem to make a living from small but important part of an bigger infrastructure, but this is the wrong way.
The Linux Foundation will throw money at Valkey, Amazon will still sell the service and Redi's will lose (because it's just one company and not opensource).
[1] https://opensource.org/blog/the-sspl-is-not-an-open-source-l...
And I'm not even talking about external contributors whose work is re-licensed under a proprietary license.
Overall if an OSS project becomes a significant part of cloud workloads, the cloud providers will pony up to keep that project going.
Tencent - 24.8%
Redis Labs - 19.5%
Alibaba- 6.7%
Huawei - 5.2%
Amazon.com - 5.2%
Bytedance - 2.0%
NetEase - 1.3%
Users lose out on the fruits of that labour, harming bug fixes, feature development etc., as well as now having to consult with legal experts and the like to ensure there is no chance the fall afoul of the new license (you need to be really careful with the wording and the way it might be interpreted, not just how you interpret it or how Redis Lab's blog post suggests it is), and any time and hassles spent switching.
The people providing that labour now have the hassles and expense of forking, setting up governance, legal stuff etc, when they could have been just getting on with things.
Amazon has people contributing to a lot of projects. Google and Microsoft do so too. If you look at who actually contributes the most to things like the Linux kernel it's all the big software companies you can name: Amazon, Oracle, Google, Microsoft, Intel, etc. That's not ideology but just out of necessity. Linux is as big as it is because it has had big companies backing it and working on it for the last thirty years.
You could actually turn this argument around and say that for an open source project to be successful and have lots of users, it's absolutely critical for big companies like this to be able to get involved. The more the better. This requires robust communities backed by an OSI endorsed license providing a neutral place for development to happen.
I would not be surprised to see most of these companies re-engaging with their OSS forks a few years down the line. Assuming they survive the implosion of their user and developer communities of course. If the business is there (and it will be) and they have the expertise, why would they ignore that? And there will be lots of upstream contributions to their forks that they'll find themselves rebuilding in closed source form. It's going to be tempting to just take the upstream OSS stuff that's there ready to be used. And from there to contributing back to it is a natural transition.
As a long time Elasticsearch user and consultant, I've been following Opensearch pretty closely. It's attracted a lot of users, companies, and activity. Essentially all my clients are defaulting to Opensearch at this point. That has got to be majorly annoying if you are a sales manager working for Elastic. Lots of their former employees are working on Opensearch as well. All of their business partners are now also supporting Opensearch, etc. As a strategy to stop that from happening, their closed source moves have largely failed. They just accelerated it.
Just like you might imagine a leech could evolve some attribute to help defend its host against other predators.
I can't speak on the elastic vs open search topic though - does being part of the fiefdom of amazon work as a survival strategy?
The same article would apply to Terraform (and OpenTofu as the fork now), which was a much more clear "community doesn't want this" case. There were a few companies that provided a bit of hosted terraform services, but it was hardly at any significant scale. Yet the same thing happened: community doesn't want a restrictive license.
I have no respect for these organizations. Provide real open source software or start up closed from the get-go, don't build on community contributions for a while and then switch to closed while marketing as being open!
Seriously though, very duplicitous framing by AWS. Ignoring the clear existential threat to Redis's business if they allow other managed offerings to undercut their own.
Even if you're not affected by this license change because you aren't hosting Redis there is no reason to believe that you won't be on the chopping block for the next license change when Redis Inc.'s numbers must go up. The trust has been completely broken. You would be crazy to base your business on Redis now.
AWS and the Linux Foundation are the ones keeping the original Redis, the community project that existed before the business, alive for the benefit of everyone.
Redis Inc. is incentivized to continue the development and improvement of Redis, because the success of Redis is directly proportional to the success of their business. Meanwhile, a shit-hot new open-source KV database could come out tomorrow, and AWS would forget their newfound OSS goodwill towards Valkey in a heartbeat.
I wonder if US monopoly regulation actually starts to work well, which I see some signs of happening, will all this license revert back to fully open source?
Their Walk Out technology original statements and working reality show they find with grifting to prop up their image.
Here is good example of economics. How much is a $25 Amazon gift card worth? Some it many be $25 and others it is $0, and in-between for people looking to off load their gift card for pennies on the dollar.
Redis labs effectively became the defacto owner of the project later down the line when Antirez joined them. They inherited the project then tried to capture all of the value.
This isn’t a case of the original maintainers trying to sustain the project. It’s a hostile takeover that’s backfiring significantly. They brought Microsoft onboard as a partner hoping that would get them through the mess. Turns out that wasn’t enough.
Free Software is the only way
How do you propose AWS “collaborate” with Elastic or Redis Labs under the terms of the SSPL? Also, who do you believe the creators of Redis are?
This is quite simple, and should have happened before these companies decide to switch licenses because of Amazon. Each time Amazon decides to use an open source product, instead of doing it for free, they should contact the parent company and offer them a fee. There are many advantages of such an arrangement: a single version exists, the parent company has a stable source of income etc.
I might be mistaken, but this path was possibly chosen by Citus and Azure, and nobody seems to complain.