IMHO this is gonna kill Redis Labs just like Hashicorp is getting owned and seeking a buyout, and not stop anyone from ripping off Redis Labs, because the folks who truly suffer from this are the small startups who just want to use Redis cache without legal bullshit, whereas for AWS to fork Redis is doable and they could even turn it around and make their fork permissively licensed which suddenly makes Redis Labs into the worse choice in terms of license.
It’s a hard choice to make, but imho either keep your code proprietary or stick with “Apache OR MIT” … all this stuff about switching licenses partway down the line is really lame and just seems destined to backfire.
Open Source is about user ownership of software. If we try to get around that with legal trickery to make a buck, then it’s not going to hurt the big corpo teams, but rather the users. Big corpo teams are users too, they don’t want to deal with this legal mess either. Like it or not, Redis has always been a permissive open source project which is why it has been a success. Changing that is changing the equation in that regard going forward and portends bad outcomes for everyone involved.
I think this pretty much kills the idea of Corporation being a good stuart of Open Source Software user needs over long term...
We need to better recognize the difference between "Foundation" owned software like PostgreSQL vs Corporation Owner like Open Source. When you focus in "Maximizing shareholder value" the goal of keeping your user freedoms will inevitably be put aside.
It would be much better choice for Redis community if Antirez would seporate his employment from Project ownership and leave it in hands of some non profit. Something like Apache Redis would be much better for community and it also would allow Redis Labs to build proprietary extensions and cloud business around it.
> the goal of keeping your user freedoms will inevitably be put aside
That depends on who you consider the user. If it's the person buying managed redis, then this license change doesn't affect any user freedoms.
I don't know, it feels like this way of doing things doesn't work well, but pure open source also doesn't work well when you want to pay salaries to a bunch of devs.
Over the years I've come to agree with this POV, and distilled it down to this:
If your goal is profit, don't open source your core product.
We've seen this time and time again where a company releases their core software under a permissive license, and then bigger competitors come along and resell a solution redistributing their software.
If the company's central goal is profit, this is an existential threat. However if your company goal is to ensure the software exists (as a non-profit steward), this is a resounding success!
This doesn't apply to software that's secondary to your core product, e.g. a useful tool you've developed but don't make money directly selling to others.
> However if your company goal is to ensure the software exists (as a non-profit steward), this is a resounding success!
That depends on whether those big competitors are contributing code back.
If they are, then great, the code continues to exist as high quality open source, even if you're playing a smaller role.
If they aren't, then the good version isn't open source. Your goal is failing even when you ignore profit. And at that point maybe an "open source except for those guys" license gets you closer to your goal in practice.
> If your goal is profit, don't open source your core product.
Or more fundamentally, don't open source your value prop. Open source your complement. So many OSS shops build a valuable core only to realise their actual business ends up being selling managed servers.
Your "product" is what you sell. The owners of redis labs don't sell redis, they sell hosting, as far as I can see, in which case they made themselves a competitor to AWS, Azure, etc. And they don't have a competitive advantage in that. Also, why should AWS not compete back? Is a hosting company supposed to sit back and watch another hosting company just win business?
> If your goal is profit, don't open source your core product.
It's not hard to create a profitable business on open source and make good money. The question is how much.
If your goal as a founder is to be a billionaire, open source products are not going to do it. You need monopoly-level rents to do that, like Oracle or Snowflake. There's plenty of opportunity to create millionaires. But you'll have to forego VC financing to do it because that math does not work for venture capital funds.
Open Source has a) you guys implement it b) we sell it, thanks problem.
This license change addresses this very problem so cloud mega corps can't leech.
For me it sounds like better AGPL.
I don't give a shit about philosophical nuances and OSI-approved list – at the end of the day this is much less restrictive license than AGPL - I have source code, I can run it locally, I can run it on my projects, I can run it on my commercial projects, I can run it where I work, I can use it on bare metal, VM, Docker, k8s and from Azure the same way.
The fact that Microsoft will have to share cut of the premium they're already charging is irrelevant to me – if anything I applaud for finding sustainable business model around it.
As opposed to leeching from open sourcing your software just to undercut the competitors and then bait and switch into closed source? There's absolutely no problem with wanting to sell your software and being proprietary. But the issue is really that they are a multi million or even billion (hashicorp) who built that value on top of being open source.
They are completely within their right to switch licences but it doesn't mean that we have to fall for the narrative that they are protecting themselves from the big guys. Let's be honest, no one would've used redis or terraform if it was closed source. Or if it wasn't available on the big guys platforms.
Redis started as a community project and had tons of community contributions. I'm sure that their effort to gain fairness for the smaller guys doesn't apply to anyone smaller than them. It's ironic that they did exactly what they imply the big cloud players did, scoop up open-source work to build corporate value
> Open Source is about user ownership of software.
No, OSS developers retain authorship (with the exception of public domain). Only the authors can change the license and terms. Users get a license to do various things with the software/code, but they do not get ownership.
Authors can only change the license if they are the sole authors or if they impose a CLA requiring others to grant re-licensing to the original authors.
A copyleft project with no CLA, levels the playing field so that everyone has the same rights. Eg.: Linux kernel
I'm assuming people are forking this as we speak. Kind of sad to see companies cut themselves off from their own developer communities.
I understand why they do it. I just don't agree it works long term.
Most Redis users have never paid the company behind it even a single cent. Me included. So, I can appreciate them doing this in order to make some money. Except it won't change my behavior; I'll just use the fork. Just like the vast majority of other Redis users, external Redis contributors, all of the cloud providers currently offering Redis commercially, and by the time this runs it course probably a fair bit of current Redis employees.
Given the large amount of commercial users and cloud providers offering Redis, I don't think it will take long for them to get organized even. They pretty much have to given that they have lots of users paying them for this.
There are some precedents with Terraform, Elasticsearch, Red Hat, and a few other big players now dealing with a lot of their target users and potential customers depending on open source forks. As a business strategy alienating future users like that seems misguided.
When Oracle took ownership of Sun's open source projects (including such things as mysql, hudson, openoffice, etc.), they quickly lost control of most of that. Oracle's attempts to convince the world to use their closed source offerings never amounted to much. Even with Java, they more or less gave in and openjdk is where the action is these days. Except for a few banks, very few people use the Oracle JDK. There's no need, Oracle has long ago stopped pretending there's any advantage to that. All the development happens on OpenJDK. There are half a dozen different companies offering certified builds.
Anecdotically, I consult on Elasticsearch and Opensearch. Most of my recent clients default to Opensearch. It's just the way it is. They all go for the free and open source option.
The point here is that this can only end in one way: the creation of a Redis fork that will be used by the vast majority of current Redis users.
Microsoft introduced an almost drop in replacement 3 days ago[1]. It is claimed to work with most Redis clients. I believe this will change things quite a bit a least for Azure users.
There are many drop in replacements (we use keydb), but, depending on the features you use, there are a lot of api compatible (but sometimes lacking features) compatible drop ins. We migrated of a large redis cluster overnight; 0 software changes.
Looks neat, but probably only for internal MSFT usage.
For what it's worth... Microsoft was quoted in the Redis press release as a cloud provider that has partnered officially with Redis under this new licensing scheme.
I think the long term game works if you look at it from a Broadcom style prospective. You're not looking to snag many users but rather the few very expensive ones who have built themselves around the product. From the Businesses prospective they'll pay the increased prices to avoid moving completely or in the short term during migrations.
To avoid the short term, providers could "buy time" and keep prices low until the project deviates far enough from forks, making migration much harder, then increase prices.
Either way, long term they can end up with a lot of money from a few companies rather than continuing to support many mixed sized companies.
Broadcom is able to screw over its customers because they have to choose between either reworking a core part of their infrastructure, running legacy code without support (provided you have a perpetual license), or paying a huge license fee. With Redis, the current version is already open-source: you can maintain it yourself, switch to a drop-in replacement community fork, or pay one of the dozens of SaaS companies to run it for you. Switching away from the official Redis flavor can be as simple as a one-line change in your infrastructure recipe. If they increase their prices, why would anyone stay?
I think MySQL is probably a better comparison. After Oracle's acquisition they have been trying quite hard to add vendor lock-in and extract money out of it, but these days MariaDB has essentially made it completely irrelevant. I wouldn't be surprised if the future of Redis looked quite similar.
What are you talking about? At some megacorp I work at, we had a similar situation where some other braindead product changed its license. Even since, there's, on average, 30% engineering position, maintaining the old deprecated version before the license change.
When it comes to large corps, the prices paid for these products is already so large, because of the scale, that it often times makes more sense to employ your own, instead. These kind of decisions are taken all too often. We'll spend a good few sprints exploring possibilities/mapping differences/POCing to more accurately estimate all these findings and their ROI before deciding. This can also include tough migrations. At a previous megacorp; ELK did a nasty? Migrated to OpenSearch.
I see it ending in another way, long term FOSS will be considered a phase in the industry, never to be repeated again, as the industry settles back on trial and demo versions, without full features available on the free tier/source code.
That might make sense if the tools in question were created by corporations who used OSS as a pseudo demo.
Redis the project/tool existed long before Redis the company owned it.
Vagrant existed before HashiCorp owned it.
Significantly: both companies dropped permissive licensing after the creator of their (original) products stepped away, and both are venture capital backed companies.
So we could just as easily say "I see that long term people will preemptively fork projects the moment they are owned by a VC backed company"
I think it comes down to is the project there to make money or not. If it's mainly for money then it would never start out open source (ie AWS) but if it's a solution to a problem that can be improved via collaboration then it'll be Open Source (ie OpenStack). This hasn't really changed over the years.
What we are seeing here, as others have pointed out, is that companies are buying Open Source solutions and then close sourcing them because they view it as a money maker which in the end leads to forks.
I doubt that. What has been proven clearly in the industry is that FOSS works excellently as a way for businesses to collaborate on common infrastructure. Linux is by far the biggest success in this area, but there are also things like Kubernetes, clang, Python and others.
What does not work, not long term, is trying to build a business around selling a FOSS solution - RedHat is probably the only notable exception here. But having multiple companies invest in a common tool that they all use as part of their infrastructure has worked wonders.
Cynical take: Oracle didn’t need MySQL to be a profit center since it already offers a much more expensive alternative. They enjoyed good ROI by fragmenting the MySQL community, chilling usage and external development, and therefore slowing down the whole project.
MySQL is used as upsell, when it can't take the requirements any longer, there is Oracle RDMS over there with a nice upgrade deal discussed over lunch.
> Most Redis users have never paid the company behind it even a single cent. Me included.
Most users never will. That's the fallacy made by MBA types. They dream up some lofty sums "if only everyone paid us money". What they don't realize is that most users will find alternatives.
And Redis as a company can get some cash from certain amount of clients that decided to stick with Redis (even in Oracle's case, this was a non-trivial amount of money)?
For personal projects maybe yes, doesn't work for companies, they can't chase for thousand different forks of Redis and try to understand why feature isn't working properly on their version. Unless single fork emerges as a winner
Why would there be thousands of forks? We only need one good one.
I'm predicting such a fork backed by several core committers, and possible several cloud providers will emerge pretty quickly because they all need this to continue to exist as free and open source. AWS is not going to pay Redis a cent. Nor is Azure. Or Google. Or people commercializing open stack. All of those offer Redis support currently. Lots of their users use it.
Revenue through hosting continues to be the big driver for all of these projects, which is what is motivating the license changes.
The trend indicates that only open source libraries work for companies that own projects. If it's a program (e.g. server software like a database) then it's either source available or under a foundation. It's tough and I don't know what the answer is here.
I'd love to see a model that causes the pendulum to swing back the other way with open source permissive licenses for complex programs, but I don't see a viable way yet. Maybe trademark enforcement and open source code only with licensed builds?
Either way, I'm sure we'll continue to see the rise and fall (or license change) of popular open source software for years to come. There's too much benefit for developers and companies to start out open source. And there's too much pressure later on to change it.
At the very least, I'll give Redis credit for giving far more value to the world than they've captured. By an absolutely massive margin.
It'll be interesting to see how long a fork takes to land and if it'll be successful. And it'll be interesting to look at Redis (the company)'s revenue growth curve in 5 years.
> Revenue through hosting continues to be the big driver for all of these projects, which is what is motivating the license changes.
Yeah, isn’t this just massive cloud providers eating the lunch of Redis etc? I don’t know enough about the licensing but I highly empathize with these small-mid sized companies building foundational tech that is commoditized and upcharged by an oligopolistic cloud behemoths. Surprised it's taken this long.
Question: what other alternatives than license changes are there, assuming we want a healthy ecosystem of both businesses and open source?
TimescaleDB has an open core style license that seems to prevent the cloud services from repackaging their DB.
It's not technically fully open source, but it's pretty close to it.
Actually, I just took another look and they now market their "open core" as the apache edition (or perhaps have diverged from the "community edition" now)
Personally, I don't find foundations to be a magic solution for this problem. There are many examples where a single company has decided to basically "fork" their way out of foundation housing and the community is left with the same outcome.
It would also help that many developers would acknowledge that we are no different from other professionals, expecting to be paid for our own work, while not wanting to give a dime for the work tools doesn't scale.
Those producing work tools also have bills to pay.
In a way, developers themselves are to blame for the failure of the FOSS dream.
Slowly we are back to the public domain/shareware days.
I can't see how you can shoulder the blame of (possible) failure of FOSS dream on developers. Devs (usually) don't control budgets and can't really ask for money to pay for freely licensed code. If blame is to be given then I'd point to money handlers for not acknowledging this situation.
Then there's the question of what I should be paying anyway. Who among all those non-free developers are paying in turn to all the professionals whose code they build on? Are proprietary developers somehow exempt from paying themselves? If and when I choose to pay I like to think all that contributed are getting the benefit.
There's a long line of professionals behind every code that should have been paid. Certain percentage might have tried to get paid. And even some who in fact did get paid.
Developers are entirely to blame - the fraction of developers meaningfully contributing to FOSS or advocating for supporting it is tiny. Just ‘import foo’ and holy smokes - free shit, yes please!
People always said that the model for making money off open source is support - some company uses e.g. Postgres and they require specialists to help them out and put out fires in their on-prem setup.
But in the age of the "Cloud" companies will simply use the managed offering provided by Amazon/MS/Google/etc. basically destroying any financial opportunities for the maintainers and other people around the project. Also nobody wants to work their ass off on some OSS just to see AWS raking in milions off it without contributing back anything.
Disclosure: I work for Amazon, but I don't work directly on Redis related cloud services. I am close to the Open Source Program Office, and I care a lot about the people who do the hard work required to collaborate on open source projects.
Madelyn Olson did the hard work for years to earn the trust of other Redis core developers to become a core maintainer, all while employed by AWS to do that work. She and other AWS developers have contributed a lot to the core Redis engine. Some may say that they too worked their asses off for the Redis community.
I think most people are aware of the occasional contributions from the behemoths. Sometimes, entire projects. But charity is not a sustainable business model. When you provide a service offering the marginal returns go to the provider. In the B2B world, that’s a golden deal for these companies. Normally, you’d have a rev share or something like it. So it’s very understandable there’s a shift in the industry. It’s probably for the better for everyone.
This is like seeing an employee of Philip Morris pointing out that they have employees volunteer to tell kids how smoking is not healthy or like when British Petroleum funds research on green energy... I'm sorry but you're a cog in a machine which is fine but we have structural problems at play here that can't be swept under the rug
The work was still on the behalf of AWS and their goal to make money and out compete Redis. it seems like this thread is forgetting that?
The alternate future seems to be a headline like "Redis shuts down and stops development" anyway, so how is this different?
What do you think Redis should do? Continue to let the cloud providers run them out of business? And all because Amazon was gracious enough to fund 1 employee working on it? I think this thread is missing that response.
More Open Source projects should adopt SSPL, or experiment with LLama 2 style limitations on the size of companies which may use the work for free (for example, Open Source but not if you're a multi-billion cloud megacorp). When individual developers contribute back, they weren't doing it to enable AWS to freeload.
AWS of course is the single biggest reason why projects are flocking to more restrictive licenses. The right thing to do for AWS would have been to respect the work of the original authors (/company) and throw their weight behind an offering supported by the original developers. Instead, AWS builds a competing product when they see an OSS product succeeding. Third party vendors stand no chance after that due to the tighter integration and marketing muscle.
Not to mention, Amazon and AWS give so little back to Open Source despite being a big (the biggest?) beneficiary. Google, Microsoft and even Oracle do more for Open Source than Amazon.
I am fine with SSPL and AGPL as long as there is no CLA which makes me sign me rights over to someone else. I have never contributed to a project with a CLA and unless an employer pays me for it I do not think I ever will.
I certainly won't sign CLAs to entities like IBM (Eclipse/RHEL) or Oracle. But I did willingly sign a CLA for the Apache Software Foundation. I didn't enjoy doing it, but at least they're a force for good.
SSPL + no CLA: we don't want anyone to profit from the hard work of our volunteer contributors
SSPL + CLA: we don't want anyone but us to profit from the hard work of our volunteer contributors
If you want to dual-license your software, dual-license it from the people that helped write it, or treat their contributions as work-for-hire from the very beginning
Some time ago I tried to argue for a FOSS license that would disallow code from being used by AI. I got a lot of negative feedback saying that this wouldn't be FOSS because it imposes restrictions etc. The same is true for the SSPL. But for long term FOSS viability, I think we may need to impose some restrictions to protect ourselves from big bad megacorps who effectively exploit FOSS developers.
I am still not entirely convinced that "disallowing code from being used by AI" is going to hurt megacorps in the long run - or the individual.
I guess plenty of people have already made their own call on this matter but I'm still genuinely undecided. As much as the megacorps are rushing to rule the AI roost - it's possible it will turn out to be a universal solvent to some degree.
But I'm also pretty lukewarm about AGPL and SSPL. I feel there's a huge amount of fragmentation in open source land and I'm often unable to use code in situations where I feel the original creator would probably have been ok with it.
What does code being used by AI have to do with "big bad megacorps who effectively exploit FOSS developers?" I don't see any connection there, while I do see it for something like SSPL.
It's a semantic thing and I agree with the feedback - specifically with the "F" in FOSS. That sort of license would be Open Source but not completely Free (as in freedom, not beer).
> AWS of course is the single biggest reason why projects are flocking to more restrictive licenses
Don't forget that AWS is one of the biggest reasons so many OSS projects became popular. Redis, Mongo, ES, HashiCorp stuff, a complete big data ecosystem, got wider recognition through AWS's offering. Many people have yet to learn about dozens of obscure databases (that have been in development for years) simply because AWS or other big cloud providers have not pushed them.
Also, many projects receive a lot of contributions (bug reports, PRs, patches) due to liberal licenses increasing their use and popularity. I'm not particularly eager to contribute to anything with SSPL/BSL/etc-like licenses simply because I don't want to waste my time on something I can't use liberally in the future.
Aws not offering it does indeed make it harder to adopt, especially if you have to have additional billing contracts with an additional business party, have to validate their certifications (soc2, etc), customer data sharing agreements, etc.
There’s a difference between developer popularity, and ability to actually use it in commercial product. If AWS provides a commercial alternative out of the box available within existing contracts and certifications, adopting that is low friction.
That’s highly unlike my experience: each of those tools was popular first - the AWS offerings were recognizing widespread customer use. You couldn’t go to a meetup without someone handing out ES or MongoDB stickers by the time AWS decided that was a market worth being in.
I do agree there’s some value in wider use but developers have to get paid. If users are paying someone who doesn’t contribute much to the upstream codebase at some point the project is going to founder. I don’t love the change as someone who’s been using open source for decades but the maintainer problem is real and won’t go away without structural changes.
Also, with AGPL-style license Redis will not become less popular. Anyone still will be able to use it as a cache, but not as a free work done by others that you can resell without contributing back.
Other commentators have already pointed out that this is probably not true.
But MongoDB relicensed before Amazon could launch a direct hosted offering and it is the biggest of all these projects. It did not want nor did it need Amazon launching a hosted variant.
People are forgetting that Redis became big exactly because of it being both free and open. If Redis came out with limitations similar to LLama 2 it would have been dead in the water since the main consumer is enterprise, while LLama 2's primary popularity is because it was one of the first to provide a high quality LLM to individuals for personal use. A KV store that's compatible with RESP is nothing particularly special, shoot Microsoft just released their own (garnet) under an MIT license. The value of Redis was always it being both free and open source and the community that supported it. As of now they just dropped the biggest reason to use Redis.
> The right thing to do for AWS would have been to respect the work of the original authors (/company) and throw their weight behind an offering supported by the original developers
That's what they do in some cases - their managed Grafana and Prometheus are a cooperation with Grafana Labs. But it's the only one I'm aware of, practically all other ones (MongoDB, Redis, Memcached, MySQL, PgSQL, etc.) aren't.
Look more closely and you'll see that they offer a competing service right next to it... it's about the most anti-competitive posture you can imagine as they slowly corrode their foundation
> AWS of course is the single biggest reason why projects are flocking to more restrictive licenses
Should be general competition, including AWS, right? AWS does not host a Terraform service, yet HashiCorp feels the pressure from quite a number of competitors that offer Terraform as a service.
Open-source still has a long-term advantage. Long-term, either AWS goes out of business, “enshittifies” their “enhanced” version, and/or open-sources it themselves. Meanwhile, the open-source version never goes away or gets worse: at worst it will bitrot, but that’s only if nobody is using it enough to put in the bare minimum of maintenance (then when AWS inevitably degrades, there’s a good chance someone makes an open-source rewrite).
I guess but AWS is the one being a good steward of actual open source software. It's hard to say they're the evil ones when it's because of them we still have an OSS ElasticSearch for anyone to use as they please.
No one forces you to make OSS, you can be closed source from the beginning and no one will fault you. But companies releasing OSS as a growth hack because it's seen as a donation to the software commons and then rug pulling deserve every fork coming to them. Debian and Fedora don't include JSMin (not that it's relevant anymore but still) because the license says you can't use it for evil making it not OSS.
That's what OSS means -- everyone, even the worst person you know, especially the worst person you know, can use the software for anything they want.
Redis Inc. is moving the https://github.com/redis/redis/ project away from the three part BSD license to a dual license using two non-OSI approved license. This comes after previous comment from them saying that "... the Redis core license, which is and will always be licensed under the 3-Clause- BSD". (https://redis.com/blog/redis-labs-modules-license-changes/)
For those worried about EOL, Redis 7.4 will be the first release under the new license, leaving 7.2 as the last release with the old one. Redis supports 2 additional releases at a given time: latest major.(minor-1), (major-1).(last-minor).
This roughly means that 6.2 will go out of support once 8.0 is released, and 7.2 will go out of support once 7.6, or 8.0 is released.
Looking at prior releases, my guess would be to expect a 8.0 release around Mar-May 2025. So if you're relying on Redis under the 3BSD license, plan accordingly.
Note that Ubuntu packages redis under the `universe` repo, which means security upgrades are only available to Ubuntu Pro customers. So Ubuntu 20.04 will stop redis upgrades on Apr 2024, except for Ubuntu Pro users under ESM.
Debian 11/12 track Redis 6.0/7.0, so they are responsible for backporting the patches from 7.2. Unsure how this will happen once 7.2 stops receiving security updates, and they only go to the 7.4 branch.
Also note that you might be impacted indirectly (even if your usage of redis fits with the new license), because your distro will likely drop redis from its official repos in the next release, so should account for that in the next distro upgrade cycle.
(I maintain https://endoflife.date/redis, happy to merge PRs if someone has clarity on how this might impact EOL/Support)
That's the point of open source, and free software in a way as well. Copyleft licenses have restrictions, but as long as you follow those restrictions, you can build whatever you want using the software. SSPL, FSL, BUSL licenses outright prevent you from competing in certain commercial ways, no matter what.
Just because most business models don't want to comply with copyleft doesn't mean it's not open source - it just means it doesn't fit your business model.
You can also build whatever you want with SSPL, as long as absolutely everything you use to run a service that supports it is also licensed as SSPL. It's not that different from the AGPL in spirit.
IMO we need new terms for that kind of stuff. New licenses such as SSPL, BSL FSL are becoming more and more popular, and for very good reason (the conditions today are vastly different than they were 20 years ago when there was no AWS to resell your FOSS to the whole world). They are not "open source" because of the restrictions, but the next closest term that can be applied to them is "source available" which means something different - source code is technically there, eventually, and is not reflective of the reality of those relicensed projects. ElasticSearch, Sentry, etc. are still developed in the open, random people not affiliated with the project can still submit PRs, and anyone not trying to compete publicly with the company behind the project can still do whatever they want.
> the conditions today are vastly different than they were 20 years ago when there was no AWS to resell your FOSS to the whole world
No, its not. SaaS has existed for more than 20 years and reselling FOSS has been something it has done as long as there has been FOSS to resell.
What's changed recently is people launching venture-funded startups centered on gaining popularity through the appeal of FOSS with initially no clear monetization plan or one centered on selling services that were essentially just the FOSS, hosted. That’s the new thing, and why there is so much energy going into trying to figure out how to retain the marketing appeal of FOSS with the new licenses that lack the value proposition of FOSS.
Readit News
It’s a hard choice to make, but imho either keep your code proprietary or stick with “Apache OR MIT” … all this stuff about switching licenses partway down the line is really lame and just seems destined to backfire.
Open Source is about user ownership of software. If we try to get around that with legal trickery to make a buck, then it’s not going to hurt the big corpo teams, but rather the users. Big corpo teams are users too, they don’t want to deal with this legal mess either. Like it or not, Redis has always been a permissive open source project which is why it has been a success. Changing that is changing the equation in that regard going forward and portends bad outcomes for everyone involved.
We need to better recognize the difference between "Foundation" owned software like PostgreSQL vs Corporation Owner like Open Source. When you focus in "Maximizing shareholder value" the goal of keeping your user freedoms will inevitably be put aside.
It would be much better choice for Redis community if Antirez would seporate his employment from Project ownership and leave it in hands of some non profit. Something like Apache Redis would be much better for community and it also would allow Redis Labs to build proprietary extensions and cloud business around it.
That depends on who you consider the user. If it's the person buying managed redis, then this license change doesn't affect any user freedoms.
I don't know, it feels like this way of doing things doesn't work well, but pure open source also doesn't work well when you want to pay salaries to a bunch of devs.
If your goal is profit, don't open source your core product.
We've seen this time and time again where a company releases their core software under a permissive license, and then bigger competitors come along and resell a solution redistributing their software.
If the company's central goal is profit, this is an existential threat. However if your company goal is to ensure the software exists (as a non-profit steward), this is a resounding success!
This doesn't apply to software that's secondary to your core product, e.g. a useful tool you've developed but don't make money directly selling to others.
That depends on whether those big competitors are contributing code back.
If they are, then great, the code continues to exist as high quality open source, even if you're playing a smaller role.
If they aren't, then the good version isn't open source. Your goal is failing even when you ignore profit. And at that point maybe an "open source except for those guys" license gets you closer to your goal in practice.
Or more fundamentally, don't open source your value prop. Open source your complement. So many OSS shops build a valuable core only to realise their actual business ends up being selling managed servers.
It's not hard to create a profitable business on open source and make good money. The question is how much.
If your goal as a founder is to be a billionaire, open source products are not going to do it. You need monopoly-level rents to do that, like Oracle or Snowflake. There's plenty of opportunity to create millionaires. But you'll have to forego VC financing to do it because that math does not work for venture capital funds.
This license change addresses this very problem so cloud mega corps can't leech.
For me it sounds like better AGPL.
I don't give a shit about philosophical nuances and OSI-approved list – at the end of the day this is much less restrictive license than AGPL - I have source code, I can run it locally, I can run it on my projects, I can run it on my commercial projects, I can run it where I work, I can use it on bare metal, VM, Docker, k8s and from Azure the same way.
The fact that Microsoft will have to share cut of the premium they're already charging is irrelevant to me – if anything I applaud for finding sustainable business model around it.
They are completely within their right to switch licences but it doesn't mean that we have to fall for the narrative that they are protecting themselves from the big guys. Let's be honest, no one would've used redis or terraform if it was closed source. Or if it wasn't available on the big guys platforms.
Redis started as a community project and had tons of community contributions. I'm sure that their effort to gain fairness for the smaller guys doesn't apply to anyone smaller than them. It's ironic that they did exactly what they imply the big cloud players did, scoop up open-source work to build corporate value
No, OSS developers retain authorship (with the exception of public domain). Only the authors can change the license and terms. Users get a license to do various things with the software/code, but they do not get ownership.
A copyleft project with no CLA, levels the playing field so that everyone has the same rights. Eg.: Linux kernel
Deleted Comment
See: Enshittification. Totally agreeing with you, but this feels like just another data point to Cory's thesis.
I understand why they do it. I just don't agree it works long term.
Most Redis users have never paid the company behind it even a single cent. Me included. So, I can appreciate them doing this in order to make some money. Except it won't change my behavior; I'll just use the fork. Just like the vast majority of other Redis users, external Redis contributors, all of the cloud providers currently offering Redis commercially, and by the time this runs it course probably a fair bit of current Redis employees.
Given the large amount of commercial users and cloud providers offering Redis, I don't think it will take long for them to get organized even. They pretty much have to given that they have lots of users paying them for this.
There are some precedents with Terraform, Elasticsearch, Red Hat, and a few other big players now dealing with a lot of their target users and potential customers depending on open source forks. As a business strategy alienating future users like that seems misguided.
When Oracle took ownership of Sun's open source projects (including such things as mysql, hudson, openoffice, etc.), they quickly lost control of most of that. Oracle's attempts to convince the world to use their closed source offerings never amounted to much. Even with Java, they more or less gave in and openjdk is where the action is these days. Except for a few banks, very few people use the Oracle JDK. There's no need, Oracle has long ago stopped pretending there's any advantage to that. All the development happens on OpenJDK. There are half a dozen different companies offering certified builds.
Anecdotically, I consult on Elasticsearch and Opensearch. Most of my recent clients default to Opensearch. It's just the way it is. They all go for the free and open source option.
The point here is that this can only end in one way: the creation of a Redis fork that will be used by the vast majority of current Redis users.
[1] https://www.microsoft.com/en-us/research/blog/introducing-ga...
For what it's worth... Microsoft was quoted in the Redis press release as a cloud provider that has partnered officially with Redis under this new licensing scheme.
To avoid the short term, providers could "buy time" and keep prices low until the project deviates far enough from forks, making migration much harder, then increase prices.
Either way, long term they can end up with a lot of money from a few companies rather than continuing to support many mixed sized companies.
I don't like it either but I can see it working.
Broadcom is able to screw over its customers because they have to choose between either reworking a core part of their infrastructure, running legacy code without support (provided you have a perpetual license), or paying a huge license fee. With Redis, the current version is already open-source: you can maintain it yourself, switch to a drop-in replacement community fork, or pay one of the dozens of SaaS companies to run it for you. Switching away from the official Redis flavor can be as simple as a one-line change in your infrastructure recipe. If they increase their prices, why would anyone stay?
I think MySQL is probably a better comparison. After Oracle's acquisition they have been trying quite hard to add vendor lock-in and extract money out of it, but these days MariaDB has essentially made it completely irrelevant. I wouldn't be surprised if the future of Redis looked quite similar.
Invariably, someone looks at the numbers and realizes "We could make way more money if we only catered to the top 2% of our customers!"
Unfortunately, opinions and needs of the top 2% of customers != a generally useful product.
Thus, the reason to try and maintain user volume is better product-market feedback to guide development, instead of revenue.
When it comes to large corps, the prices paid for these products is already so large, because of the scale, that it often times makes more sense to employ your own, instead. These kind of decisions are taken all too often. We'll spend a good few sprints exploring possibilities/mapping differences/POCing to more accurately estimate all these findings and their ROI before deciding. This can also include tough migrations. At a previous megacorp; ELK did a nasty? Migrated to OpenSearch.
So, hard no on your take.
Redis the project/tool existed long before Redis the company owned it.
Vagrant existed before HashiCorp owned it.
Significantly: both companies dropped permissive licensing after the creator of their (original) products stepped away, and both are venture capital backed companies.
So we could just as easily say "I see that long term people will preemptively fork projects the moment they are owned by a VC backed company"
What we are seeing here, as others have pointed out, is that companies are buying Open Source solutions and then close sourcing them because they view it as a money maker which in the end leads to forks.
What does not work, not long term, is trying to build a business around selling a FOSS solution - RedHat is probably the only notable exception here. But having multiple companies invest in a common tool that they all use as part of their infrastructure has worked wonders.
Most users never will. That's the fallacy made by MBA types. They dream up some lofty sums "if only everyone paid us money". What they don't realize is that most users will find alternatives.
It sounds like a win-win to me.
Dead Comment
For personal projects maybe yes, doesn't work for companies, they can't chase for thousand different forks of Redis and try to understand why feature isn't working properly on their version. Unless single fork emerges as a winner
I'm predicting such a fork backed by several core committers, and possible several cloud providers will emerge pretty quickly because they all need this to continue to exist as free and open source. AWS is not going to pay Redis a cent. Nor is Azure. Or Google. Or people commercializing open stack. All of those offer Redis support currently. Lots of their users use it.
The trend indicates that only open source libraries work for companies that own projects. If it's a program (e.g. server software like a database) then it's either source available or under a foundation. It's tough and I don't know what the answer is here.
I'd love to see a model that causes the pendulum to swing back the other way with open source permissive licenses for complex programs, but I don't see a viable way yet. Maybe trademark enforcement and open source code only with licensed builds?
Either way, I'm sure we'll continue to see the rise and fall (or license change) of popular open source software for years to come. There's too much benefit for developers and companies to start out open source. And there's too much pressure later on to change it.
At the very least, I'll give Redis credit for giving far more value to the world than they've captured. By an absolutely massive margin.
It'll be interesting to see how long a fork takes to land and if it'll be successful. And it'll be interesting to look at Redis (the company)'s revenue growth curve in 5 years.
Yeah, isn’t this just massive cloud providers eating the lunch of Redis etc? I don’t know enough about the licensing but I highly empathize with these small-mid sized companies building foundational tech that is commoditized and upcharged by an oligopolistic cloud behemoths. Surprised it's taken this long.
Question: what other alternatives than license changes are there, assuming we want a healthy ecosystem of both businesses and open source?
It's not technically fully open source, but it's pretty close to it.
Actually, I just took another look and they now market their "open core" as the apache edition (or perhaps have diverged from the "community edition" now)
Like the AGPL3?
https://spdx.org/licenses/AGPL-3.0-or-later.html
Those producing work tools also have bills to pay.
In a way, developers themselves are to blame for the failure of the FOSS dream.
Slowly we are back to the public domain/shareware days.
Then there's the question of what I should be paying anyway. Who among all those non-free developers are paying in turn to all the professionals whose code they build on? Are proprietary developers somehow exempt from paying themselves? If and when I choose to pay I like to think all that contributed are getting the benefit.
There's a long line of professionals behind every code that should have been paid. Certain percentage might have tried to get paid. And even some who in fact did get paid.
That isn't open source.
It is open source if the source code is available under an open source licence.
For example, OpenJDK is licensed under the GPL and Oracle provides licensed builds, but that does not make OpenJDK not open source.
But in the age of the "Cloud" companies will simply use the managed offering provided by Amazon/MS/Google/etc. basically destroying any financial opportunities for the maintainers and other people around the project. Also nobody wants to work their ass off on some OSS just to see AWS raking in milions off it without contributing back anything.
Madelyn Olson did the hard work for years to earn the trust of other Redis core developers to become a core maintainer, all while employed by AWS to do that work. She and other AWS developers have contributed a lot to the core Redis engine. Some may say that they too worked their asses off for the Redis community.
You can read more about some of those contributions here: https://aws.amazon.com/blogs/opensource/behind-the-scenes-on...
The alternate future seems to be a headline like "Redis shuts down and stops development" anyway, so how is this different?
What do you think Redis should do? Continue to let the cloud providers run them out of business? And all because Amazon was gracious enough to fund 1 employee working on it? I think this thread is missing that response.
Deleted Comment
AWS of course is the single biggest reason why projects are flocking to more restrictive licenses. The right thing to do for AWS would have been to respect the work of the original authors (/company) and throw their weight behind an offering supported by the original developers. Instead, AWS builds a competing product when they see an OSS product succeeding. Third party vendors stand no chance after that due to the tighter integration and marketing muscle.
Not to mention, Amazon and AWS give so little back to Open Source despite being a big (the biggest?) beneficiary. Google, Microsoft and even Oracle do more for Open Source than Amazon.
SSPL + no CLA: we don't want anyone to profit from the hard work of our volunteer contributors
SSPL + CLA: we don't want anyone but us to profit from the hard work of our volunteer contributors
If you want to dual-license your software, dual-license it from the people that helped write it, or treat their contributions as work-for-hire from the very beginning
I guess plenty of people have already made their own call on this matter but I'm still genuinely undecided. As much as the megacorps are rushing to rule the AI roost - it's possible it will turn out to be a universal solvent to some degree.
But I'm also pretty lukewarm about AGPL and SSPL. I feel there's a huge amount of fragmentation in open source land and I'm often unable to use code in situations where I feel the original creator would probably have been ok with it.
Don't forget that AWS is one of the biggest reasons so many OSS projects became popular. Redis, Mongo, ES, HashiCorp stuff, a complete big data ecosystem, got wider recognition through AWS's offering. Many people have yet to learn about dozens of obscure databases (that have been in development for years) simply because AWS or other big cloud providers have not pushed them.
Also, many projects receive a lot of contributions (bug reports, PRs, patches) due to liberal licenses increasing their use and popularity. I'm not particularly eager to contribute to anything with SSPL/BSL/etc-like licenses simply because I don't want to waste my time on something I can't use liberally in the future.
There’s a difference between developer popularity, and ability to actually use it in commercial product. If AWS provides a commercial alternative out of the box available within existing contracts and certifications, adopting that is low friction.
I do agree there’s some value in wider use but developers have to get paid. If users are paying someone who doesn’t contribute much to the upstream codebase at some point the project is going to founder. I don’t love the change as someone who’s been using open source for decades but the maintainer problem is real and won’t go away without structural changes.
Also, with AGPL-style license Redis will not become less popular. Anyone still will be able to use it as a cache, but not as a free work done by others that you can resell without contributing back.
Other commentators have already pointed out that this is probably not true.
But MongoDB relicensed before Amazon could launch a direct hosted offering and it is the biggest of all these projects. It did not want nor did it need Amazon launching a hosted variant.
That's what they do in some cases - their managed Grafana and Prometheus are a cooperation with Grafana Labs. But it's the only one I'm aware of, practically all other ones (MongoDB, Redis, Memcached, MySQL, PgSQL, etc.) aren't.
Should be general competition, including AWS, right? AWS does not host a Terraform service, yet HashiCorp feels the pressure from quite a number of competitors that offer Terraform as a service.
Deleted Comment
No one forces you to make OSS, you can be closed source from the beginning and no one will fault you. But companies releasing OSS as a growth hack because it's seen as a donation to the software commons and then rug pulling deserve every fork coming to them. Debian and Fedora don't include JSMin (not that it's relevant anymore but still) because the license says you can't use it for evil making it not OSS.
That's what OSS means -- everyone, even the worst person you know, especially the worst person you know, can use the software for anything they want.
This roughly means that 6.2 will go out of support once 8.0 is released, and 7.2 will go out of support once 7.6, or 8.0 is released.
Looking at prior releases, my guess would be to expect a 8.0 release around Mar-May 2025. So if you're relying on Redis under the 3BSD license, plan accordingly.
Note that Ubuntu packages redis under the `universe` repo, which means security upgrades are only available to Ubuntu Pro customers. So Ubuntu 20.04 will stop redis upgrades on Apr 2024, except for Ubuntu Pro users under ESM.
Debian 11/12 track Redis 6.0/7.0, so they are responsible for backporting the patches from 7.2. Unsure how this will happen once 7.2 stops receiving security updates, and they only go to the 7.4 branch.
Also note that you might be impacted indirectly (even if your usage of redis fits with the new license), because your distro will likely drop redis from its official repos in the next release, so should account for that in the next distro upgrade cycle.
(I maintain https://endoflife.date/redis, happy to merge PRs if someone has clarity on how this might impact EOL/Support)
https://opensource.org/definition-annotated#6
That's the point of open source, and free software in a way as well. Copyleft licenses have restrictions, but as long as you follow those restrictions, you can build whatever you want using the software. SSPL, FSL, BUSL licenses outright prevent you from competing in certain commercial ways, no matter what.
Just because most business models don't want to comply with copyleft doesn't mean it's not open source - it just means it doesn't fit your business model.
No, its not. SaaS has existed for more than 20 years and reselling FOSS has been something it has done as long as there has been FOSS to resell.
What's changed recently is people launching venture-funded startups centered on gaining popularity through the appeal of FOSS with initially no clear monetization plan or one centered on selling services that were essentially just the FOSS, hosted. That’s the new thing, and why there is so much energy going into trying to figure out how to retain the marketing appeal of FOSS with the new licenses that lack the value proposition of FOSS.
Some folks are working on terminology over here, if you're curious.
https://github.com/softwarecommons/softwarecommons.com/issue...