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.
OSS is a great way to build a community, increase adoption, and get attention. It isn't perfect at that, but it beats alternatives, for devtools at least.
But then you need to make money (especially if you've taken VC).
That's when the problems start. It's hard to make money on OSS unless you are using it as a complement to something you can sell. Especially in the age of hyperscalers.
And, as other posts indicate, switching from OSS midstream burns any goodwill you had when you started, and opens you up to forks.
It's not unique to OSS, though. Even devtools that cost money or are free but not OSS run into issues making money. Devs are a hard audience to sell to, in my experience. I know I am stingy.
no, devs aren't hard to sell to. It's business owners that are hard to sell to.
If you are running a business, every cost needs to be controlled for you to be profitable. Adopting open source is a form of cost control.
The problem of OSS is that the value proposition is that it is free-as-in-beer (as well as all of the benefits of OSS). So if/when the software becomes not free-as-in-beer, the company will have to reconsider, or change, or eat the cost if the cost is lower than the value generation of the software.
The value of open source is that I don't have to waste my time negotiating contracts to license the software, I can make improvemwnts and customizations to it, I don't have to accept changes from upstream that are detrimental to my business, and no one can take it away from me.
Open Source may also be less expensive, but I am paying with some combination of time and efort and support contracts or other service and sponsorships.
It very much does. If I'm buying Managed Solution I want to have a choice of multiple providers which are free to innovate and compete. If they have to have agreement with vendor we have situation no different than hosted Oracle
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.
Contributing code back alone doesn't help, if there isn't any sustainable source of income, those devs aren't going to pay supermarket and the landlord with the pull requests from big corp.
Yes? I don't see the issue here, except that old observation that entities built to solve a problem almost never want to shut down once the problem is solved.
> 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?
> And they don't have a competitive advantage in that.
Sure they do. As the original authors of the product, they should have the best understanding of its features, and are in the best position to augment it in ways other pure hosting competitors can't or won't. They have first-mover advantage to build novel features, and integrate them into commercial propositions that benefit their customers first. They should also know best how to deploy and scale the product, even if their competitors excel at this.
If Redis Labs wasn't able to compete with AWS and other pure hosting providers, then they failed at taking advantage of their position. This is not an indication that the open core model can't be successful for both OSS users and the business. E.g. see Grafana.
Of course, this also depends on the nature of the product. A general purpose database or another core infrastructure product is much more attractive for hosting competitors than a purpose-built product.
> 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
You can't if your offer directly competes with redislabs - ie. you are cloud provider and you're selling redis as a service. You have to share your profit margin with them through licensing in this case.
not having read the license (and not a lawyer), i dont know how far or direct it must be for it to be considered directly compete. Surely it's a very blurred area, which would then be rife with risk for anyone to adopt redis from now on.
If your product is open source, then you choose SSLPv1 and you're safe.
If your product is closed/commercial, then you choose RSALv2.
You probably want to look at RSALv2 [0] instead of SSLPv1. It's very short, plain and simple.
With RSALv2 you're safe as long as your product is not a wrapper/database aimed at developers that just exposes redis internals. If it does that then you need to enter agreement with Redis Labs to share your profit margin with them.
Ie. if documentation for your offering redirects users to redis docs for usage of your product – you can't use RSALv2 because you're directly competing with Redis Labs with your offering.
This means cloud providers are directly impacted, not usual businesses that USE, not OFFER redis.
And frankly, that's the way it should be. This is the way to do sustainable, source available, open source compatible (through SSLPv1) business model.
> If your product is open source, then you choose SSLPv1 and you're safe.
If I choose a dependency that's SSLPv1 licensed, my product is no longer open source.
> If your product is closed/commercial, then you choose RSALv2.
From the limitations section of the RSALv2:
> 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.
What does this even mean? The functionality of Redis is to store data and then make it available on request (typically over a network), therefore this clause means I'm not allowed to use it in any system which exposes the capability of storing data for end users and making it available on request. For example, a product that allows a user to set some preferences.
If it doesn't mean that, why isn't the licence more specific?
> With RSALv2 you're safe as long as your product is not a wrapper/database aimed at developers that just exposes redis internals.
It's delightful that you infer this. However, this is not what the licence says.
I stand corrected for this sentence saying that SSLPv1 is open source license, it's not OSI approved [0], even if people using it claim it's open source (it was created by MondoDB IIRC and adopted by others).
From user's perspective it's open source. From provider's perspective it's not. OSI doesn't distinguish between those two, there is only user, which can be ordinary end user or provider. Because for provider it's not open source, it can't be approved OSI license.
For RSALv2 "Software" and "Modified" is not "software" and "modified". It's capitalized because it refers to terms that are provided in "Definitions" section. From there you have:
Modify, Modified, or Modification: copy from or adapt all or part of the work in a fashion requiring copyright permission other than making an exact copy. The resulting work is called a Modified version of the earlier work.
Redis: the Redis software as described in redis.io.
Software: certain Software components designed to work with Redis and provided to You under this Agreement.
Plain and simple.
It's also plain and simple to see why those things are created in the first place. It's because open source has problem with cloud where big players not involved with the project cash out on it by simply selling it as is (as managed service) and by doing it they also automatically strip original authors from any chances of competing.
This effort is targeted solely on cloud providers so original authors of the project get a chance at having viable, sustainable business model.
It's not targeted at users. It's targeted at providers.
SSLPv1 was added into dual licensing to allow open solutions to allow to exist – ie. projects that extend redis but don't monetize on it.
ps. OSI doesn't have (or will ever have?) licenses that are compatible with this new era of cloud providers because it equates end user with cloud provider. This is wrong and people will have to invent new adjectives/nouns to describe what they mean by open source contribution + not allowed to leech on us (compete with us through cloud offering without giving us a cut).
> For RSALv2 "Software" and "Modified" is not "software" and "modified". It's capitalized because it refers to terms that are provided in "Definitions" section. From there you have:
Notice how they deliberately don't define "service" or at any point specify "the functionality of the Software".
> It's because open source has problem with cloud where big players not involved with the project cash out on it by simply selling it as is (as managed service) and by doing it they also automatically strip original authors from any chances of competing.
This is, quite obviously, highly subjective. I (and many others) don't think there's a problem, VC-backed companies think there's a problem. Go ask (for example) the Linux, Postgres, Memcached or any of the CNCF folk about whether there's a problem.
> It's not targeted at users. It's targeted at providers.
Providers are also users.
> OSI doesn't have (or will ever have?) licenses that are compatible with this new era of cloud providers because it equates end user with cloud provider. This is wrong and people will have to invent new adjectives/nouns to describe what they mean by open source contribution + not allowed to leech on us (compete with us through cloud offering without giving us a cut).
It's also pretty insulting to the thousands (millions?) of open source projects that choose to adopt an OSI-approved open source licence to suggest that they somehow don't understand what they're doing or are "doing it wrong".
If you're worried about not getting a cut when cloud providers use your software to make money.... don't release it under an open source licence. This isn't hard?
> If you're worried about not getting a cut when cloud providers use your software to make money.... don't release it under an open source licence. This isn't hard?
End use != provide.
Open code, open contributions, open non-commercial applications matter.
It's a simple 2 dimensional space on:
Usage(Use, Provide)
Setting(Commercial, Non Profit)
With single false cell on Provide & Commercial.
Copyright holders should be allowed to choose this option. I don't see why the whole fuss about why not.
If you don't want to use it on your copyrighted work, don't.
You seem extraordinarily sure that the definition of "provider" or "provides a service" (or even "end user") is universally and objectively understood by all, and yet you can't point me to the place where Redis (or anyone else) spells this out. Curious.
> Copyright holders should be allowed to choose this option. I don't see why the whole fuss about why not.
I agree. As long as they define their terms. Redis haven't. That's the point.
It's clearly stated in Definitions section (for Modify, Modified, or Modification).
It draws clear distinction between merely USING the software in its original form and ADAPTATION or DERIVATION that requires copyright permission.
It plainly, simply and directly implies that using it is fine and distributing modifications is not. It also says that unmodified version is fine to distribute commercially ("... other than making an exact copy").
There is a real, non-negligible cost to dealing with even baseless lawsuits. With that said, essentially any decent insurance company will usually be able to price that risk into a shockingly-low cost policy for you (think <0.1% of at-risk revenue).
There is no problem with baseless lawsuits in this case.
It's plain and simple distinction between USE and PROVIDE.
Users don't care.
Providers are upset because they can't leech on this work anymore and have to share their cut with upstream.
From user's perspective it's open source.
From provider's perspective it's not.
ps. as a user I also do care about the fact that upstream has found sustainable business model because it means people on the payroll working on it while I can freely use it, inspect and contribute to the code. Frankly I don't want more from open source. I even like it more than SQLite's Public Domain which does not allow upstream contributions.
> 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"
Free software existed long before mass investment by VCs. The business arguments for open source existed long before the low-interest-rate period.
We are probably not going to see mass investment by VCs in free software for awhile (perhaps never, but that is pretty strong), but developers will keep scratching our itch.
And maybe more and more developers and users will realise that AGPL/GPL/LGP are the only licenses which truly protect one’s software.
> maybe more and more developers and users will realise that AGPL/GPL/LGP are the only licenses which truly protect one’s software.
I don't think this is a fair assessment of the cause of the issue with redis, or hashicorp, or elasticsearch etc;
This wasn't some nefarious third party taking all the community good will and contributions and creating a private fork to kill the original projects.
If you don't want some corporate asshole to turn your open source project into a get rich quick scheme, don't give control of your project to that asshole.
> because they didn't had to pay anything, while the tool maker's salaries were being burned by VC money
I think you somehow missed the point where Redis the project existed and was extremely popular before it was owned by what is now Redis the company.
The competition for redis in the early days wasn't paid alternatives, it was other open source alternatives; Redis just provided a more featured solution.
Which people adopting Redis didn't had to pay for, if they had to, they would rather suffer with those other less capable open source alternatives instead.
The point is that it wasn't developed by VC money. It was bought with VC money after the fact.
It wasn't a "demo" for a paid product funded by corporate dollars or VC funding, it was just a thing that someone created, and released as an open source project.
It's hilarious that you think the companies dropping open source licenses for the products they bought are going to stop the industry using open source. As I said originally, it's going to have the opposite affect: it's going to make the industry embrace the very nature of open source and create forks of projects, the moment there's a sniff of a corporate buy out, specifically because of this type of activity.
The question here is what motivates individual developers to write big projects and then release them as open source. I think vague dreams of million-dollar deals are part of this for a lot of people. As the developer community becomes more aware of what a grind open source maintainership is, people are already less interested in taking on that responsibility. If we also prevent big money buyouts from happening, I wonder what's left to motivate a future developer to create the next redis.
We basically need to see the big users of these projects hiring staff to contribute to the fork and destroying the original project for that to work well i think. We need to invalidate the business model of "buy opensource project, be a giant asshole" by causing billions of losses t( vcs and proving there is no mote like there can be buying closed source before thia bs goes away.
We need to normalize the idea that if a company uses something open source they automatically get someone to contribute to the project. That couple be hiring people in house to maintain it, it could be paying a consultant, it could be donating to a charity that maintains it. Probably some other way as well. However if you are a company getting value from open source you really need to put some money into keeping it maintained.
The above applies to private people as well. You use how many different pieces of software, what are you doing to ensure they stay maintained. (if you are like most nothing...)
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.
so the original owner of said OSS being sold is making money by selling it to this company (who might be told, or is sold the idea that said OSS could be monetized).
This is no different to a startup making their own acquisition the end goal.
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.
Yes, massive corporations who nevertheless don't want to take on the burden of developing a solution of this magnitude alone, or that want network effects so that their suppliers can't sell them bespoke solutions.
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)?
People are not using open source for the hippie philosophy. They are using it because it is free (as in beer), but even more importantly: they are using it because non-free licenses are a terrible pain in the ass.
Legal aspects are a headache, and the amount of effort to get someone in your company to pay even a tiny amount for some library or service is a serious hurdle.
I would not be surprised if adopting a non-free library would take a typical company ~40 man hours of work. At current rates, that translates to quite an expensive license.
Just getting open source adopted in my company takes around 10 man hours, and that is for something like a compiler that is only for internal use. If we will ship/expose it to customers we do due dalliance that probably amounts to 40+ man-hours to verify we can accept the license terms for that use and that the project doesn't have some hidden license issue (someone copied in code with a different license, link to something with a different license...).
Getting close source is even more work though - now we need someone to negotiate license terms (that is make sure our proposed use is compatible with the license we buy). We also make sure there is no risk of using their code (what if the closed source binary library has some AGPL3 code in it). I'm not even sure how to go through that process.
That may be true, but a lot of the creators of open source do in fact do it for the "hippie philosophy." That disconnect will eventually kill it. Why work hard to just be free labor for SaaS companies and people who don't care about you?
The problem I’ve seen historically is when a company is founded around one project or ecosystem.
Someone like Microsoft or Google could take software like this, pay the original developer, and still see tons of ROI offering it as a canned cloud service. And to a certain degree they don’t care about the profitability of that 1 thing if it helps sell the rest of their system. Quite honestly, they won’t care about competition using it if it’s already common. People want X, they’re using it, you can offer it. You’re paying a handful of people for street cred, a guarantee it will continue to work well with your stuff, and input into direction.
Folks like RedisLabs, MongoDB, Hashicorp, etc. think they can do the same with a marketplace offering. But they’re reliant that the particular product is profitable on its own. They’re also reliant on the cloud customer being willing to establish another relationship with another vendor, even when they can automatically deploy and bill through their existing provider.
We’ve seen folks behind OSS projects hop from company to company over time and the project continues to thrive. I haven’t seen a company restrict a license and the project do so… at least that I can think of. I might be wrong.
No. I think part of the value of Redis to date was exactly that it was BSD licensed. When I started using it, I showed many other developers what they could do with it, and those devs took Redis to work, and built products and some bought services/products from Redis. Without the open source product, Redis the company would likely not exist as it does today. Times change, and the right strategy for Redis the company probably looks a lot different than when they started it on the back of Antirez's still awesome software.
After reading about the situation that Lasse Collin was in with xz before their mental health problems were exploited by a likely state actor I'm 100% not fucking apologizing for using that word to describe how unpaid maintainers of critical open source software are being treated. It is more or less fucking appalling and if I have to use shocking language to get the point across I absolutely fucking will. And I'm tired as fuck of how we can't use any strong language to talk about situations that demand strong language because some theoretical person might take offense to it. This is fucking bullshit and needs to change, and we need fewer language gatekeeping assholes who aren't making anything better. So sick of this shit.
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.
Easy, there is no need to try to use every tool under the Sun.
Do as we did before the GNU days, analyse what really matters for a specific project development, pay for those tools, and keep using them until they aren't suitable any longer.
Ha. I'm not sure your remark really responds to my concerns. I do use very small set from all the things. And do pay (small amount, I admit) money to some of them.
If I choose to pay for a tool and the tool maker doesn't pay for their tools, then how much better off we are? I can't really see this next iteration of non-GNU ecosystem faring that much better if only few benefit.
And for that matter, I did pay money for non-free tools. And bought Linux on those CDs distributors used to sell. Then the free-er ones somehow got better, so that revenue stream had nowhere to go. As I said, there's no easy way to pay for free stuff.
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.
The beef I have here is that Redis also takes credit for community work. Most of the heavy lifting came from antirez, who created and ran the project up until 2020. (It's worth conceding that Redis did compensate antirez). At that time Redis created an open governing board that took over, with a majority of contributions coming from the community during this time (~25% of contributions came from Redis engineers, ~75% from the community, including ~3% that came from me personally). They own the trademark and the repository, so they can do what they want, but I take issue with the optics that this is really AWS or GCPs or some other vendors fault that Redis decided to blind side it's development community. Redis gave some of us a heads up this was happening, but most people are finding out by a blog post that Redis dissolved the previous open-governance (a fact they barely address in the blog post). We had to drop weeks of work on the floor because we could not longer finish it.
The core team has the following remit:
* Managing the core Redis code and documentation
* Managing new Redis releases
* Maintaining a high-level technical direction/roadmap
* Providing a fast response, including fixes/patches, to address security vulnerabilities and other major issues
* Project governance decisions and changes
* Coordination of Redis core with the rest of the Redis ecosystem
* Managing the membership of the core team
It seems clear to me (speaking only for myself) that the core team didn't have a say in project governance decisions and changes here. :-(
I’m obviously talking about corporate FOSS contributions overall, not any individual contributor. There’s also a difference being on FAANG payroll vs maintaining without financial stability, which is the reality for most FOSS maintainers.
They get paid for it. Don't try to spin this as if it's someone people working on it in their spare time out of the goodness of their heart. It's just their job.
Amazon simultaneously wants to be "part of the community" but also extract the maximum amount of profit via AWS. Amazon can just do a deal with Redis to share a percentage of the profits from their Redis usage. They don't have to, but they could. But no, they insist on having it for free, and we should be grateful that benevolent Amazon with their $23 billion operating income (from AWS) deems Redis worthy for a contributor or two (which is of course entirely in their own interest). Give me a break.
Amazon Inc. wants to maximize profits. Okay fair. I'm not against capitalism. But it holds others to a different standard by insisting they only (not Amazon) should be beholden to some different type of post-capitalist post-scarcity "let's all share together in community" type of model and cries crocodile tears when they model of extracting the maximum in profits while giving the minimum in return blows up in their face. You reap what you sow.
Amazon needs to either hold everyone to the same standard as they have for themselves or stop whining.
> They get paid for it. Don't try to spin this as if it's someone people working on it in their spare time out of the goodness of their heart. It's just their job.
No, you can't have this both ways. I'm the main contributor from AWS, and I've worked many times on weekends because I care about open source. I like helping people, I don't need to be paid to do it. Many of the AWS folks that made changes were normal engineers that were excited to be part of Redis. https://github.com/redis/redis/pull/10419 and https://github.com/redis/redis/pull/8621 are both examples of features someone from AWS built in their free time. We're all upset about this. Not because Redis deserves to get paid, it's that they acted like they were being good stewards of the open-source community and then they changed their mind.
I'm sure you do, but that changes nothing about the problematic nature of Amazon's relationship with a lot of projects it interacts with, which is really what this is about: "Amazon thinks that by throwing some contributions at a project offsets for depriving a project of its main revenue". Well, it doesn't. My landlord and Tesco doesn't accept code contributions as payment. This is why this keeps happening again and again with all sort of projects. You reap what you sow.
> My landlord and Tesco doesn't accept code contributions as payment
Your landlord and Tesco aren't an open source project.
If for instance I get paid $X to specifically work on Redis by Y. The open source project now has effectively a full time engineer they aren't paying for, one that likely would not be a full time engineer for redis otherwise.
You cannot have "Amazon engineers contribute to redis" and "Amazon pays redis $X every month" and Amazon is only an example here, it could be Costco or IKEA or whatever.
So your argument is that instead of having OSS contributions from some of the best engineers in the world, redis (and other now OSS software) should compete with FAANG to pay those engineers.
Guaranteed one of the FAANG companies would just develop the tools internally instead if paying redis.
> You cannot have "Amazon engineers contribute to redis" and "Amazon pays redis $X every month" and Amazon is only an example here, it could be Costco or IKEA or whatever.
Wouldn't be better for both Redis, community and OSS movement if
1) Redis was fully OSS
2) AWS has a deal with Redis Labs were they share some X% of the revenue of their income for managed Redis (ElastiCache)
3) Redis Labs with that revenue can hire more maintainers
3a) Redis Labs with that revenue can pursue a competitive offering to ElastiCache (booom!)
4) AWS can still hire their developers and try to make them core maintainers to steer Redis development into implementing features they want/need
It's really impossible for me to paint AWS as the good citizen here and Redis Labs as the villain.
EDIT: I also wonder what history would have been if antirez started or moved to an AGPL3 licensing early on.
All this hinges in redis being a for profit with OSS software and not competing with AWS, that isn't happening though AWS won't happily fund their competitors and definitely wont contribute developer time to it.
Redis is partly where it is because of large FAANG companies contributing to redis, that cannot be discounted.
I don't have the time but go strip out all commits from FAANG companies employee and see if redis would be the product it is currently.
I'm not saying AWS is right but at the same time that is what redis decided to allow when they used the model they did. Now that they see they could be making a ton of money they want to retroactively change their licensing which is arguably also bad.
It's a money grab both ways which is what I have an issue with.
I'm pretty sure we will see AWS fork redis just before the license change and keep developing from there. They could even also then have all new code be proprietary as far as the current license allows that.
My argument is the industry in general is probably going to be worse of after this move than before.
> Redis is partly where it is because of large FAANG companies contributing to redis, that cannot be discounted.
Redis is offered as a managed offering by AWS and other because it was already very popular between developers that were clients or potential clients of cloud vendors. That it is/was used also by FAANG companies doesn't change a thing in this part of the story. (And no, I don't believe Redis is popular because it was used by FAANG companies which also contributed back)
AWS has no problem with running and contributing to AGPL projects. This entire wave of taking OSS closed started with Mongo switching away from AGPL for the same reasons that Redis is doing it today.
All of these companies trying to sell OSS are unhappy that AWS is competing with them on maintenance. AWS is more or less fully living up to the ideals of OSS - they share the code, they contribute to the core, they share processes and so on (to a greater or lesser extent). That's why the FSF or SFC have no problems with AWS.
However, these companies don't want to collaborate with AWS on building Redis or Mongo or whatever. They want AWS to be their customer, or at least to stop being their competitor. And FOSS has never been about preventing others from becoming your competitors.
> All of these companies trying to sell OSS are unhappy that AWS is competing with them on maintenance. AWS is more or less fully living up to the ideals of OSS - they share the code, they contribute to the core, they share processes and so on (to a greater or lesser extent).
Can you point me to the code describing some of the secret sauce used by AWS? If AWS was a real good OSS citizen, they would use FLOSS software and create FLOSS automation to operate it at scale, no? We have hundreds of such tools out there: Linux kernel, IPVS, keepealived, HAProxy, Kubernetes etc etc etc. These are all plumbing that are FLOSS. Why isn't AWS publishing their own plumbing as FLOSS so I can potentially run a mini-AWS in my datacenter?
I was only talking about their Redis service or Mongodb service. As far as I know, they are sharing their contributions as required by the license (or even beyond, in the case of Redis' former BSD license).
> instead of having OSS contributions from some of the best engineers in the world, redis (and other now OSS software) should compete with FAANG to pay those engineers.
This already happens. Amazon is never the main contributor. That blog post talks about 33 commits for MariaDB for 2023. Like, that's great and all, but that project doesn't run on those 33 commits. It's the same with Elastic; when they did their license change I looked a bit at the commit history, and something like >95% was by Elastic.
And all these projects that did license changes are fine.
> At that time Redis created an open governing board that took over, with a majority of contributions coming from the community during this time (~25% of contributions came from Redis engineers, ~75% from the community, including ~3% that came from me personally).
So, while I believe you're true in the general case, you appear to be wrong about Redis in particular.
I question whether AWS is depriving Redis of their revenue. You just can’t pay every single open source author for their work, too much overhead in maintaining all the contracts, especially if the software is offered as a service. You need the billing in place, certifications, support contracts, data sharing agreements, etc. As a company you want to optimize the number of business partners you have to deal with, and this is the value AWS offers, not Redis.
Who is this ‘we’ - you are speaking about people who want the good bits of redis but not the responsibility of helping it sustain a business model built on open source? Your enabling of AWS’s corporate FOSS-washing hasn’t helped redis sustain the model you want it to.
>We're all upset about this. Not because Redis deserves to get paid, it's that they acted like they were being good stewards of the open-source community and then they changed their mind.
I'm an open-source zealot and I have no beef with the SSPL.
Redis is still an open-source project for 99.99999999999% of entities on Earth. The only people crying foul about this are tech giants and the corporate drones at the OSI. Sorry if this sounds harsh, but normal people don't care about either of you.
I'm not going to shed a tear for your trillion $ market cap company being asked to contribute a little more in exchange for all the wealth they siphon from the rest of the world.
If the tech giant you're cheerleading for is such a fan of open-source, why don't they open-source the management layer like the SSPL asks? This would resolve this beef overnight, right?
The SSPLv1 has fatal flaws that were identified by the open source community during its review for OSI approval. Some of those flaws were attempted to be addressed in the SSPLv2 draft that was never finalized, which is an acknowledgment that the flaws exist.
There isn’t really any way for someone who wanted to offer software licensed under SSPLv1 to comply with the obligations of the license in good faith. This is what makes those obligations a “constructive restriction” [1].
There are some conditions that don't fit with the OSD (in the view of some, opinions are divided). That's fine. It's allowed to have licenses that don't fit with the OSD. These licenses are not flawed in any objective sense.
The important thing here is that distributions are gonna start moving the packages to non-free repos or removing it altogether. So you'll have to get it as if were a closed source project anyways.
There is no spin here. There are people that work for Amazon that work on FOSS projects out of the goodness of their heart, just like folks who are independent developers, or folks who work for startups, or folks who are just getting started.
When a FOSS maintainer tells you they sometimes do work on the weekends for the love of the community [1] you believe them. The evidence (with timestamps!) is there for all to see in the pull requests and commit history.
I think the industry's criticism of AWS is understandable, msw. I believe it is time for AWS to come up with a more sustainable method to support the open-source community. By sustainable, I mean financial support and dedicated resources for contributing back to open source. Given your position, I hope you can initiate this type of change. Allocating 0.5 or 1% of AWS's revenue or even profit from each service that utilizes open-source software is unlikely to significantly affect the financial statements, yet it would represent a significant contribution to the open-source community.
What I meant is a systematic approach to review and reconsider the support mechanisms for all of AWS's current open-source offerings, including those that AWS uses behind the scenes but does not disclose to the public, not just a few services or examples.
Countering a criticism of how Amazon interacts with the projects it uses to drive a large section of its profit with "don't dimish the work FOSS maintainers!" absolutely is a spin. Or some other bad-faith behaviour. It sure as hell isn't a meaningful engagement with the core issues, is it?
> There are people that work for Amazon that work on FOSS projects out of the goodness of their heart
So they work for free then?
Didn't think so.
They just have a job they like. That's great. But lots of people have jobs they like. And lots of people work on weekends. But don't try to spin this as an act of altruism, because it's not.
Without denying the good intentions and inputs of the individuals going above and beyond to contribute - AWS as a whole contribute peanuts to these projects relative to what they make from them - they have it in their power to make these projects sustainable via healthy revenue sharing but don’t.
You write as if you have all the facts, but I doubt you do.
There are services with varying partnership terms, and there have been services launched with an intent to build long term mutually beneficial relationships that help ensure FOSS projects are well resourced.
“AWS, working with Grafana Labs, will be contributing licensing revenue and code to help make Grafana even better, not just for the AWS service, but also for open source users and Grafana Cloud customers.”
You’re just showing your ignorance of redis. The project is sustainable without the company as the vast majority of work on the project is done by those who don’t work for the company.
What isn’t currently sustainable is the company. That’s all.
In that case you will have to excuse my conflating this special case with the multitude of other projects the same thing has happened to in the past and will likely continue happening to. I will watch with interest on how the contributors self-organise and prevent the exact same thing happening to whatever fork comes out.
RedisLabs actually was a somewhat hostile takeover of the project by a complete outsider. It commercialized Redis prior, kept trying to trademark the project name, change the company name to RedisDB to confuse users. A few of those attempts were halted by antirez and the community, but after they had thousands of customers he relented. At the time he complained about his own financial challenges and reluctance, but it gave him a just reward at the cost of legitimizing RedisLabs. The history of that company was always as exploitive to Redis OSS and feigning being good citizens. While you may be right in general, this is actually a case of those exploiting OSS winning.
> They get paid for it. Don't try to spin this as if it's someone people working on it in their spare time out of the goodness of their heart. It's just their job.
I know devs doing exactly this today. Devs who when the actions of their employer would have forced them to diverge from being able to do so, stuck to their convictions so much that they chose to terminate that employet contract so they could continue to do exactly that "in their spare time out of the goodness of their heart."
I will fully admit that I am not that kind of individual, I lack the capacity to contribute meaningfully in that way, but there are certainly many out there in our industry who are.
So when cloud providers like AWS are contributing to an open source project that they also host, I wouldn't call it "charity". The self-interest is obvious.
The problem is that it may not match the self-interest of other contributors. Especially when there is a "main" company that owns the IP of the open source that is not them.
But note how Amazon forked ElasticSearch when it became no longer open source, to their "OpenSearch" OpenSearch is Apache-licensed. Amazon engineers maintain it. This is not charity exactly, Amazon makes money from selling hosting of it.
In the "classic" age of open source, most projects were collaborations, where different people who got paid by differnet employers worked on it on company time, because their employers used it for their operatons. And were willing to pay to contribute to the software they used. Most of these were not in the business of selling software. They did not expect to make direct money from their contributions to the software.
This is how apache httpd began for instance. I think some of the employers of contributors were non-profit as well.
I think that's actually the only sustainable model for open source. A single company paying people to develop open source software and hoping to make money from that -- was probably never actually sustainable.
If the current economic conditions don't support people working on the clock to contribute to open source software that their employers use -- because software has gotten too complex, or because companies have gotten much more stingy or unwilling to pay for such things -- then indeed we won't have much open source anymore, we'll have proprietary source-available licenses like this.
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.
No, the goal was to make Redis better for its community, which has positive downstream effects for everyone (users, Redis as a service providers-including Redis Ltd, etc.)
And these efforts involved more than one developer. It is only that one of them happened to be a core team member (which required working in good faith for the interest of the Redis community as a whole—a “commitment to the project”).
On the “downstream” side of this equation (managed services), the goal is to build a business that delights customers to the point where they part with their money to enjoy it. The ultimate goal there is naturally revenue and profit margin oriented, but _how_ you advance that goal matters a lot. In my experience, focusing on the customer first increases the chances of success.
When such a line of business has a core component that is open source, the growth and health of the “upstream” project, its developers, and the user community is an essential component in its continued success. This is why folks on the ElastiCache team has been increasing their investments in both the upstream project code and in helping to maintain it as a “community-led” project under the previous governance structure.
Those investments increased the provision of digital public goods (as open source licensed software is generally considered to be a “digital public good” even if it is not technically in the public domain). Increasing the provision of digital public goods is generally seen as in service of the public good, as it (more often than not) makes the world a better place.
I think I agree with someone else in this thread. This reads like spin and fluff. We all make quality improvements when we use open source software because we run into our own issues. Were also on a hacker forum, you don't need to respond to me like were at some business partner meeting.
What do you want redis to do though as they are run out of business by amazon and the rest? Who pays for the rest of the developers?
It reads like Amazon is trying to bully their code supplier. The code was out there, and without negotiating Amazon decided on their own "one developer sending TLS upstream seems fair". I'm sure amazon will negotiate with Redis for some amount in the end. Or have the one developer write the drop in replacement if the code is only worth one persons time and some other random commits? Then maybe Amazon can even open source it with no restrictions?
Do you at least see and understand the perspective, that giant companies are making tons of money off software that is out there from smaller people. Giving back what is perceived not that much if anything?
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.
If you simply believe "CLAs are bad", you're missing the point (unless you refuse all legal documents on principle, or something).
The question is: WHO are you signing the CLA over to?
If it's a for-profit company, well, then do you trust that company to follow through?
If it's a non-profit, then look to see (in the US) if they're a 501(c)(3) public charity, which have legal restrictions on their governance, which typically require serving some larger public good. Also look at their history of past governance. I certainly hope (as an ASF peep) that we've shown who we are to be who we plan to be in the future; namely producing software for the public good.
Key reasons the ASF uses a CLA are protecting the org from future IP issues, and partly simply to be able to fix some future typo or legal issue in our license if one ever comes up. But the ASF will always provide all of it's released software under a similar style permissive license to Apache-2.0, as long as the organization is around.
If they're a 501(c)(6), then they're a business league, and might act more like a for-profit corporation, so...
It's important to remember that FOSS contributions are on a voluntary basis. When I have to sign paperwork, things start to feel like unpaid work.
Signing legal documents requires disclosure of personal information. Most CLAs require full legal names and often the names of employers. While Elric is my legal name, I prefer not to disclose my last name for a variety of reasons. Being able to commit to FOSS on a pseudonymous basis is impossible when CLAs are involved, which I think is a real shame.
I understand that orgs want to protect themselves, but CLAs only protect orgs, and can potentially harm contributors. Now, I happen to trust the ASF, and I hope my personal information is safe with them.
There are, roughly speaking, two types of countries when it comes to names. One kind (like the UK) where you decide on your name and the government has to comply with it (after minimal paperwork and minimal expense). And the other kind (where I live) where your name is more or less set in stone after your birth, where it is subject to the whims of the approving official, where it is difficult and expensive to change at best, and sometimes impossible to change.
I'll refrain from going off on a naming tangent, but that stuff is wild.
Which defeats the purpose, because then your pseudonym is legally tied to your IRL identity in a way that may, depending on jurisdiction, be public or semi-public record.
> the ASF will always provide all of it's released software under a similar style permissive license to Apache-2.0, as long as the organization is around.
What makes you think that? What stops a few "evil" people from getting on the board and changing the mission in some way and then changing the license so that it is no longer permissive?
I've never been clear on what stops the above attack. Many people have setup foundations on their death that are now promoting things the person was clearly against in their life. Martin Luther King Jr's "I have a dream" speech is now property of his heirs who milk that copyright for all the dollars they can get - I believe this is not what he would have wanted. There are plenty of other examples.
Personally I know it since I've been volunteering there since 1999 and know how elections work and know most of the membership. But that probably doesn't help much if you don't know me.
Practically, I know it because the ASF is a Membership organization, meaning there are hundreds of individual Members who have been elected by their peers inside the ASF. The Membership is the group who elects the board. The ASF has only individuals as Members (never corporations), and quite a lot of folks have made their careers about their ASF project work, while hopping between multiple jobs at various vendors.
So to mount an attack like that, you'd need to "evil-ise" a over a hundred Members to get them to vote for your hand-picked candidates who would be shunned by basically everyone else involved in the ASF.
Vendor neutrality and our permissive license are baked very, very deeply into everything the ASF does.
A fair number of 501(c)(3) foundations are similarly membership corporations, where the board is elected from the set of people who've been volunteering there for years, so they are unlikely to change direction like that. Some (c)(3)s are not, but still have a good track history. (c)(6) organizations are a mixed bag, since some explicitly allow sponsors to pay for board seats - a very different world.
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.
The phrasing "used by AI" was a bit simplistic. I agree that this is not a black/white situation. Maybe everyone will benefit eventually. But it would have been nice to have the option.
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.
Raises eyebrows We're already having the discussion of what we should do about redis at work, given it's a cache, and the tooling we use allows for other caching tools, we'll likely switch away from redis fairly quickly...
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.
> as long as absolutely everything you use to run a service that supports it is also licensed as SSPL.
There isn't an SPPL-licensed OS available, is there? Is that not included in "absolutely everything you use to run"? I actually don't know, I haven't tried to make sense of the license. Is there a boundary somehow that you are allowed to run it on a non-SSPL OS? Where is the boundary exactly, I might be using many other open source licensed (or even third-party proprietary licensed tools) in my total ops stack -- which of them don't have to be SPPL?
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.
> 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,
That isn't new either. What has changed is some have found what looks like a path to monetization that seems like it might actually work. 20 years ago they never found a path to monetization at all. You just forgot about the other failed ones because they never went anywhere (though the source code may still be out there).
> 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.
Not from a single vendor everyone is already using (AWS, GCP, Azure).
> What's changed recently is people launching venture-funded startups centered on gaining popularity through the appeal of FOSS
Redis aren't a venture-funded startup.
> one centered on selling services that were essentially just the FOSS, hosted
Many companies tried open core and hosting, like InfluxData, and it still didn't work. It's a hard sell when the big cloud providers' services are right there, a click/tf resource away, with integrated billing just a line item you don't have to haggle over. Honestly the only one I can think of that is kinda working with that business model (but still losing money) is GitLab.
> 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.
BSL/SSPL don't lack the value proposition of FOSS. You can still see the code, you can still contribute to it, you can still fork if it the company goes under or you disagree with their direction. The only thing you can't really do is compete with the company behind it, which most users actually don't care about and is hardly a part of the value prop.
“Source available” is uncool, compared to “open source” or “Free Software”, in substance, not uncool as a term.
The non-ideological value of open source is exactly the commodification that the retreat to source available licensing seeks to end, along with downstream consequences of that commodification.
> Apparently marketing people who want to sell stuff under those new licenses think "source available" is uncool.
It's not that it's uncool, it's just not true and reflective of reality. There's a world of difference between a .zip on an FTP ("source available because GPL says it must be") and everything still happening in public on GitHub and everyone still being able to contribute if they want to. Both are technically "source available".
GPL or any OSS license doesn't require you to accept contributions. Your users are free to do anything with it except distribute derviative software under a different license, but you, the author, don't owe them anything except buildable and runnable (since v3) source code.
And in the HN discussion about Garnet, someone said they’d never go into bed with MS. Their argument was that MS is just going to do bait and switch and will just change the license when it suits them, therefore Redis is superior because they will always be open source licensed. What a prediction.
Garnet is a small side-project for Microsoft, that they can fund with loose change Microsoft finds in the sofa. Redis on the other hand is the bread and butter for Redis.
There's a lot less incentive for Microsoft to muck about with the license and in that sense it's not really about trust.
Companies don't do s*t if they don't see it being beneficial. Perhaps they started it because they anticipated Redis license change.
Or maybe they saw redis had some shortcomings when trying to use in their cloud offering. The thing is that once it will get popular enough that other cloud providers might add it to their offering, the license likely might also change.
> This dual-license model provides greater clarity and flexibility, empowering developers to make informed decisions about how they utilize Redis technologies in their projects.
Fully on board, but no mention if they’ll be releasing the source used to run Redis on Azure. Do they have an exemption? A separate license?
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?
“Redis will continue to support its vast partner ecosystem – including managed service providers and system integrators – with exclusive access to all future releases, updates, and features developed and delivered by Redis through its Partner Program. There is no change for existing Redis Enterprise customers.”
I wonder how exclusive this actually is. Did Microsoft pay a boat load of money to freeze out Amazon?
I think that is more that Amazon doesn't want to pay to support anything, and that includes Redis, so I don't think Microsoft paid for an exclusive deal.
Well yes, what else would you expect from the folks who once called open source "a cancer" and came up with "SharedSource" as a replacement. Good move on releasing a genuinely open alternative, though.
MIT allows for Microsoft's "our very slightly internally changed version does behave slightly differently enough so the two can't interoperate" shenanigans, though.
> Note that Garnet is a research project from Microsoft Research, and the project should be treated as such. That said, we are bunch of highly passionate researchers and developers working on it full-time at the moment to make it as stable and efficient as we can. Our goal is to create a vibrant community around Garnet. In fact, Garnet has been of sufficiently high quality that several first-party and platform teams at Microsoft have deployed versions of Garnet internally for many months now.
> 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.
Garnet doesn’t use those however. A lot of older libraries that do runtime code emit or unbound reflection don’t work, but a lot of others do even though they were written more than 10 years ago and were adapted to netstandard2.0 target. Either way it does not benefit much from NativeAOT given it’s expected to be long-running where JIT is more advantageous.
At this point C# little to nothing common with Java and builds a perfectly runnable binaries. C# is extremely capable and strong and arguably is one of the best dev platforms there is.
(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 bootstrapping path does not exist. There is (afaik) no way to go from C compiler to working dotnet environment. You are supposed to just download binary blobs from m$soft.
https://github.com/dotnet/dotnet exists for "complete" source build that stitches together SDK, Roslyn, runtime and other dependencies. In fact, it is required by certain Linux distributions for publishing in their feeds, to be built from source in full. All components above can be built and used individually (usually), which is what contributors also do. For example, you can clone and build https://github.com/dotnet/runtime and use the produced artifacts to execute .NET assemblies or build .NET binaries.
Thanks for the information. It seems to contain only versions 8 and 9, so I guess what I said was valid only for the previous ones.
The repository looks promising, however the build.sh trying to reach to the internet during the build is disappointing. I would expect that to not help with having reproducible results. I need to look into how distributions approach this.
Domains that require network-isolated builds usually maintain internal mirrors with corresponding dependencies. It is unreasonable to expect from a project of this size to have all tooling it depends on to be available within repository files (moreover, it should build on multiple ISAs and OSes). I doubt you can build LLVM this way or, let's say, OpenJDK.
Well for example golang builds offline just fine, which seems similar in scope? Runtime-based language targeting multiple architectures and operating systems.
So the technical founders of both Redis and Hashicorp managed to step down before their respective businesses take on a shitstorm by steering away from FOSS. Unless I have my timelines wrong.
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.
Can someone please explain why this is bad to me or my company, who don't offer a paid, hosted Redis installation? As far as I can see, this license means that Redis the company gets some exclusivity on who can run a hosted version of their product, and everybody else gets it for gratis, with source we can change libre.
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 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.
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))
Well, if you've grown tired of this debate, maybe I shouldn't reply, but maybe someone else wants to have it: Sure, it's not OSI-OSS, but what does that mean for the world, in practical terms?
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.
There is larger community impact of not being FOSS. Most immediate, distros will not package it anymore. Overall you will not be able to include Redis in FOSS projects in the same way anymore. In longer term this means that Redis will not enjoy similar integration with other projects; FOSS projects tend to prefer using/depending/integrating other FOSS projects, so Redis becoming non-FOSS means that it loses that preferred status. And so on.
That may end up being a net win for all involved: distribution users will get an up to date package direct from the source instead of a 5 year old version (or whatever) patched to hell, and the project will stop getting reports about versions modified by packagers.
Sure, it's not OSI-OSS, but what does that mean for the world, in practical terms?
One practical consequence: Linux distributions will drop the new Redis, and ship its OSS fork or an alternative protocol-compatible cache. Or perhaps continue with the pre-license-change version for a while, which is a kind of fork. What was the relatively simple "apt install redis" will now be "apt install freeredis" or "apt install awesome-cache" or "apt install redis73". So you will have churn.
I don't have an idea how many installations are via the official docker image; they won't change, but even there now you have a legal risk, however tiny: will Redis Inc. come after us for our usage? Legal departments are allergic to risk: witness their aversion to GPL variants, especially GPLv3 and AGPL. So perhaps there will be pressure to avoid Redis, again causing churn.
The restriction isn't that "you can't run the software as a service without offering the source." You're thinking of the AGPL, which is recognized as an open source license by the OSI. Redis's license has changed to the SSPL, which requires anyone who runs Redis as a service to release the source code to "all programs that you use to make the Program or modified version available as a service" under the SSPL. This makes it effectively impossible for a cloud provider to actually try to comply with the license, as it would require a massive engineering effort to write a new operating system, new device drivers, new programming language implementations, new web stack, etc all licensed under the SSPL.
Well I always welcome a healthy discussion so feel free to answer. I’ve really just grown tired of seeing outrage that software which was previously “OS as defined by the famous organizations” changes to protect their commercial interests.
Like you said, there’s a continuum, and I really don’t think that “you can’t sell this as a service” is a huge restriction on freedom. Especially when I can still use the software (even commercially) if I host it myself. Many of these services (Redis, Elastic Search, Mongo, etc) wouldn’t really exist without commercial use cases, and I really care more about protecting individuals freedoms and the use case of a human using a machine in their own hands for their own use. The extent of my interest in OSS being good/bad (if you can make that claim at all) is in the impact to individuals at home.
Also, the server side license just feels like the modern viral license we should have. GPL ensures all code running together is forced open, and AGPL ensures clients are open, and this ensures that the server is open. Seems good to me the same way GPL or AGPL are good.
I view it like government regulation. Bureaucracy is waste and I’m all for enriching society and creating new jobs and products with better commerce… but environmental protections and safety protections help society. If your business can’t exist without endangering someone, I won’t miss it. If your business exists solely to resell free software (explicitly designed for commercial use) that someone else made, and they don’t want to give it to you for free anymore, I won’t care it if you need to change up your business.
I think the disconnect here is that people think "it's either SSPL or GPL, and I want the GPL", when in reality it's probably "it's either SSPL or no more development", in which case I'd prefer the SSPL.
If I don't mind antirez not working on Redis any more, I can always fork it and do my own development.
Its no longer open source, if being open source isn't one of your requirements then it probably doesn't directly effect you.
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)
> 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 people who coined the term (OSI) gave a definition when they coined the term. That definition is almost universally accepted in the software world. Redis no longer meets that definition.
Just because something is a marketing term doesn't mean its meaningless. You can't sell non free range eggs as "free range" simply because its a marketing term. Etc
The term “free range” is almost meaningless when buying eggs - even the opening paragraph of Wikipedia explains this:
“Free-range eggs are eggs produced from birds that may be permitted outdoors. The term "free-range" may be used differently depending on the country and the relevant laws, and is not regulated in many areas.”
AGPL is an “open source” license per OSI - I assure you if you use code licensed under it at many big companies, you might avoid a meeting with legal but will instead get one with HR…
> opensources products can be used without talking to legal departements.
Pretty much every company I've worked at has wanted legal signoff for use of any open source project. Granted, compliance with that directive was often spotty. But some did have a tool to scan our repositories for dependencies, and flag things that had licenses not on an approved list (which, no, was not the entirety of OSI-approved licenses).
It opens you up to a larger litigation surface. Previously, you didn’t risk having to explain to a court that you’re really not offering Redis as a service even though your service is using Redis.
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.
And this is why it is a bad idea for open source contributors to transfer their copyright.
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.
That may be true if a codebase is licensed under the GPL and has a diverse copyright ownership. But the 3 clause BSD is not that.
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.
> 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.
RedHat says that you can't get future versions if you exercise your GPL freedoms. You are free to redistribute the latest version of RHEL or CentOS or whatever, including all source code for all packages in their repos. But they will never give you another version of any of their software if you do so.
When will developers learn that the BSD does not protect you or your users? I understand the philosophical reasons some folks like BSD/MIT-style licenses, but at the end of the day they are not much more than public domain: anyone can take someone’s work and contributions, make improvements and keep the entire thing — original work and contributions, as well as improvements — proprietary.
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 true for copyleft licenses, but not for permissive licenses. And you can still get a copy of the old version under the old license from someone who downloaded it before the license change.
Slightly off-topic: Until last week, we used Redis for Laravel queues and cache in our blogging platform. We decided to get rid of Redis and use the database. The reason was that we are planning to allow self-hosting of our software so removing a dependency is a huge win to reduce complexity (didn't know about the license change then). There are a lot of arguments against using a relational DB for queues, but from our testing, it just worked! So, we just went with it in production. Surprisingly, there are no noticeable performance issues so far.
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.
Almost three years ago, but the last time we used database as engine for Laravel’s queue subsystem it exploded due to some database table locks under high load. We switched to redis and things just worked well.
if you have very high volume, there can be some tricks to using an rdbms as a queue system.
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.
> 24. Will Redis accept community contributions under the new license?
> 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...
OSI lost touch with their mission. This SSPL license is clearly an open source license in the full spirit and original intent of open source. It is more aggressively copyleft than AGPL is.
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.
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.
The problem is the entire stack has to be released under the SSPL.
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.
That's essentially why people think its not-free. In essence, it pretends to give you the right to do something, but puts impossible to meet requirements so that in pracitise you cannot do the thing.
In essence, the license says you cannot use it as SASS software, but they didn't want to outright say that, so they did this instead.
You only need to do that if you operate it as a service that you sell or give away to others (rather than just running your own internal redis instance)
So yes, this basically prohibits anyone but redis from operating it as a service, unless you write your own operating system for it to run on. (Although presumably they will sell you licences or similar to operate it as a service)
That's the point! It's impossible to comply with it. If it were an open source license, it'd require every component to be released under an open source license.
I don't believe that was the intent. If you look at the text it's more focused on the unique software that goes into delivering the service itself ... but since the goal of the SSPL was in many ways to reduce ambiguity compared to the AGPL, I think this perspective should be reflected upon and perhaps incorporated into a future version of the SSPL.
Let's say you deploy a work queue service backed by Redis, with authz/n delegated to Azure AD. You would require a commercial license since you can't publish Azure AD?
Taking an established open-source project with a healthy ecosystem and community and making it proprietary overnight is already destroying their community.
Isn't SSPL compatible with the GPL? If so you could "just" republish your stack under the new license. Not sure how feasible this strategy is in practice, as any company's stack is vast and no one wants to enumerate it all...
OSI executive director here: The SSPL was retracted from review (it was years ago) as the discussion on a mailing list stalled and became unproductive. Read the original threads on the list, not just that blog post. Frankly, it was a low point for the organization, the board at the time recognized it and that triggered a structural change[0], too.
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.
Thank you, and it's great that it was recognised a structural change was needed inside and that they attracted you to help implement that. I understand there's deep and long threads on the mailing list, and that there are great flaws with the SSPL.
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?
I don't accept that this is OSI's fault thought: It takes two to tango. The OSI has been thinking about a more appropriate format to address the issues of copyleft in the cloud world. I recognize that the problem exists, I wrote about it here: https://opensource.net/lost-decade-crucial-lessons-for-ai/
Frankly speaking, I would love to see also a detailed criticism of the AGPLv3. I would love to have a better understanding of why the SSPL was deemed necessary and what needs the AGPLv3 fails to satisfy... So far, the only explanations I've heard are superficial at best.
You have to also realize that most of these companies are not interested in copyleft or in the values of Open Source to empower users. They're following a very well known path, one that Phipps calls the rights ratchet model. Call it the SugarCRM model, if you prefer: it's a very very predictable pattern, from Open Source to proprietary in about 10 years https://meshedinsights.com/2021/02/02/rights-ratchet/
These are complex matters though and I'm convinced that they cannot be eviscerated properly on a social media, or only on an online forum. We need better ways.
You're right, I don't want to imply it's OSI's fault at all. There is an incentive from the ex-opensource companies to move on from their permissive licenses to something else. That movement is entirely separate from OSI, the best OSI can do is entice and encourage project to go or stay open source. You can take a horse to water, but in the end you can't make it drink.
I agree that the companies are not really interested in copyleft. They built a business on open source, and as they gain popularity the edge they have in competition by virtue of being the original authors of the project is eclipsed by the resources and marketing power of platform operators. They turn to copyleft to ensure the platform operators can not use their superior resources to embrace, extend and extinguish their product. They use copyleft to even the playing field, and maintain their profit margin.
And yeah there's the ratchet. I think it's in the open source community's interest to try keep projects inside the "open" part of the ratchet cycle. I imagine that if there was an AGPLv4 that had more of the SSPL style provisions it could've kept Redislabs inside the "open" part of the ratchet for another 5 years.
With regards to a detailed criticism of the AGPLv3, the SSPL is a straight fork with a small diff, which basically amounts to rewriting section 13. I feel it is really clear what the intended effect of the changes is, what do you think the OSI could learn from a more detailed criticism? The goal is that platform companies can no longer use proprietary software to operate their product. That might be superficial, but I just don't see a reason why it would have to go deeper than that.
What I would rather see from OSI is defining Source Available licenses better.
MongoDB, Elastic, Now Redis do not really provide the practical freedoms one comes to expect from Open Source software - it is clearly anti competitive by design which is bad for the use who will suffer bad quality and inflated prices as you always do when monopoly is created.
Having said that Source Available Licenses are better for end user in many circumstances than old fashioned Proprietary licenses and spliting the world in black and white does not help
I'm not familiar with the Elastic ecosystem, but both MongoDB and Redis have a great plenty of competitors, many of which implement the same wire protocols even, that don't make use of their license at all. So I don't think symmetric competition is affected or even a concern of these companies. Symmetric competition still drives them to improve quality and pressure prices.
It's the asymmetric competition from the platforms that's siphoning resources from these companies that could have been spent on improving the core product.
I don't understand your point with regards to Source Available licenses. Sure, source available is beneficial to the end user, but what does that have to do with open source licenses and the OSI? Source available licenses are simply irrelevant. If source available licenses need representation there should be a new organisation formed for them, no need to involve the OSI. You could call it the Source Available Initiative.
The SSPL is more than just source available. Except for the anti-competitive poison pill in it, its effectively the same as rights granted under the GPL. It's just taking the GPL viral nature to its ultimate extent.
As a simple thought experiment outside the cloud space (or in the pre cloud times) on how the GPL is just as "anti-competitive"
I can release code as GPL. Lets assume either I am the only contributor to this code or I have a CLA allowing me extra rights to the code. In that case, only I have the right to use that GPLd code in a closed source product. That's fundamentally not any more "anti-competitive" or "discriminatory" than the SSPL. Just like the GPL would have allow you to use my code in your commercial product shipped to customers, as long as you GPLd the entire code base (which many might find untenable), so to the SSPL allows you to use a "service" oriented code base, as long as you open source the entire service structure that delivers your version of the service to the end user.
As I wrote above, its mostly a question on values and how one emotionally reacts to those values than simple logic. As the arguments made against the SSPL (or at least a theoretically more perfect SSPL type license, as the emotionally arguments against the SSPL have created an environment where there has been no desire to improve it) really apply just as equally to the GPL.
"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]"
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.
I don't think anybody would argue that the BUSL is an open source license. OSI has investigated and released a report last year about the business practices similar to what the BUSL uses: https://opensource.org/delayed-open-source-publication
How a license which conflicts with the OSD can "clearly (be) an open source license in the full spirit and original intent of open source" is beyond me.
If the SSPL is more aggressive than the AGPL why don't companies just adopt the AGPL. This is an honest question. I'm familiar with the AGPL but not with the SSPL and wondered before, why the AGPL is used so rarely.
Because the AGPL left more ambiguous the scenarios where the user would be compelled the open source their work that used the AGPL licensed work: this unfortunately led many people and organizations to rule out the use of a AGPL software. Google and Amazon in particular are known to have these carte blanch rules in place.
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
The goal of these license changes is to prevent people from selling Redis as a service essentially, in order to prevent them competing with the redis company's offerings. If it was AGPL, you would still be allowed to do that.
I think you have it right. Unfortunately much of the "OSI is OS" commentariat misunderstands the SSPL which aims to confer freedoms to use with no obligation from there (and even deliver as a public service where the machinery that does so is also made open source and hence free for others to use).
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.
This keeps coming up, but I've been around for a while and I'm pretty sure that saying no restrictions on field of use was part of the "full spirit and original intent" of open source.
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.
You went for an incorrect reading of my message, and then built an entire argument against that incorrect reading of that message, and then even went on to assume the people who seem to agree with me also follow that incorrect reading.
Let me try to make my argument more clear. The spirit and intent of the original GPL is to use restrictions on the use of open source software, in such a way that it can only be modified and distributed and linked to other open source software that has the same provisions. This effectively limits the fields of use to companies that don't make money off proprietary software. This is the original intent of copyleft open source. Here is a quote from RMS himself: " Using a noncopyleft license is weak, and usually an inferior choice, but it's not wrong."
In the 2000's however, it turned out that the GPL wasn't copyleft enough, because most software was offered as a networked service, and the GPL didn't affect this field of use strongly enough to effectively have the copyleft effect. So we got the AGPL, which extended the restrictions of copyleft to the networked software industry.
And then in the 2010's it turned out that the AGPL wasn't copyleft enough, because big infrastructure builds proprietary platforms around AGPL software, and the restrictions of AGPL don't affect them as much. So that's where SSPL comes from.
You might see it differently, but I think the SSPL follows this spirit.
Am I the only developer, working for corporation that is using other mega corp's cloud, using redis personally and at work - who sees this as good news?
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!
Because once you have strings attached, you need to constantly be aware of it. Sure, this only targets cloud providers, but what if a company wants to host a redis instance for its subsidiaries? Or you expose direct Redis access to certain partners? Or insert any other perfect innocent scenario. Suddenly you need to hire a lawyer.
No, the competing cloud providers would pass that extra premium right to the customers. So the affected parties are those individual customers who want to buy managed Redis from the cloud - the prices will go up for them (if Redis Labs plan were to work)
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.
> Sounds like solid way to build sustainable business around open code.
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.
Classical "bait-and-switch". Bait users and developers with a fully-open and freely-licensed project, wait for it to gain enough market share, then switch the license to a more restrictive one...
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)
Are you talking about the developers who willingly contributed code under the BSD licence? The same BSD licence that says that it's completely fine for the company to do this?
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.
To a large part it is probably simply uninformed developers choosing permissive licenses, because some of their favorite projects do so as well and that is what they know as "open source". The thought seems to be along the lines of:
"I am going to make it open source! What license was that again? Ah MIT license! OK, done!"
Only later, when a project has gained traction they might or might not realize that MIT license allows people to do things they would not like. But by then they need to ask all the contributors for a license change and it typically doesn't happen.
Often the people also think they must not upset companies, if companies uses their software. Sometimes there is also financial motivation behind that. Big players invest into that project directly or conferences or other things, giving the people involved in the project some fame. See for example project Jupyter. One look at the $ponsors and you know why they will never change to a copyleft license.
That is alright, but people should not be surprised, when the rug is pulled away under their feet and big tech creates some closed source alternative or derived work under a different license, that integrates with their other stuff and that the original authors do not see a penny of, even if millions of people use it.
When I decide on software to use for myself, and I have a good choice between something copyleft and something MIT or similarly licensed, I usually go for the copyleft one, because I have no interest in the corporate involvement.
I think for most devs, software licenses are not a core competency. Most devs interact with licensing only occasionally, if that, and they may not have a good grasp of the licenses they work under (or if they do, they may forget parts of their understanding later).
Talking about bait and switch for Redis makes no sense.
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.
I'm curious about something: I suppose Salvatore still owns the copyright for most of the code? The old license does include his copyright, up to 2020: https://github.com/redis/redis/blob/7.2/COPYING So I think this change couldn't have been done without his explicit consent? Or did he transferred his rights to RedisLabs or a foundation?
What your link points to is the BSD license, so yes, he owns the copyright but also gave everyone permission to use and modify the code as they see fit.
There is nothing that prevents anyone to use this code in combination with proprietary code and sell the resulting project for money. If he didn't want that he would have chosen a different license.
Actually, if i read the below correct, on the server-side side license part, they want any company to publish the source code of any Redis-as-a-Service product is being developed:
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.
Yeah, I don't like that we're at the point that we need licenses like this, but in a world where AWS has decided to "disrupt" the methods for open source monetization that the open source community has generally agreed upon as being in the spirit of open source, I don't see any other option.
The methods in question are not the ones that the open source community has agreed upon, they are ones that the FOSS community had identified as being non-viable, with detailed reasoning, before the OSI was even founded. The fact that a handful of founders and VCs decided to ignore this established wisdom does not constitute an general agreement by the “open source community”.
The consensus that simply selling FOSS software (and renting access to it is not substantially different in this regard) is not a viable method of monetizing FOSS as an independent business centered around a particular piece of FOSS because large established firms with established hardware, professional services, and other associated lines of business and the ability to integrate it with their other offerings would eat your lunch was established by, at the latest, the mid-1990s.
> 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.
I don’t think this is about bait-and-switch, I believe (like some other comments mentioned) they want a bigger part of the pie. It’s same story as what Elasticsearch went through, this an understandable move.
It’s bait and switch to community developers who contributed free labor to a for profit company for what is now either a fork or a more restrictive license
The version they contributed to is still available under the same permissive license that was in effect when they were contributing the code.
The license change only affects the code written in the future and now people can change their mind about contributing.
That seems fair to me.
Maybe you think that morally the license should never change but there is no clause in the license to prevent changing the license, so that would not be a reasonable expectation.
The company Redis only adopted the Redis project (and changed its name) a few years ago. Redis started as a community project and was run that way for almost a decade.
All clients will still be Open Source and a lot were initially written by the community as far as I'm aware, so they're actually still asking for free labor there.
This shows a fundamental misunderstanding of how open source licenses work. I am completely sick of this take. It’s intellectually dishonest, or extremely ignorant.
Never attribute to malice that which can be explained by stupidity
Reading the other comments the switch does make more sense, if you want to freeload off of the work redis has done for the project then you’ll have to join whatever community remains on the forked version, and anyone who cares about this kind of stuff should probably understand what’s permissible in the previous license, which clearly includes it being switched out like this
Why do you think almost zero users are affected by this change? If a business was built on hosting redis or providing managed redis, that company is now inviable, no?
note: I am not disagreeing with the license change, just asking why you think nobody is affected.
If a company is built on hosting redis - and is now unviable, they should be pretty incentivized to fork the previous version and maintain it themselves. Isn’t that the power of open source?
I doubt there were many (if any) non-AWS businesses that were affected. To earn a profit you need to continue to work, I don’t feel bad when a corporation is negatively affected after their leeching or rent seeking is disturbed. Even if it was previously acceptable behavior.
That's exactly the point. Companies providing managed services on top of popular opensource projects are not contributing to the respective OSS project at the scale at which they've been benefitting commercially from these projects.
Not sure what exactly the point is. The OP is saying almost 0 users are affected and this is not true. I was only saying that the license change affects quite some people. Whether rightly or wrongly is not mine to debate (I have nothing to do with redis!).
Do you really think they planned this from the start, intending to change the license as soon as enough people use it? To me, that's reading malice into a situation that could equally be explained by changing circumstances over time, which does not meet the definition of bait and switch
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?
Redis picked SSPL instead and cited those reasons for why
"It is based on the AGPL, with a modified Section 13 that requires that those making SSPL-licensed software available to third-parties (modified or not) as part of a “service” must release the source code for the entirety of the service, including without limitation all “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”, under the SSPL. MongoDB is the publisher of this license. They have a FAQ about the license https://www.mongodb.com/legal/licensing/server-side-public-l..."
Can't developers sue this company for false advertising ?
This started off as one thing and ended up being something else. They probably at any point did not hint about changing license in the future, just guessing.
For any open projects , couldn't dev. request for keeping the license as is or Free(or whatever relevant) before letting their code merged.
This may sound illogical to someone who is a domain expert, but this is just a dumb question from someone who has almost 0 clue on this topic.
Sue is probably not the better description of the thoughts I had. Let's say, can't the developers do anything in an act of retaliation? Given that so much work came from the community.
> ... advertised
Yeah. Wrong choice of word. Using one kind of license to get the attention of public is in spirit akin to advertising(that was the line of thought I had). I am not doubling down on stupified things I said, I am tryina explain what I thought.
So... if I can re-ask the question , I take my dumb-comment yesterday back and ask it like this :
can't the community do in act of retaliation against these acts ?
can't we mandate community approval for license updates when the community is also participating in contribution and popularizing its usage
I do not have anything against Redis. What is going to happen to the future of FOSS and software in general , if once open(open source and Libre) projects end up walled or proprietary etc.
It's not viral enough. It's easy for AWS to host a version of an AGPL project and just point to the source code. Cloud hosted instances are the primary business models for a lot of projects. The solution is to add a requirement that any platform the software is hosted on also has to be open source.
What's your outcome? Are you actually asking for a "No AWS" license?
AGPL is fine - it ensures that open source projects remain open source. If a vendor hosts an AGPL project as is (unlikely imho) and is able to point to the existing repo for source, then that's great. If they make changes to the code, they must also make that source available through a compatible license.
> The solution is to add a requirement that any platform the software is hosted on also has to be open source.
Even that is a somewhat temporary hack. The SSPL spreads to:
> "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"
and sure, AWS and Azure definitely don't want to open source all of that stuff now, or for the next decade or two.
But that's not their competitive advantage; that's their datacentres and their sheer gigantic size and deep pockets, making them a "safer" partner for enterprises. National governments won't run a critical service on Redis Cloud when Azure Redis is available, even if the software stacks were 100% identical.
It's quite possible to imagine a cloud provider in 2040 that does run a fully OSS stack and is able to sell SSPL software on a massive scale without paying a cent to the original developers. Doesn't even have to be a new actor, Amazon could spin-off a separate experimental organization for that purpose.
If that were to happen, could another license solve the problem?
> Cloud hosted instances are the primary business models for a lot of projects.
No one is entitled to their business models, no matter how noble their goals.
It's quite simple: if you believe in the ethos of Free Software, you need to be prepared to the possibility of other people taking your work, doing modifications and even profiting from it. That is the whole point.
If you don't want "evil corporations" from taking your code, then keep it closed and say it so. But don't be dishonest with others when you say that you "support open source" while not ready to walk the walk.
People are struggling with what I think of as the pyrrhic victory of open source software. Vast swathes of computing is done with OSS, yet there is very little software freedom for actual people, because it’s all running in megacorps data centres with all the data locked away.
Essentially, the intention of copyleft to increase software freedom, which is the overall mission, has foundered. It is didn’t work and need revising.
Smaller companies are an ally of convenience here.
No, the problem is that people conflating "free as in speech" with "free as in beer". Data is locked in megacorps because people are giving away their freedoms in exchange of convenience.
> the overall mission, has foundered.
Absolutely not. I've never had so much freedom on how to do computing.
I don't think the intention of OSS was to make computing more free for a tiny elite who are will to live with quite a lot of inconvenience. Maybe I'm wrong. I certainly don't think the average computer user is more free in their software use than they were, say, 10 years ago. Or 20.
1) The average user has a lot more choices of free systems to use. That they still prefer to lock themselves to a closed platform is not a failure of FOSS.
2) in the worst case analysis, FOSS trickle downs to people. Eg: WhatsApp could only have started if we had FOSS. It may have been colored by Facebook, but at the end of the day it was thanks to it that the "non-elite" managed to disrupt the telcos and offer messaging for free.
It absolutely is a failure of FOSS. It was supposed to be viral, leading to greater software freedom for all. The strategy has been countered and subverted by running FOSS on servers people don’t control.
Half the world’s communication being under the control of one company with a dictator is hardly a success.
Are we arguing over "freedom from" and "freedom to"?
I don't like that so many people preferred to go for a closed solution and I certainly don't like virtual monopolies, but people are there out of their own volition.
30 years ago, there was no real alternative for Windows on the desktop. All productivity tools were closed. Today, people buy iPhones and sign up to Instagram/TikTok because they want to.
What would you propose, to have Stallman pointing a gun to everyone who didn't attend a install fest?
> What would you propose, to have Stallman pointing a gun to everyone who didn't attend a install fest?
If I can propose wild things, then I'll propose that something forces big hosting companies to share their code.
And data freedom is an important issue that has a huge overlap with software freedom. I like the EU's movement toward forcing export and interoperability for big entities.
The more things you list that are before the year(s) they used as reference points, the more you support their argument that software freedom peaked a while ago and has been going downhill in major ways in more recent years.
My point is that I can continue with the timeline, and it will trend towards more freedom, not less:
- Google's original Android was more open than any of the alternatives. And even if Google went on the direction of closing Android and putting functionality around its Play Services, there are a good number of alternatives that build on Android and make it completely free. The number of devices that can run LineageOS/Murena/Linux is going up, not down.
- All social media was closed, and now we are seeing an explosion of open source projects. The number of people using it is going up, not down.
- Self-hosting software is easier than ever.
I fail to see any time interval where the availability of free software has been reduced. All it takes is a motivated individual.
Basically everyone who complains about proprietary/closed software and platforms and claims to "support" FOSS but never put their money where their mouths are.
Every company that pays through the nose for their cloud hosting, but does not allocate anything in their budget to support the downstream projects.
Every owner of a pricey Apple device who claims "they need something that just works" but never spared a few dollars per month to contribute to the development of free alternatives.
If a fraction of these people realized that quality free software takes money to be developed, and were willing to invest in it, the FOSS funding issue would be solved. The problem is, people are not willing to pay for R&D, they just want to pay for the finished product.
Unless you actively want the support contract with Oracle, there is no reason not to use MariaDB instead.
Debian changed it to the default quite a while ago, and it's full support for mysql compatibility means you sometime don't even notice it (eg "mysql" is starting mariadb client).
Yes, it replaced MySQL in Debian, and many other distros. The only shared web hosting I know about uses it on FreeBSD, etc. It seems to be more widely used then MySQL at this point.
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?
For me, using OSS means that if I bump into a problem, I can fix it and use, and share the fix. Yes, I've created OSS projects and contributed to others.
It also means that if the people providing the software decide to change the deal to something that is too onerous for me to accept, I have options that don't disrupt the continuity of my business.
If I no longer have those rights, I'm no longer willing to rely on this software.
Unfortunately, it's far from trivial to rip Redis out of a running application environment and they know that.
This kind of change feels like a bait & switch to so many people, because it is a bait and switch.
Now that it has been integrated, and could cost hundreds of thousands or millions of dollars in labor to rip out, they change the deal.
We've been reassured for many years that this is OSS and it will always be OSS and many people relied on that assurance to place a hard and expensive dependency on this software.
That is a betrayal of trust and it's hard for me to understand how people aren't seeing it that way.
How do you think your freedom to “fix it and use, and share the fix” is changing? Unless you’re running a Redis hosting service isn’t it business as usual?
I don’t love the direction that the open source world has been moving in but in terms of practical impact on my work this seems to be minimal. I think the easy money during the VC bubble lead a lot of us to get used to high-quality software not having a plausible business model and we’re going to see a lot more of this, which makes me wonder if OSI could come up with some kind of hybrid license allowing maintainers to get paid but not giving up too much freedom. Otherwise it feels like we might see a move back towards closed-source development.
This is one way to see it. The other side of the coin is that this move is totally in their rights, morally and legally.
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 other side of the coin is that this move is totally in their rights, morally and legally.
Legally, sure. That's pretty binary.
But if you claim they have the moral right to do so you need to elaborate on that. Since they had a "social contract" with the community (people who submitted PR's, advocated for Redis, etc.) which a single side has now altered. I don't see how one can do that an claim to be in their moral rights to do so.
We've altered the deal, pray we don't alter it any further...
They haven't taken anything away from the community though. You can still fork it and maintain it going forward. It's the same as if the entire redis team died in a bus crash.
What they did do is decide that in the future, their work won't be as easily taken advantage of.
If you think that your "social contract" has been violated that that is because you are mistaken about the contract you entered into.
This would only be immoral if you were misled or forced, and I'd argue that neither is the case here.
All the contributors gave their explicit permission to use their contribution in the way Redis does.
All contributors had plenty of freedom to spend their energy in projects under a license that specifically prevents what happened with Redis. It is not that they wouldn't have other options.
No they haven't. "The community" submitted under a BSD licence, they literally gave anyone permission to take their code and relicence it under an alternative.
It's not like the BSD version of their code has disappeared. You can still use older versions of Redis that have their changes under BSD.
It sounds like submitters should have gone with GPL or AGPL if they wanted it to remain open source, available with the original licence for commercial use, etc.
> This is one way to see it. The other side of the coin is that this move is totally in their rights, morally and legally.
Morally I would say it depends on contributors. If there haven't been any then sure, but if I contributed a feck-load of code to some project and they slap on a commercial license, I guess I feel somewhat shafted.
You shouldn't. If you contribute to a project under a permissive license that is what you sign up for.
I contributed to projects under permissive licenses myself, there is nothing wrong with it. Being indignant about companies exercising the rights you explicitly granted them is unwarranted though.
You can, and that is ok. It would not help you if you feel shafted, because then the next company comes around and takes your contributions, uses them as intended without giving back and you'd still feel the same.
I think you should not feel
shafted, but if you do there is a simple and obvious solution.
> 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 licensed in way that matches your needs and wants.
The best thing you can do is to fork the project at the commit prior to the license change, and maintain it from that point onwards (and/or contribute to other forks with the same goal).
what a perfect org name for capturing these rug pulls, second to "github.com/lol-our-incredible-open-source-journey" or "gitlab.com/but-aws-gonna-steal-our-shit"
Honestly, I created it just to keep things organized. I fork a lot of projects for different reasons, but mostly just to keep a copy around for when "weird shit happens". Eventually I had some many forked projects in my "mindcrime" org that they got in the way, so creating a "mindcrime-forks" and moving all the forks there seemed like an obvious choice.
I also did a "mindcrime-templates" for template pom.xml files, and silly little "starter projects" of various sorts that I can clone down and and have something set up the way I like it, with minimal scaffolding, and then start morphing it into whatever I need.
This incident reflects the increasing profit pressure on Redis Inc. Furthermore, Redis' competitive edge in performance is declining, especially with the emergence of alternatives like Dragonfly and Garnet (disscussed here https://news.ycombinator.com/item?id=39752504).
Interestingly, there is some nuance. One of the two licenses seems to be copyleft, but it's just not currently approved.
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.
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.
With the current expectations, no license will solve the problem of making software open and prevent companies from "stealing" it.
The "stealing" point is not necessarily my opinion; just pointing that there's always noise about it.
Both were noped by lawyers pretty quickly (who actually know their stuff and how licences work, rather than random engineers), so I'm not sure what you are trying to suggest...
> (who actually know their stuff and how licences work, rather than random engineers)
The whole licensing diatribe is more ideological than concrete, so it's actually about "random" engineers more than lawyers.
> so I'm not sure what you are trying to suggest...
First, that most, if not all, of the criticism of dual licensing, in particular WRT the Redis case, is unfounded/uninformed. The SSPL is liberal when it comes to "engineering" freedoms (fork/distribute); the restriction is a business one (SSPL is very close to AGPL).
Second, most importantly, with the advent of cloud engineering, as of now, there's no licensing that makes everybody happy. And this implies that there will be plenty of complaints no matter what (just look at the dual licensing threads):
- if a company adopts standard FOSS licenses, there will be complaints about cloud companies leeching off open source projects
- if a company adopts non-standard but still liberal licenses (e.g. SSPL), there will be complaints about companies betraying the FOSS principles
I've tried KeyDB a few years ago, performance was significantly better than Redis. Didn;t test the spill-to-disk feature for data sets larger than RAM. Not sure if it's kept up with Redis on advanced features like HyperLogLog.
I remember in the olden days of open source, when there was a debate whether it is viable, the point of the free software party was that you are not going to make money selling the software itself, but rather using the software or providing support for it. Later at some point as open source matured, some people decided it was still possible to make an open source business.
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.
Has these moves to non-FOSS ever ended up working well in the long term? I think for Elastic and Mongo both it hasn't been the stellar successes they'd hoped for, those are the two major cases on top of my head. Or the big FOSS exodus of Sun projects post-Oracle acquisition.
There will be almost certainly some OpenRedis project, but this move might just kill the wider community interest.
By which metrics are you evaluating those companies' license changes? Both are significantly more profitable than before they changed licenses, MongoDB especially. I'm not sure there's a causal relationship, but it doesn't seem to have significantly harmed them.
That was more because they put a gun to people's head though wasn't it?
Docker on windows is pretty painful without docker desktop. You can certainly get it running without docker desktop, but the polish isn't there. As far as I know there is no way to install docker on windows manually and get integration with 3rd party tools. The closest I've come is using podman desktop. I think it has a way to go before it can be considered a drop in replacement
Isn't that just the standard Oracle playbook: increase prices and push people to alternatives? k8s has long dropped docker as a base technology, it really is the dockerhub default that makes docker relevant.
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?
Unfortunately memcached is missing some features that make Redis very powerful for uses beyond a simple KV cache (for that simple cache usage neither are as important, granted):
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.
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.
I'd rather see alternatives from individuals and small business. Microsoft can subsidize whatever freebie project they want simply because of their cash reserves. Redis, on the other hand, is the lifeblood of a single company. There is a much greater incentive for them to produce a better product.
That is why enterprise shops than get all the cool toys, because many devs aren't willing to pay for their tools, and then they wonder when their toys aren't available any longer as the creators got enough CV coverage to get a proper job, doing proprietary software for big corps.
Having recently left a job that let me run Ubuntu and started a job that forces me to use Windows, that is an excellent example of the proprietary/paid option being awful in comparison to the FOSS option. The rest I've not used so can't say with any confidence.
Redis is still 'free as in beer',
unless you are operating a bar and want to profit off of the free beer someone else produced,
then it's not 'open source',
but somehow you can still get the source as it remains 'source available'.
Redis was open before the trademark was acquired from antirez by Garantia Data, who then re-branded themselves as RedisLabs, and then as Redis. This was definitely not a predestined outcome, there are plenty of other foundational open source server software that transitioned to a software foundation. While I worked on the redis core team (https://redis.com/blog/new-governance-for-redis/), I advocated to move it to a foundation.
Yes, but the point is that the project started as, and gained success as, a not-paying-the-bills endeavour. The fact that RedisLabs desires to get enough to pay a bunch of staff is not actually a requirement for redis to exist and thrive, they just happen to own the trademark.
Exactly. Redis (the company) had plenty of opportunity to monetize either a cloud offering or their enterprise offering. They have a lot of cool technology like vector search and time series extensions that people will readily pay for. They could have found a path of moving the core to a foundation and continuing to make money with their added value. They're choosing to get the value they can out of the open-source stack. It might work out well for them, but I can't believe it will be good in the long term for Redis users.
> Maybe such is the destiny of foundational open source server software... If it's "cloudable" no profitable business will come out of it.
I really hope it's not true, but many clues suggest it might be.
I like the concept of open core with a very liberal license. Perhaps there should be a special "MIT-X" (an example, it would be certainly not compatible) license with a clause borrowed from that of Llama2 for large organizations, as Additional Commercial Terms [0].
"2. Additional Commercial Terms. If, on the Llama 2 version release date, the monthly active users of the products or services made available by or for Licensee, or Licensee’s affiliates, is greater than 700 million monthly active users in the preceding calendar month, you must request a license from Meta, which Meta may grant to you in its sole discretion, and you are not authorized to exercise any of the rights under this Agreement unless or until Meta otherwise expressly grants you such rights."
Yes! There are modules such as encryption, compression and more thorough test suite (for safety-critical users) that SQLite authors only offer at charge.
(IANAL) Every commit is a derivative, I don’t think the numbered releases have any impact on that. Say you fork Redis now, from the commit that changed the license, that’s a different ”version” of the software compared to the commit just before that is practically the same but using the BSD-3 license.
"... 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."
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.
I work at Earthly. We build a pretty popular open source build tool. I've worked for several companies that build OSS before Earthly as well.
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.
There have been several really good episodes of Oxide and Friends discussing the danger to open source posed by license proliferation, the danger of copyright assignment, the danger of conflating downloads or FOSS project popularity with income and a viable business model, and appropriate stewardship of a shared project. This is an area that sort of bleeds over between engineering and politics, and as politics go I think this is an a very important topic for developers to understand well and engage with.
> Despite efforts to support a community-led governance model…
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.
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.
Seems like AWS did contribute to Redis and has implemented quite a few features [1] and have been partners for quite a while [2]. This could not have any effect for AWS but for other cloud providers instead.
So it seems making money by developing open source products is hard. I wonder how many more we will see this and next year? And is the open source model actually broken outside hobbyist and large enough projects with enough players like Linux...
Or it works just fine. I imagine that Redis would be OK if it was just a small company with a few consulting developers. Expecting to build a huge business around it with y-o-y increasing shareholder returns only works for a very very few companies.
Their Q&A essentially says you can no longer build anything that is commercial using Redis, except as a partner. That's exactly the opposite of what the SSPL License says.
"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.
> "this definition would include hosting or embedding Redis as part of a solution that is sold competitively"
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.
Can they do this? Open source contributions to their codebase were under a different license. They don't have the copyright for those contributions without a CLA (I can't find one). So how can they relicense those contributions?
Sure. Only the new contributions are under the new license the older contributions are not affected at all.
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.
To be clear (for the GP and others): the consequence of the parent's second paragraph is that if the old license were something like the GPL, this wouldn't be allowed, unless all copyright holders consented to the change. (The GPL specifically does not allow "adding restrictions", which the new licenses do.)
But since the old license is BSD/MIT (I think?), it's fine. BSD/MIT code is still licensed as such, but can be commingled with code under the new licenses without issues. BSD/MIT's terms can still be complied with under the new licenses.
BSD doesn't allow relicensing. I don't think any license that does either. However, BSD allows the licensees to incorporate the source however they want as long as they keep the notice visible.It doesn't transfer the ownership so re-licensing isn't possible.
So basically Redis becomes a licensee of the third party contributors and BSD happens to be quite permissive that Redis can relicense their own parts while keep using other people's creations under BSD without limitations.
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 problem is that the idea was "we'll build this nice thing and other people who use it en masse will also be nice and give us some money for support or just because"
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.
Nope. This is tied to the whole "Free as in speech, not beer" thing.
Open Source has core definitions around the freedoms (the "speech") allowed to people when making use of that source code.
Source available makes the source code available for free (the "beer") along with certain specific freedoms, but not all of the freedoms that would be required to be Open Source.
Whether or not you think those missing freedoms are important is a matter of personal opinion, I suppose. I think they are, which is why I try to avoid source available software if there is a reasonable open source alternative.
Very true. I suppose I should have clarified that source available in the context of a lot of these formerly open source projects, and not as a blanket term.
Famously, "open" is usually considered to be the same as "visible". When people say that a door is open, they typically mean that they can see the door.
You're implying the majority of programmers are HN users, not true ofcourse. HN is just a different, possibly older breed compared to the average programmer. I would say it's not even debatable that the majority of programmers would still consider this open source (since the source is still open), and haven't heard of the term source available. The more accurate statement is, its no longer free (as in freedom).
Perhaps you thought I meant the majority of all people, I meant the majority of all programmers outside HN (hold a different definition of open source than the more extreme one used here). Not that it matters - but I would say non-programmers have an even higher percentage of people with a different definition.
I mean sure, the more upset reactions from the more invested parties are the more interesting ones. I just take issue with people fighting to use a more-incorrect, less-used definition which serves no purpose other than to try make entities like Redis look bad.
Good, most value in OSS is being syphoned off by the mega corp cloud vendors which contribute nothing back to the maintainers of the OSS products they're charging rent for.
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 use cloud-hosted redis. Presumably the price will be going up. i work for non-profit endeavors with limited budgets.
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 contributed a few LOC to Redis in the past (before "Redis Labs" had taken over), but never signed a CLA or assigned Copyright (that's not even possible in my country of origin). I realize that under the permissive license that I published my contributions under, they can very well do what they are doing. That they are doing it, is disappointing nonetheless. I guess there are more people like me out there, with vastly more important contributions, who feel about the same. I, for one, will not contribute to the project under this new license any more.
I don't understand what's wrong with AGPL-style licenses. If I wrote something that can be used in a cloud I would also prefer AGPL to prevent cloud companies from selling software and taking all the profit while contributing nothing.
> I don't understand what's wrong with AGPL-style licenses.
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
AGPL and SSPL are quite different (around how it works with other licenses and software), and those differences are what makes AGPL still FOSS, and SSPL not.
The ‘Redis Source Available License 2.0 (RSALv2) Agreement’ is a relatively succinct and human-readable license. Still, I really wish these non-compete licenses would come with a few examples of use cases that are definitively non-infringing, to remedy any uncertainty.
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.
I agree it would be good to clarify this. I have a product that does some background job processing using Sidekiq and Redis, and it seems that this would not constitute "making the software available", in particular where it says:
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 think more accurately, yes, but when is more the question instead of will it happen. I would expect current LTS to keep the open source releases for now (assuming security releases for older versions are still released as open source, if not you may find it dropped earlier!), but it won't appear in any new releases (LTS or otherwise).
Do not kid yourself SSPL is intentionally designed so even someone who wants to provide DBaaS version and honestly contribute to the project can't really use it, because most likely I can't SSPL all components which are required
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.
As I said in another comment, I believe this is a fundamental misunderstanding of the intent, but hearing you and others saying it shows that the authors will need to consider further revisions.
All GNU projects require assigning copyright to the FSF[0]. It feels a little absurd to call a GNU project "not open source".
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.
Yup! I might make an exception at some point but so far I haven't. I believe that all contributors should be equals and not some have more rights than others. Also I need to research and trust the entity which I sign the CLA with.
It's the other way around. Mega corps are cut off from leeching on open work.
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.
Redis is also on the the leeches in this case. They have a 500 people company which plans to profit off of hosting Redis and wants to have a competitive advantage by being the only ones who do not have to open source their modifications.
> 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.
I like it and I think this is how open source should work to thrive.
If a webserver were to use this license it would still allow most enterprises to use it as a web server (IIUC) except if you are offering an open proxy service.
All websites and even value-add proxies likely would not be impacted
I think you're underestimating the impact that the webhosting industry had on the popularity of Apache httpd, all of these related ecosystem projects like PHP, MySQL, etc., and even Linux itself. How many small businesses launched because cheap and good webhosting was plentiful? How many developers cut their teeth making web apps that worked on the average cPanel/WHM webhosting provider? The answer to both of these is "A lot. A whole lot."
I did not think of this, if I understand the license correctly an AGPL webserver used to host third-party websites would only require the ability to download the source of the webserver, while a whit SSPL it would require the ability to download the source for both the infrastructure and the hosted application.
Definitely a different tradeoff that many would not have been confortable in choosing.
But now you're open to [Redis] taking you to court saying that your service that uses [Redis] is too similar to “just [Redis]” for you to offer it to anyone else.
Field of use restrictions are a terrible idea, and totally incompatible with “open sourceness”.
If you run cloud providing business that directly competes with Redis Labs with your "Redis on steroids as a service" then you need to enter into licensing agreement with them to share your profit margin, no drama here, don't be a leech and that's where it ends.
If you're running commercial project where you USE redis, not PROVIDE it, you're fine.
If anyone is still debating about fairness, philosophical view point, business viability of OSS projects, competition from cloud providers - please click on the link below and check it for yourself.
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.
If there was a license violation they should sue. Otherwise, writing a compatible reimplementation of something should not be something "open" fans are against.
I think OP's point is that AWS have the resources to reimplement all the differentiation you can try to add with an open core model like Redis tried, which makes the whole attempt at open core useless. Therefore the choice is either to try to partner with AWS like Grafana Labs managed to do (only ones I'm aware of), move to a license with restrictions on them reselling your code, or accept defeat.
Well even if they moved to a restricted license it would not stop reimplementations of the same protocol (I assume the extra non-open-core bits were already under a more restrictive license). I think that was just a poor example.
Maybe this is naive, but some of those bloody license discussions on this thread have hit a nerve.
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.
I believe the sarcasm is around Sentry and implying that it's redis usage is poorly optimized. I'm not familiar with Sentry, but it looks like the self hosted version makes use of redis as part of it's underlying stack.
I recognize our (Sentry’s) over-use of redis. Also doesn’t make us particularly happy. Can’t promise that this will get significantly better but the desire is there at the very least.
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.
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.