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.
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.
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.
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.
Good timing.
There's a lot less incentive for Microsoft to muck about with the license and in that sense it's not really about trust.
Yeah sure.
On one hand I could see why Microsoft would back the original project, since they likely don’t want Amazon owning a replacement (elasticsearch). But I’m not sure how they plan to honour the new licensing?
> Publishing your app as Native AOT produces an app that's self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.
https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
While there are limitations, this is an active area of work for future versions of .NET.
(On the other hand, call me an old fart, but my trust in Microsoft has been completely eroded in early millennium and did not came back.)
The JVM and the .NET clr are just runtime JIT engines. It’s not like they ship with a full O/S and a hypervisor.
And .NET can bundle the runtime, even in a single binary if you prefer that.
Their reasoning[0] for not considering it open source is that due to the requirement that all interfacing software (my words) must also be open source it restricts the possible fields the software can be used in. Reread that sentence! that's exactly the intent of the original GPL license, and follows directly from the philosophy of its progenitor.
If the original GPL was proposed today, then following this reasoning the OSI would not have approved it. Imagine today the Nginx project would switch its license from MIT to GPLv2. Just regular old GPLv2. Would the OSI also complain that previous contributors thought they were contributing towards the "greater good" and now their software is embedded in a proprietary product, just because nginx plugins now have to be open source as well?
The OSI shouldn't be chasing some vague "greater good". They should be protecting the spirit of open source. Which includes copyleft licenses like GPL, AGPL and SSPL.
[0] https://opensource.org/blog/the-sspl-is-not-an-open-source-l...
Its hardly just the OSI. Debian, redhat, FSF all think this license is bad.
> Their reasoning[0] for not considering it open source is that due to the requirement that all interfacing software (my words) must also be open source it restricts the possible fields the software can be used in. Reread that sentence! that's exactly the intent of the original GPL license, and follows directly from the philosophy of its progenitor.
When they say "all", they really mean "all". The exact phrase is: " including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available."
IANAL, and its not 100% clear, but i think this would prevent for example, using redis on a windows server because windows is not open source. What if the hard drive you are using has non-free firmware? Is that allowed? I don't know, but the fact its even a question seems ridiculous here.
In essence, I think this clause is so burdensome, that nobody could realistically comply with it. Thus the license effective disallows that specific purpose. So I agree with OSI's assesment.
Which means if you want to offer it as a service, you can't use it on GNU/linux, since you don't have permission to release it under the SSPL.
edited to add: this could easily be remedied by simply requiring the entire stack to be published under either the SSPL or an OSI/FSF approved license. Such a license (somewhat ironically) probably wouldn't be approved by the OSI/FSF, but it would solve the main issue with it. Although I also suspect the people using the SSPL consider this a "feature not a bug" of their psuedo-open-source licence.
We've been thinking about how we'd discuss large and controversial licenses in a productive way. We're learning how to drive large, productive, difficult conversations with the process towards the Open Source AI Definition[1] and we hope (soon) to be able to transfer that knowledge to other pressing issues, like complex licenses.
[0] https://opensource.org/blog/osi-executive-director [1] https://opensource.org/deepdive
That the communication with MongoDB crashed and left a sour after taste I can imagine. But the fact now is that there's a deeply flawed SSPL out there, OSI's only real public statement is very dismissive of it. It does not address at all the concerns of Elastic or MongoDB, painting them as some sort of bad guys, when in fact their products have always been open source, even when they were so valuable they really didn't need to be.
And the companies that drove them away from what OSI considers open source, are OSI's two biggest sponsors! Two sponsors it is worth mentioning, who built their products entirely as proprietary closed software, on top of open source software.
So now, wether they meant to or not, OSI has profiled themselves as defenders of proprietary platforms, making no effort to acknowledge the plight of open source companies, and lost credibility to such a degree that now again one the great open source companies has dismissed their approval and went for an unapproved license.
If the OSI was really serious about the "greater good", they would have worked with the FSF and helped MongoDB, Elastic and Redislabs defend against proprietary platform companies such as AWS and Google with an AGPLv4 that has the provisions the SSPL introduced without causing the concerns other people raised in this thread with regard to (possibly intentional?) vagueness around what does and does not need to be open sourced.
If that had happened, then maybe today Redislabs would have announced their switch to an OSI approved open source license, and the OSI would have retained its legitimacy and reputation. How many great budding open source/open core projects have been inspired by the success of Redis, MongoDB and Elastic, that now will consider the same path as these companies, or worse, that of Hashicorp?
Certification with OSI
"In 2018, MongoDB submitted the license to the Open Source Initiative (OSI) for approval. The company withdrew its submission in 2019.[19][20] In January 2021, following the re-licensing move by Elastic, OSI released a statement declaring that the SSPL does not comply with its Open Source Definition because it discriminates against specific fields of endeavor,[which?] describing it as a "fauxpen" source license.[7]"
wikipedia links to https://opensource.org/blog/the-sspl-is-not-an-open-source-l...
So it would seem your take is not quite accurate. It's not simply that it was withdrawn, the OSI board of directors has made public statements.
I'd note that the argument made above "discriminating against specific fields of endeavor" is not fundamentally different than other viral copyleft licenses.
While it has a big poison pill, the whole point of viral copyleft statements is about having a poison pill. The GPL arguably discriminates against fields of endeavor (i.e. closed source code, actually preventing it). The SSPL discriminates against cloud service providers by having a poison pill, which in theory, actually discriminates less, as that field is allowed to use it, just the requirements to use it might be to onerous to be reasonable. But there should be no logical difference if its just about "discriminating against specific fields of endeavor".
i.e. it comes down to a value/emotional statement vs a pure logic statement. The value is that cloud providers need to be allowed to use the code without severe restriction, while its ok to prevent closed source products from using the code.
It's fine for the OSI to make decisions that are not purely logical, but are simply about trying to protect the values that they want to push, but they should also be honest about it.
While an open source maximalist might be happy with that ambiguity, if it impedes the use of the software and hence the chance that a broader community of open source will thrive, it arguably backfires... SSPL aims to make explicitly clear that it is in context of building a public service for the software that the copy left provisions of an expectation of open sourcing occur.
The theory is that this allows the software to be more widely used and for the community to benefit when a public service open source project is maintained
If the OSI calls the AGPL open source, surely the SSPL is as well. A lot of people seem to lose the forest through the trees on "free as in freedom" vs "free as in beer" to the extent that copyleft offers a sustainable road to free as in freedom for the community... Unfortunately zealots have shot themselves in the foot without realizing they're doing the strip mining hyperscalers' bidding.
Including the idea that you should be able to pay whoever you want to host a thing, without needing the permission of the authors to do so. While hosted things weren't common back then, the nearest analog is vendors selling you the thing (oh physical media, before widespread internet!), and that was always understood from the start as part of the full spirit and original intent of open source. That anyone could sell you the thing without license from the copyright holder.
Readings from RMS one of the originators of the "full spirit and original intent" of open source are also pretty clear here -- that part of the full spirit and original intent is nobody can tell you what to do with the software or limit what you do with it -- including basing your business on it without license from the author.
The fact that the OSI definition is what it is is also notable. It's not like the OSI definition/requirements/specification have _changed_, it's stayed the same for 25 years. And it was originally taken from Debian! If it didn't cover the original intent and spirit of open source, why weren't many people upset about it way back then? At what point did OSI "lose touch with their mission"... by... _not_ changing the 25-year-old requirements?
The original spirit and intent of open source was never about supporting ways for authors monetize code -- quite the opposite.
That doesn't mean you have to agree, you can have _different_ intent and spirit yourself, and it seems many people agree with you. You can think the original intent was always naive and a mistake. Or you can think times have changed and the original intent that may have worked at one point is not longer useful.
But what you can't do is retroactively redefine the "original intent and full spirit" of open source.
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
See: Enshittification. Totally agreeing with you, but this feels like just another data point to Cory's thesis.
In a few days, a clone called "Libredis" or "Freedis" will probably appear that the community and developers will move to.
So yeah, it might be annnoying buit in the long term it won't matter much anymore (same as the company)
It's such a strange pattern that plays out again and again: developers insist that a permissive license is the way to go, until somebody (or company) they don't like exercises their rights.
Usually what said developers actually wanted was the GPL, because they realise in retrospect that they didn't want the company to be allowed to do this. But they didn't like it because it restricts recipients rights. So they want people to have those rights as long as they never actually exercise them? It's all very confusing.
I say this having contributed to and released my own projects under both permissive and copyleft licenses — based on what I'm actually willing for people to be able to do with the code.
Redis is a 15 years old project started in 2009 by Salvatore 'Antirez' Sanfilippo. He worked on his startup, then at VMWare, them at Pivotal, and only joined Redis Labs (created in 2011) in 2015.
In 2018 Redis Labs changed the license of their modules and Antirez published http://antirez.com/news/120 In 2020 he quit.
Anyway I agree with the conclusion: Redis will be forked, the fork will win and Redis Labs will become irrelevant.
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
Which sounds pretty good and is the complete opposite of what Mongo or Elastic are doing.
> Under the new license, cloud service providers hosting Redis offerings will no longer be permitted to use the source code of Redis free of charge.
So, this is just a money grab scheme because Redis finds it an absurd that cloud providers are offering Redis hosting, in their minds Redis Company should be the only one offering Redis hosting.
Maybe I'm wrong, but I believe this is a shotgun shot to their foot and this will result in Redis dying or even drastically reducing its market-share.
We need new licenses that let developers get more of the pie because no one is benefiting from the GPL in the age of cloud computing. Who cares that Linux is open source when I'm locked in aws and can never leave? What does it matter to users when their data is stolen to train Ai models and they don't even know what's in it?
I have never seen a fork last long enough.
What exactly is the material impact on a developer with this licensing change? There is a tendency these days to sensationalise things without getting to the bottom of it or even reading the whole article.
What did the OSS Redis project promise a developer that it is not going to deliver in the new licensing model?
It is our obligation as developers to communicate to companies if we want these license changes to happen or not. If you don't like it, don't contribute and invest your time into projects that are not licensed in way that matches your needs and wants.
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?
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.
Your view on its impact is orthogonal to this reality. People’s view on this reality is orthogonal to its impact
Personally, I’ve grown tired of this debate. Redis is clearly commercial software. None of my “freedoms” rely on redis, the way they might on more core or primitive softwares like Linux, Bash, or a browser. The real (but non-exclusive) value of the invention lies in commercial applications. I’ll bring out my “it’s not OSS” pitchfork when VI or eMacs changes their licenses. I care deeply about open source software, but not all source code matters.
Contributing is a thankless task that benefits people’s profit driven interests. It’s understandable that contributors would like to try for some of that profit, and this doesn’t seem to be too aggressive either. Yea, the relationship changed, because they were “giving it away” prior. But so what, life is full of changes. There is only a handful of organizations this will impact and they’re all rich corporations that don’t need my pity. The project is mature, so most remaining work is likely feature adds required by mega-scale and niche commercial uses cases, that’s just not work people usually do for fun.
Pardon my aggression - it’s rhetorical- but redis doesn’t need to exist in this world. It certainly doesn’t need anyone’s emotions.
There is still a long tail on this. For example, wikipedia offers a cloud like platform thar people who contribute to wikipedia can sign up for free to, get some web space where they can make small unofficial tools, provided that the tool is somehow related to wikipedia. This includes redis hosting among other things (https://wikitech.wikimedia.org/wiki/Help:Toolforge/Redis_for... ). The license change would probably effect that use case ( the RSAL would prohibit that. The situation with the SSPL is less clear (IANAL))
OSI-defined OSS means "comes with no restrictions, except maybe redistribution", whereas this license adds another restriction (you can't run the software as a service without offering the source, as I understand it). How does this restriction affect us?
It surely can't be that OSS as defined by the OSI is the only good thing, and anything else is horrible, it has to be a continuum. Why is this license so bad, when it only affects AWS? How are my liberties being restricted?
It doesn't really answer anything to say "it's not open source", because that just implies that we already agree on why that's bad.
It might indirectly effect you as some free labour from the open source community might dry up. E.g. your linux distro might no longer package it and you might have to rely on packages maintained by redis which might not be as well integrated into your distro (although lots of users probably don't care about that)
This might be me living in a bubble, but OS packages for this kind of server software really feel like a relic the past.
Containers have been around for a decade and we now have tools like podman that run without privileges or daemons. I run my freakin' Raspberry Pi 4GB as a pure container host, just because it makes the system cleaner and more reliable at almost no cost.
Now I'm sure some people still want to `apt install redis`, for example to squeeze every last ounce of performance out of hardware, and more power to them if that's what gives them the best results.
But Debian maintainers have to do a lot of dull, unfun work to update, test, and bugfix native packages for Redis and Mongo and RabbitMQ and... is that really a good use of their precious, unpaid time? To make the UX and performance only slightly better than 'podman run redis'?
The GNU people fought the good fight on free/libre software, but they lost because companies are greedy and devs are lazy at their day jobs.
Copyleft licenses are limited to the software itself, but SSPL expands this to ”including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software”. If there’s even the tiniest risk of having to comply with that, I’d stay clear of anything SSPL licensed.
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...
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.
If hundreds of commits are baked into a software - under an open source license but without the full copyright transferred to a central legal entity - then it becomes impossible to change the license post-hoc.
3 clause BSD gives everyone permission to use it in new works that are made available using license terms of one’s own choosing, so long as the obligations of those 3 clauses continue to be met.
But what I get from this is: The project switched away from 3 clause BSD to something that is less permissive.
If you care about a software commons, if you care about benefiting from the improvements others make to your own software, if you care about your users benefiting from the improvements others make: use a copyleft license!
This is because Redis is a caching database, and pulls the data into memory for it to be faster. This is by design.
This change means that cloud providers will have to share premium they're charging customers for offering redis as cloud service.
Developers still have access to source code, you can use it personally and for commercial products, you can use it on your cloud VMs, dockers, k8s etc. as before.
The only affected parties are competing cloud providers - they'll have to share their premium.
What's wrong with that?
Sounds like solid way to build sustainable business around open code.
Also putting together all this other stuff into single package (JSON, vector, probabilistic and time-series) sounds great!
I am personally fine with running Redis myself, but I can completely understand the people who don't want to bother with this, and get a hosted version -- and pay as little as possible for it.
Yeah, that’s basically my question: how else do they make money? I’d bet that there’s at least one order of magnitude more people who use any of the major cloud providers’ hosted Redis service than who pay for a support contract, and probably at least two orders more than contribute anything substantial to the open source project. At some point you need recurring revenue or development is going to slow dramatically.
I wonder if they knew that was coming and disagreed. Or knew it was coming and didn't want to take the hit to their reputation. Agree or not with the move, there is a reputation hit. Or was it them leaving that enabled the change to be pushed through?
This is entirely speculation and just something I noticed with Hashi and now see repeat with Redis.
Or had enough sway to prevent it happening before they left?
> just something I noticed with Hashi and now see repeat with Redis
The similarity wasn't lost on me either.
We initially used Redis because, well, Laravel recommends it. But, what I learned is that Redis is not a requirement until you absolutely need it.
For Rails use, 37Signals recently released the open source solid queue package, meant for use with either msyql or postgres. It makes some odd choices, like separating things into different tables depending on state. And it also makes careful use of the not-necessarily-super-well-known (but standard, and in both mysql and postgres) `FOR UPDATE SKIP LOCKED` clause.
These choices were to get good performance at high volumes, which they think they have done and tested.
So it can be done! Probably. And indeed solid queue is MIT-licensed, there are not barriers to looking at the choices they made and copying them in whatever language/platform you want.
But it's not necessarily trivial. At non-huge volumes though it's probably not an issue.
EDIT: Ironically, the SSPL seems to be more open than the copyleft counterpart (AGPL) - the difference is that it enforces releasing the whole service source. Any discussion assuming that the new dual licensing model is hurting the users' freed is actually unfounded.
---
About SSPL (https://redis.com/legal/licenses):
SSPL is a source-available license created by MongoDB, who set out to craft a license that embodied the ideals of open source, allowing free and unrestricted use, modification, and redistribution, with the simple requirement that if you provide the product as a service to others, you must also publicly release any modifications as well as the source code of your management layers under SSPL.
SSPL is based on GPLv3, and is considered a copyleft license. This means that if you use the source code and create derivative works, those derivative works must also be licensed under SSPL and released publicly. For more information, MongoDB has a good FAQ.
Note that SSPL has not been approved by the OSI, and we do not refer to it as an Open Source license.
This makes it sound like it's just a matter of resources or time to just get it approved, which is misleading. Field of use restrictions go against most definitions of open source or free software, and it was on track to be rejected by OSI until they withdrew from the process.
https://opensource.org/blog/the-sspl-is-not-an-open-source-l...
Similarly, Debian also rejected classifying it as open.
There will be almost certainly some OpenRedis project, but this move might just kill the wider community interest.
It's a bit different though, since it was already on a proprietary license, and they just changed the terms.
1. Replication
When using Redis for things like Session storage, a Job Queue, etc it's important that all hosts (web/app servers) see the same data, which means you either need them to all rely on one single server (which introduces a SPOF) or you need to be able to replicate the data, so that when the primary instance has an issue, a hot spare takes up the load with an existing dataset already in place.
2. Lua
This is slightly less important, but it provides a lot of power: systems like Qless (https://github.com/seomoz/qless) use Lua to run a job queue that executes within Redis, so you get atomic writes for free, and you aren't tied to a specific application language to get a usable queue with consistent features/results.
Or in the spirit of YC, is there yarcdis (yet-another-redis-clone-dis) awaiting in the wings?
"Starting on March 20th, 2024" doesn't seem right to me.
"... Redis follows a dual-licensing model with all Redis project code contributions under version 7.4 and subsequent releases governed by the Redis Software Grant and Contributor License Agreement."
So it is tied to version 7.4
The follow-up question would be what allows them to still use the old contributions together with the new proprietary ones and the answer is: the permissive license of the old contributions.
If the old contributors have not wanted that, they should not have contributed to a project under a permissive license.
Nothing IMO.
But many commercial entities won't touch software covered by them, so if wide adoption is one of your desires this could be a significant consideration. You can argue as much as you like about where lines are and how using <component> won't mean they have to open source their entire business, but you'll get nowhere, and the blanket ban will remain. If they really want what your component does they'll do it in-house (and maybe release that under a more permissive licence) or use an alternative if one already exists.
Dual licensing (AGPL with commercial options) usually won't help either: they don't actually want a commercial option because they don't want to pay for things the way they want others to pay their services. Dual licensing can also be an issue for other contributors, it becomes more important to have a CLA⁰ so you can do that at all (legally) and a CLA might put off a lot of potential contributors.
This would not be an issue for me¹², and from your question I assume it wouldn't be for you either, but for some people/projects it could be more important, possibly a blocker.
--
[0] Unless your project is “open source, not open contribution” which is a perfectly valid choice and one I'd likely go for, but again this is not suitable for all people/projects.
[1] “We can't/won't use your stuff under its current licence”. Me: “OK, thanks for letting me know.”
[2] “If you don't do X³ we'll have to go elsewhere”. Me: “OK. Enjoy your trip. Hope it works out for you.”
[3] where X could be a license change or anything else
I only install Redis on Ubuntu VMs. I don't pay for hosted Redis (since it's always been rock solid for me).
Will these changes stop me from running `sudo apt install redis`?
But I would certainly trust the FSF not to change licensing terms (aside from moving to newer versions of the GPL/LGPL) to something unsavory, while the same can't be said of any old random project out there. I think that trust (or lack thereof) is the real issue. Ultimately, though, it's better to just not have to trust; I don't sign over my copyright to projects either, unless it's part of a job and the stuff that I write would otherwise be owned by my employer anyway.
maybe we wait for a few months before making wild statements like this, software is not about chasing the latest hype
- https://github.com/dragonflydb/dragonfly (BSL-licensed, aka not OSS).
- https://github.com/Snapchat/KeyDB (BSD-licensed)
Anyone using one of these?
Did you misread the first paragraph of that wikipedia entry, where it defines the term as pretty much opposite that, or am I misunderstanding what you're meaning?
I think they can manage.
"this definition would include hosting or embedding Redis as part of a solution that is sold competitively"
Sure this limits the condition to competing offerings. However in reality that's a huge stop sign. It essentially means "we'll get you" because whatever service/product you offer that somehow includes or so much as touches Redis they can always argue that you are effectively competing. That is they can always make the case that this would have been business to them if only.
I interpret this as "You can't sell Redis as a Service".
You can make any number of applications that use Redis and host the instances yourself, you just can't package Redis and sell/rent a miraculixx-branded version of it.
I am sorry, isnt this the post itself? Or am I missing something?
Between this non-compete clause of their license:
> You may not make the functionality of the Software or a Modified version available to third parties as a service or distribute the Software or a Modified version in a manner that makes the functionality of the Software available to third parties.
..and this clarification in their FAQ:
> A “competitive offering” is a product that is sold to third parties, including through paid support arrangements, that is derived from the Redis’ code-base and significantly overlaps the capabilities of a Redis commercial product. For example, this definition would include hosting or embedding Redis as part of a solution that is sold competitively against our commercial versions of Redis (either Redis Enterprise Software or Redis Cloud).
It’s pretty clear that any SaaS product simply using Redis as a dependency for a completely different product (e.g. Discourse) is in the clear. But it would be nice if they could spell that out as an unaffected use case.
Making the functionality of the Software or Modified version available to third parties includes (...) offering a product or service, the value of which entirely or primarily derives from the value of the Software or Modified version (...).
Since the value is not _primarily_ derived from using Redis, I guess it's fine. I am sure the majority of projects using Redis in some way do not derive their main value from Redis.
I've personally built a little really bad version with only a fraction of the command a couple years ago for fun.
Amazon can absolutely build a fully API compatible service and have that up in no time. It's just silly to try to do this.
The tech itself is usually not mindblowing.
Imagine I'm independent provider looking to compete with MongoDB Atlas and ready to Open Source everything I need. But oh wait - I have S3 as my Control plane, EBS, AIM etc - none of which I have option to Open Source.
redis the company, wants a part of that pie.
It's the only sustainable way to have business model around open work.
With pure open source licensing you have asymmetry - where a) you guys implement it b) we sell it, thanks - problem. You cannot run sustainable business around it.
As far as I understand it they want to preserve "open sourceness" for self hosted projects - ie. if you run redis in your docker/vm/k8s, you're fine. But if mega corp clouds are offering managed service, they need to give back a cut from premium they're charging end users.
Link - https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/...
Context : Redis Inc (fka RedisLabs) started creating ''Redis Modules'' later known as Redis Stack to start differentiating with cloud provider's managed Redis. The idea was to keep Redis Core BSD licensed (one of the most liberal licensing model) but at the same time build a layer on top of this BSD layer to keep differentiating the service.
One of these modules was Redis JSON which allowed you to use Redis as a JSON store. One cloud provider copied the whole codebase (even though it was protected by all the licensing clauses) and it doesn't stop there. JSON.FORGET was a cool command created by one of the exes at Redis & the ''cloud provider'' ended up copying that command as well!
If you're still debating whether a company should continue with a liberal licensing like BSD only to allow cloud providers or other service providers to blatantly plagiarise the codebase, think again.
BSL is not OSI-approved, but it’s a much more reasonable AWS-resistant license. It’s the same license CockroachDB uses, for example.
KeyDB (BSL, acquired by Snapchat) is also an option: https://keydb.dev/
BSL is a much better license, but it’s a gamble on how long KeyDB will be supported. I don’t want to mess around with such a core part of my architecture.
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)
> Redis remains a proponent of the open source philosophy and maintains a large number of open source projects. For those who wish to contribute, we remain open to accepting future contributions – as we have done with our source available modules over the past five years.Going forward, acceptance of the contributor license agreement (CLA) by the contributor is necessary in order for us to consider the contribution.
So they don't mind changing the license on their code, but they wouldn't want to have to be subject to the same terms from anyone else...
I think by now it is more or less clear it is not the case - the companies that _use_ open source to support their non-software core business are the ones that take most of the pie. There is as little reason for outrage as for surprise in my opinion.
https://en.wikipedia.org/wiki/Redis_(company)?useskin=vector
It's funny and hypocritical that a corporation, which used the very terms of the license they now seem to hate in order to come into existence in the first place, is closing that exact path out.
Did I get it right?
Open source is about building something together for everyone's advantage. We throw our skills into the pot, be it coding, documentation, or spreading the word. The coolest part? When someone takes the software and does something incredible with it, something we never thought of! That's the power of open source – it goes way beyond what any one person can achieve.
Here's the thing: contributing to open source isn't about getting something back directly for your work. It's about building something awesome for the greater good. You put your stuff out there, and someone else might end up building a million-dollar company on it. That's not exploitation, that's someone being really good at using the tool we built together.
YOU SHOULD NEVER EXPECT THE BENEFIT FROM THE CONTRIBUTIONS YOU DO TO A OPEN SOURCE SOFTWARE BUT INSTEAD EXPECT THE BENEFIT FROM THE SOFTWARE YOU ARE CONTRIBUTING TO.
If you need specific control over how your code is used, open source might not be the best fit. There are permissive licenses that let people modify your work as long as they follow your rules.
The bottom line: open source is about sharing and building something bigger than ourselves. Let's celebrate the ways our contributions empower others, not hold grudges because someone else figured out a killer way to use our work.
At Earthly, a few years ago, the founder and CEO had these same concerns about big cloud providers and switched to a source available license. There was backlash, and after around a year, we switched back to open source. We've discussed things like this a lot, and believe an open source license is best for our product, our users, and our business.
The way that we differ from Hashicorp, Redis, and others that have switched to source available licenses is that the service we offer and generate revenue from isn't just a hosted version of our OSS. It's several services that natively integrate with our OSS but are not open source. This seems like one of the only ways a company that maintains popular OSS can survive without switching licenses: build great OSS that users love, build non-OSS services that integrate with and augment your OSS (and/or open up new use cases), and charge for those services.
If the service a company sells is just a hosted version of their OSS, even if it has a bunch of non-OSS bells and whistles added on, that company is at risk of a cloud provider eating their lunch unless they switch to a non-OSS license.
* Open Source Inside Baseball: https://oxide.computer/podcasts/oxide-and-friends/1086076 * Open Source and Capitalism: https://oxide.computer/podcasts/oxide-and-friends/1564203 * Open Source Anti-Patterns: https://oxide.computer/podcasts/oxide-and-friends/1482742
They don't say so explicitly, but it looks like the community-led open source governance model is gone too? Not already discussed on this thread I think.
In 2020 when antirez stepped down, Redis the company explained:
> "As Salvatore steps back from maintaining Redis, the project’s scale can no longer be managed as a BDFL-style project," explained Gottlieb and Agra. "We see this as an opportunity for Redis to adopt a new model that, hopefully, will promote more teamwork and structure and let us scale up its development and maintenance processes."
> As the Redis Open Source Governance page explains, the project aims "to be as welcoming and inclusive as possible" and toward that end has adopted a Code of Conduct, as many other open source projects have already done.
—https://redis.io/docs/about/governance/
It looks like the "Redis Open Source Governance page" used to be at https://redis.io/docs/about/governance/ ?
Currently 404.
Last scraped by archive.org in October. https://web.archive.org/web/20231030181609/https://redis.io/...
It explained there is a "core team". Not all of whom worked for Redis the company, although largely controlled by Redis the company. So I guess it wasn't exactly community-controlled before, but it's notable there is no longer an "open source governance" model.
antirez's good-bye blog post says:
> I leave Redis in the hands of the Redis community… I’ll just leave Yossi and Oran the task of understanding how to interface with the rest of the Redis developers to find a sustainable development model… I believe I’m not just leaving Redis in the hands of a community of expert programmers, but also in the hands of people who care about the legacy of the community spirit of Redis.
I get why Redis would want every contributor to sign this agreement. What I don't understand is why any open source contributor would agree to sign it. Maybe because someone is more interested in getting their contribution integrated than having any say over future licensing of their work?
The reality is large places will take as much as they can and never give anything unless forced into such a deal. Open source tech is probably tainted in this regard. How many other projects have gone this route for basically the same reason?
I hope this means large tech will actually contribute some money to Redis. I've used Redis for many years and hope they can make some money after giving so much away for so long.
They have still not changed meta description on their page. It still says it is open source ^^
view-source:https://redis.io/
That's not a sustainable relationship for a healthy OSS product, mega cloud corps rake in most of the profits whilst the organizations maintaining them have to handle the burden of increasing customer support issues and developer wages.
The SSPL aka "Free for all, except cloud corps" License should be more common place.
I don't necessarily need redis specifically; infrastructure ecosystems just developed around it because it was both very high-quality and open source. I could probably do most or all of what I do with redis with an rdbms. Or in some cases memcached.
I anticipate switching away from redis.
Wikipedia link: https://en.wikipedia.org/wiki/GNU_Affero_General_Public_Lice...
https://redis.com/blog/redis-adopts-dual-source-available-li...
What a shame.
Like others have said, OSI definition of open source is very outdated and needs to be updated.
For my own use in my company or project as an individual
- Can I have full access to the source, clone it and modify it? YES
- Can I do a pull request to improve it? YES
- Am I allowed to download, use and have it for free in my company even if my project is commercial and is making money from using Redis? YES
- Can I create a product that uses Redis as a technology for free in my startup? YES
- Can I get support if I need it? YES from github as before or as a paid service from the Redis company
- Is there a lot of people to maintain and do bug fixes? YES and they are paid a salary to do so
- Is it a me-and-my-cousin project that will be practically abandoned tomorrow? No. Go check a specific fork's multithreading bugs in github issues. It's scary as fk
- Can I git clone / make / make install it like before? YES
- Is there new features added or planned to be added? I guess this is a YES
- Are the people behind the project paid well enough to maintain and support it? I hope so, certainly it's not best effort after working hours and putting the kids to sleep
- Can I resell Redis as a service taking the source code and running it on my cloud without a paid license? NO (boo hoo hoo)
Personally I don't care if the definition is open source or SSPL or whatever as long as the project is open code, viable, well maintained and improved. Some complaints here sound like this is a religious thing, and I dislike religious freaks.
I am able to use this software for FREE in my company like I used to. I have access to the source code and I can modify it as I want. I can have my commercial web service that extensively uses Redis as a cache for FREE as long as I don't sell Redis itself as a service to hosting customers. Where's the real problem? Where's the problem with Mongo / Elastic / Redis and the likes who try to fight against abusive tactics of AWS?
If I must add a redis repo and then do apt update and apt install redis... Do I care? Sure, it's an extra step but c'mon. It's 2024, not the 90s. The world has changed. AWS has been "screwing open source projects for more than a decade" (tm)
Why are we scared to face the harsh reality?
Same with Mongo in 2018 and Elastic when they changed their licenses. Same thing, again and again. Nags and complaints from people that, 95% of them, have maybe contributed a typo change in the docs - if so. But they have an opinion about things that are given to them for free and still are free and open. What makes you so entitled? Have you ever said THANK YOU to any of the open source folks? Have you monetarily supported any of them, ever?
Antirez has 21k followers and 9 sponsors who donate on Github. NINE! Not 10, not 50, not 1000 sponsors... it's 9 - a carpenter that lost a finger at work can still count them... You want good open source? Make sure the projects are sustainable, viable and their creators receive love and positive criticism to continue writing code for free for the greater good.
It's only AWS who cares about the license change, no-one else is really affected in reality.
If you're not employed by AWS and you have an issue with Elastic, Mongo, Redis et al changing their license, then you are a convenient fool (sorry). You are not paying good service to the community and the open source movement in it's CORE. OSI execs are happy getting millions from bigcorps in exchange to bending their ethics and views in decision making.
Mongo's discussions with OSI in 2018 is a prime example of that.
AWS is your enemy, not licenses that try to fight against this bully.
Any company can still use Redis for their needs, only leeches like AWS can't.
