Redis adopts dual source-available licensing
redis.com
redis.com
It’s a hard choice to make, but imho either keep your code proprietary or stick with “Apache OR MIT” … all this stuff about switching licenses partway down the line is really lame and just seems destined to backfire.
Open Source is about user ownership of software. If we try to get around that with legal trickery to make a buck, then it’s not going to hurt the big corpo teams, but rather the users. Big corpo teams are users too, they don’t want to deal with this legal mess either. Like it or not, Redis has always been a permissive open source project which is why it has been a success. Changing that is changing the equation in that regard going forward and portends bad outcomes for everyone involved.
We need to better recognize the difference between "Foundation" owned software like PostgreSQL vs Corporation Owner like Open Source. When you focus in "Maximizing shareholder value" the goal of keeping your user freedoms will inevitably be put aside.
It would be much better choice for Redis community if Antirez would seporate his employment from Project ownership and leave it in hands of some non profit. Something like Apache Redis would be much better for community and it also would allow Redis Labs to build proprietary extensions and cloud business around it.
That depends on who you consider the user. If it's the person buying managed redis, then this license change doesn't affect any user freedoms.
I don't know, it feels like this way of doing things doesn't work well, but pure open source also doesn't work well when you want to pay salaries to a bunch of devs.
I wrote about this conundrum a few years ago: https://www.mooreds.com/wordpress/archives/3438
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.
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.
If your goal is profit, don't open source your core product.
We've seen this time and time again where a company releases their core software under a permissive license, and then bigger competitors come along and resell a solution redistributing their software.
If the company's central goal is profit, this is an existential threat. However if your company goal is to ensure the software exists (as a non-profit steward), this is a resounding success!
This doesn't apply to software that's secondary to your core product, e.g. a useful tool you've developed but don't make money directly selling to others.
That depends on whether those big competitors are contributing code back.
If they are, then great, the code continues to exist as high quality open source, even if you're playing a smaller role.
If they aren't, then the good version isn't open source. Your goal is failing even when you ignore profit. And at that point maybe an "open source except for those guys" license gets you closer to your goal in practice.
Or more fundamentally, don't open source your value prop. Open source your complement. So many OSS shops build a valuable core only to realise their actual business ends up being selling managed servers.
It's not hard to create a profitable business on open source and make good money. The question is how much.
If your goal as a founder is to be a billionaire, open source products are not going to do it. You need monopoly-level rents to do that, like Oracle or Snowflake. There's plenty of opportunity to create millionaires. But you'll have to forego VC financing to do it because that math does not work for venture capital funds.
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.
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.
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.
Reselling redis-as-a-service or not is clear cut to me.
I'm not so much interested in philosophical explorations of theoretical "what if I resell redis but without this and that command?" cases either.
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.
It's your choice between SSLPv1 or RSALv2.
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 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.
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.
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).
[0] https://opensource.org/blog/the-sspl-is-not-an-open-source-l...
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?
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.
It doesn't mean others are not allowed, does it?
> 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 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").
They are completely within their right to switch licences but it doesn't mean that we have to fall for the narrative that they are protecting themselves from the big guys. Let's be honest, no one would've used redis or terraform if it was closed source. Or if it wasn't available on the big guys platforms.
Redis started as a community project and had tons of community contributions. I'm sure that their effort to gain fairness for the smaller guys doesn't apply to anyone smaller than them. It's ironic that they did exactly what they imply the big cloud players did, scoop up open-source work to build corporate value
No, OSS developers retain authorship (with the exception of public domain). Only the authors can change the license and terms. Users get a license to do various things with the software/code, but they do not get ownership.
A copyleft project with no CLA, levels the playing field so that everyone has the same rights. Eg.: Linux kernel
See: Enshittification. Totally agreeing with you, but this feels like just another data point to Cory's thesis.
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.
Redis the project/tool existed long before Redis the company owned it.
Vagrant existed before HashiCorp owned it.
Significantly: both companies dropped permissive licensing after the creator of their (original) products stepped away, and both are venture capital backed companies.
So we could just as easily say "I see that long term people will preemptively fork projects the moment they are owned by a VC backed company"
I think 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.
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 ongoing uptake in open core, shows where it goes.
I find it hard to believe many if any would see "create an open source tool" as a method to become a millionaire.
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.
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.
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...)
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.
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.
Kubernetes - Gooogle, Microsoft, Amazon,...
Python - Facebook, Google, Microsoft,...
clang - Google, Apple, Intel, IBM,...
It sounds like a win-win to me.
For personal projects maybe yes, doesn't work for companies, they can't chase for thousand different forks of Redis and try to understand why feature isn't working properly on their version. Unless single fork emerges as a winner
I'm predicting such a fork backed by several core committers, and possible several cloud providers will emerge pretty quickly because they all need this to continue to exist as free and open source. AWS is not going to pay Redis a cent. Nor is Azure. Or Google. Or people commercializing open stack. All of those offer Redis support currently. Lots of their users use it.
To avoid the short term, providers could "buy time" and keep prices low until the project deviates far enough from forks, making migration much harder, then increase prices.
Either way, long term they can end up with a lot of money from a few companies rather than continuing to support many mixed sized companies.
I don't like it either but I can see it working.
Invariably, someone looks at the numbers and realizes "We could make way more money if we only catered to the top 2% of our customers!"
Unfortunately, opinions and needs of the top 2% of customers != a generally useful product.
Thus, the reason to try and maintain user volume is better product-market feedback to guide development, instead of revenue.
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.
When it comes to large corps, the prices paid for these products is already so large, because of the scale, that it often times makes more sense to employ your own, instead. These kind of decisions are taken all too often. We'll spend a good few sprints exploring possibilities/mapping differences/POCing to more accurately estimate all these findings and their ROI before deciding. This can also include tough migrations. At a previous megacorp; ELK did a nasty? Migrated to OpenSearch.
So, hard no on your take.
[1] https://www.microsoft.com/en-us/research/blog/introducing-ga...
For what it's worth... Microsoft was quoted in the Redis press release as a cloud provider that has partnered officially with Redis under this new licensing scheme.
https://azure.microsoft.com/en-us/blog/redis-license-update-...
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.
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.
Like the AGPL3?
Holy cow am I so glad for every line of that viral leftist restrictive code!
Yeah, isn’t this just massive cloud providers eating the lunch of Redis etc? I don’t know enough about the licensing but I highly empathize with these small-mid sized companies building foundational tech that is commoditized and upcharged by an oligopolistic cloud behemoths. Surprised it's taken this long.
Question: what other alternatives than license changes are there, assuming we want a healthy ecosystem of both businesses and open source?
It's not technically fully open source, but it's pretty close to it.
Actually, I just took another look and they now market their "open core" as the apache edition (or perhaps have diverged from the "community edition" now)
That isn't open source.
It is open source if the source code is available under an open source licence.
For example, OpenJDK is licensed under the GPL and Oracle provides licensed builds, but that does not make OpenJDK not open source.
Those producing work tools also have bills to pay.
In a way, developers themselves are to blame for the failure of the FOSS dream.
Slowly we are back to the public domain/shareware days.
Then there's the question of what I should be paying anyway. Who among all those non-free developers are paying in turn to all the professionals whose code they build on? Are proprietary developers somehow exempt from paying themselves? If and when I choose to pay I like to think all that contributed are getting the benefit.
There's a long line of professionals behind every code that should have been paid. Certain percentage might have tried to get paid. And even some who in fact did get paid.
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.
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.
But in the age of the "Cloud" companies will simply use the managed offering provided by Amazon/MS/Google/etc. basically destroying any financial opportunities for the maintainers and other people around the project. Also nobody wants to work their ass off on some OSS just to see AWS raking in milions off it without contributing back anything.
Madelyn Olson did the hard work for years to earn the trust of other Redis core developers to become a core maintainer, all while employed by AWS to do that work. She and other AWS developers have contributed a lot to the core Redis engine. Some may say that they too worked their asses off for the Redis community.
You can read more about some of those contributions here: https://aws.amazon.com/blogs/opensource/behind-the-scenes-on...
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.
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.
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.
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.
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 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)
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.
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?
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'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?
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].
[1] https://meshedinsights.com/2021/01/27/all-open-source-licens...
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.
[1] https://twitter.com/reconditerose/status/1770697315671535707
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.”
https://aws.amazon.com/blogs/opensource/how-aws-and-grafana-...
All I have to go by are AWS's huge profits and the continuing struggles of FOSS projects involved with AWS to develop sustainable business models.
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.
> 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.
How much does redis pay those aws engineers for their contributions?
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.
(the page is now a 404)
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
Wasn't Dwarf Fortress charity funded for a long time?
They only hit it big when they got the game prettified and on Steam.
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.
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.
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”).
Amazon isn't running and charging for redis as a platform to make redis in the world a better place.
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.
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?
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.
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...
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 is a solution to that in many jurisdictions: register your pseudonym as an "alternate name".
I'll refrain from going off on a naming tangent, but that stuff is wild.
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.
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.
https://apache.org/foundation/governance/members.html
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
I guess plenty of people have already made their own call on this matter but I'm still genuinely undecided. As much as the megacorps are rushing to rule the AI roost - it's possible it will turn out to be a universal solvent to some degree.
But I'm also pretty lukewarm about AGPL and SSPL. I feel there's a huge amount of fragmentation in open source land and I'm often unable to use code in situations where I feel the original creator would probably have been ok with it.
Don't forget that AWS is one of the biggest reasons so many OSS projects became popular. Redis, Mongo, ES, HashiCorp stuff, a complete big data ecosystem, got wider recognition through AWS's offering. Many people have yet to learn about dozens of obscure databases (that have been in development for years) simply because AWS or other big cloud providers have not pushed them.
Also, many projects receive a lot of contributions (bug reports, PRs, patches) due to liberal licenses increasing their use and popularity. I'm not particularly eager to contribute to anything with SSPL/BSL/etc-like licenses simply because I don't want to waste my time on something I can't use liberally in the future.
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.
Redis is newer than you think. Or the cloud is older.
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.
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.
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 what they do in some cases - their managed Grafana and Prometheus are a cooperation with Grafana Labs. But it's the only one I'm aware of, practically all other ones (MongoDB, Redis, Memcached, MySQL, PgSQL, etc.) aren't.
Should be general competition, including AWS, right? AWS does not host a Terraform service, yet HashiCorp feels the pressure from quite a number of competitors that offer Terraform as a service.
No one forces you to make OSS, you can be closed source from the beginning and no one will fault you. But companies releasing OSS as a growth hack because it's seen as a donation to the software commons and then rug pulling deserve every fork coming to them. Debian and Fedora don't include JSMin (not that it's relevant anymore but still) because the license says you can't use it for evil making it not OSS.
That's what OSS means -- everyone, even the worst person you know, especially the worst person you know, can use the software for anything they want.
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)
Some folks are working on terminology over here, if you're curious.
https://github.com/softwarecommons/softwarecommons.com/issue...
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".
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.
It is not a problem of terminology.
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.
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).
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.
https://opensource.org/definition-annotated#6
That's the point of open source, and free software in a way as well. Copyleft licenses have restrictions, but as long as you follow those restrictions, you can build whatever you want using the software. SSPL, FSL, BUSL licenses outright prevent you from competing in certain commercial ways, no matter what.
Just because most business models don't want to comply with copyleft doesn't mean it's not open source - it just means it doesn't fit your business model.
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?
Good timing.
And .NET can bundle the runtime, even in a single binary if you prefer that.
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.
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.
The JVM and the .NET clr are just runtime JIT engines. It’s not like they ship with a full O/S and a hypervisor.
* compare with eBPF
Rust would have been a better choice.
> Publishing your app as Native AOT produces an app that's self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.
https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
While there are limitations, this is an active area of work for future versions of .NET.
(On the other hand, call me an old fart, but my trust in Microsoft has been completely eroded in early millennium and did not came back.)
Yeah sure.
On one hand I could see why Microsoft would back the original project, since they likely don’t want Amazon owning a replacement (elasticsearch). But I’m not sure how they plan to honour the new licensing?
“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?
There's a lot less incentive for Microsoft to muck about with the license and in that sense it's not really about trust.
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.
I wonder if they knew that was coming and disagreed. Or knew it was coming and didn't want to take the hit to their reputation. Agree or not with the move, there is a reputation hit. Or was it them leaving that enabled the change to be pushed through?
This is entirely speculation and just something I noticed with Hashi and now see repeat with Redis.
Or had enough sway to prevent it happening before they left?
> just something I noticed with Hashi and now see repeat with Redis
The similarity wasn't lost on me either.
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)
The GNU people fought the good fight on free/libre software, but they lost because companies are greedy and devs are lazy at their day jobs.
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
“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.”
Bad choice of example!
For big compagnies, this a game-changer because you can spare yourself months of "work".
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).
I believe I already stipulated that companies are greedy and devs are lazy. I hope you don't consider your comment a counterargument.
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'?
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.
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.
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.
If I don't mind antirez not working on Redis any more, I can always fork it and do my own development.
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.
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))
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.
If hundreds of commits are baked into a software - under an open source license but without the full copyright transferred to a central legal entity - then it becomes impossible to change the license post-hoc.
3 clause BSD gives everyone permission to use it in new works that are made available using license terms of one’s own choosing, so long as the obligations of those 3 clauses continue to be met.
But what I get from this is: The project switched away from 3 clause BSD to something that is less permissive.
Licenses like the GPL come with an obligation that one not add restrictions when passing the software on to others.
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!
We initially used Redis because, well, Laravel recommends it. But, what I learned is that Redis is not a requirement until you absolutely need it.
For Rails use, 37Signals recently released the open source solid queue package, meant for use with either msyql or postgres. It makes some odd choices, like separating things into different tables depending on state. And it also makes careful use of the not-necessarily-super-well-known (but standard, and in both mysql and postgres) `FOR UPDATE SKIP LOCKED` clause.
These choices were to get good performance at high volumes, which they think they have done and tested.
So it can be done! Probably. And indeed solid queue is MIT-licensed, there are not barriers to looking at the choices they made and copying them in whatever language/platform you want.
But it's not necessarily trivial. At non-huge volumes though it's probably not an issue.
> 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...
Their reasoning[0] for not considering it open source is that due to the requirement that all interfacing software (my words) must also be open source it restricts the possible fields the software can be used in. Reread that sentence! that's exactly the intent of the original GPL license, and follows directly from the philosophy of its progenitor.
If the original GPL was proposed today, then following this reasoning the OSI would not have approved it. Imagine today the Nginx project would switch its license from MIT to GPLv2. Just regular old GPLv2. Would the OSI also complain that previous contributors thought they were contributing towards the "greater good" and now their software is embedded in a proprietary product, just because nginx plugins now have to be open source as well?
The OSI shouldn't be chasing some vague "greater good". They should be protecting the spirit of open source. Which includes copyleft licenses like GPL, AGPL and SSPL.
[0] https://opensource.org/blog/the-sspl-is-not-an-open-source-l...
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.
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
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.
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)
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.
Not sure how that could be the case. SSPL places additional restrictions on the usage of the software, so you cannot relicense GPL code as SSPL.
We've been thinking about how we'd discuss large and controversial licenses in a productive way. We're learning how to drive large, productive, difficult conversations with the process towards the Open Source AI Definition[1] and we hope (soon) to be able to transfer that knowledge to other pressing issues, like complex licenses.
[0] https://opensource.org/blog/osi-executive-director [1] https://opensource.org/deepdive
That the communication with MongoDB crashed and left a sour after taste I can imagine. But the fact now is that there's a deeply flawed SSPL out there, OSI's only real public statement is very dismissive of it. It does not address at all the concerns of Elastic or MongoDB, painting them as some sort of bad guys, when in fact their products have always been open source, even when they were so valuable they really didn't need to be.
And the companies that drove them away from what OSI considers open source, are OSI's two biggest sponsors! Two sponsors it is worth mentioning, who built their products entirely as proprietary closed software, on top of open source software.
So now, wether they meant to or not, OSI has profiled themselves as defenders of proprietary platforms, making no effort to acknowledge the plight of open source companies, and lost credibility to such a degree that now again one the great open source companies has dismissed their approval and went for an unapproved license.
If the OSI was really serious about the "greater good", they would have worked with the FSF and helped MongoDB, Elastic and Redislabs defend against proprietary platform companies such as AWS and Google with an AGPLv4 that has the provisions the SSPL introduced without causing the concerns other people raised in this thread with regard to (possibly intentional?) vagueness around what does and does not need to be open sourced.
If that had happened, then maybe today Redislabs would have announced their switch to an OSI approved open source license, and the OSI would have retained its legitimacy and reputation. How many great budding open source/open core projects have been inspired by the success of Redis, MongoDB and Elastic, that now will consider the same path as these companies, or worse, that of Hashicorp?
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
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.
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.
Let's have a coffee and you can explain to me why you think this would be useful. I'll email you.
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.
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.
Certification with OSI
"In 2018, MongoDB submitted the license to the Open Source Initiative (OSI) for approval. The company withdrew its submission in 2019.[19][20] In January 2021, following the re-licensing move by Elastic, OSI released a statement declaring that the SSPL does not comply with its Open Source Definition because it discriminates against specific fields of endeavor,[which?] describing it as a "fauxpen" source license.[7]"
wikipedia links to https://opensource.org/blog/the-sspl-is-not-an-open-source-l...
So it would seem your take is not quite accurate. It's not simply that it was withdrawn, the OSI board of directors has made public statements.
I'd note that the argument made above "discriminating against specific fields of endeavor" is not fundamentally different than other viral copyleft licenses.
While it has a big poison pill, the whole point of viral copyleft statements is about having a poison pill. The GPL arguably discriminates against fields of endeavor (i.e. closed source code, actually preventing it). The SSPL discriminates against cloud service providers by having a poison pill, which in theory, actually discriminates less, as that field is allowed to use it, just the requirements to use it might be to onerous to be reasonable. But there should be no logical difference if its just about "discriminating against specific fields of endeavor".
i.e. it comes down to a value/emotional statement vs a pure logic statement. The value is that cloud providers need to be allowed to use the code without severe restriction, while its ok to prevent closed source products from using the code.
It's fine for the OSI to make decisions that are not purely logical, but are simply about trying to protect the values that they want to push, but they should also be honest about it.
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.
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.
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.
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!
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.
ps. yes, I am aware of license vs copyright distinction and relation they create.
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.
Microsoft/Azure already agreed to enter new license agreement, others will follow if they haven't done it yet.
Nobody will notice anything, nothing will change for anybody. Some forks will popup and die off for sure though.
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)
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.
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
note: I am not disagreeing with the license change, just asking why you think nobody is affected.
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.
Momento is likely impacted.
Affects them how?
The number of businesses providing managed redis is very small, isn't it?
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?
Try the AGPL.
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.
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.
> the overall mission, has foundered.
Absolutely not. I've never had so much freedom on how to do computing.
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.
Half the world’s communication being under the control of one company with a dictator is hardly a success.
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?
But they were comparing to "10 years ago. Or 20."
> 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.
Linux only became a viable desktop around 2010.
Blender was open sourced in the early 2000.
StarOffice was a viable alternative to MS Office 2003.
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.
- 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.
Huh? Where?
I don't see how that confusion applies to the tradeoffs discussed here.
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.
But the problem is not because they're conflating it with "free as in speech". They're ignoring that aspect entirely.
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.
If the original case for the GLP is still not covered by the AGPL in $current_year open source licenses have failed.
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?
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.
No.
Questions for you:
1. What was advertised?
2. By who?
3. Where?
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 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..."
I have never seen a fork last long enough.
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).
Seriously, the number of succesful forks is huge.
Probably some survivor bias
It’s going excellent! I’m surprised by how well adoption is going.
Just the day before yesterday we had OpenTofu Day at KubeCon, and instead of the expected ~30 people we had 150-200 attendees and a packed room!
The next major release, 1.7, is coming out soon too.
What exactly is the material impact on a developer with this licensing change? There is a tendency these days to sensationalise things without getting to the bottom of it or even reading the whole article.
What did the OSS Redis project promise a developer that it is not going to deliver in the new licensing model?
It 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.
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.
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.
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.
I think you should not feel shafted, but if you do there is a simple and obvious solution.
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).
And use an appropriate license. Don't use BSD if you don't want people taking your stuff and closing it up.
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...
What they did do is decide that in the future, their work won't be as easily taken advantage of.
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.
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.
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.
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.
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.
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.
"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.
why are people surprised when other people start using the software/close sourcing/packaging it and selling it?
> 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 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.
maybe we wait for a few months before making wild statements like this, software is not about chasing the latest hype
EDIT: Ironically, the SSPL seems to be more open than the copyleft counterpart (AGPL) - the difference is that it enforces releasing the whole service source. Any discussion assuming that the new dual licensing model is hurting the users' freed is actually unfounded.
---
About SSPL (https://redis.com/legal/licenses):
SSPL is a source-available license created by MongoDB, who set out to craft a license that embodied the ideals of open source, allowing free and unrestricted use, modification, and redistribution, with the simple requirement that if you provide the product as a service to others, you must also publicly release any modifications as well as the source code of your management layers under SSPL.
SSPL is based on GPLv3, and is considered a copyleft license. This means that if you use the source code and create derivative works, those derivative works must also be licensed under SSPL and released publicly. For more information, MongoDB has a good FAQ.
Note that SSPL has not been approved by the OSI, and we do not refer to it as an Open Source license.
This makes it sound like it's just a matter of resources or time to just get it approved, which is misleading. Field of use restrictions go against most definitions of open source or free software, and it was on track to be rejected by OSI until they withdrew from the process.
https://opensource.org/blog/the-sspl-is-not-an-open-source-l...
Similarly, Debian also rejected classifying it as open.
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.
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
- https://github.com/dragonflydb/dragonfly (BSL-licensed, aka not OSS).
- https://github.com/Snapchat/KeyDB (BSD-licensed)
Anyone using one of these?
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.
There will be almost certainly some OpenRedis project, but this move might just kill the wider community interest.
It's a bit different though, since it was already on a proprietary license, and they just changed the terms.
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
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?
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.
https://en.wikipedia.org/wiki/Redis_(company)?useskin=vector
It's funny and hypocritical that a corporation, which used the very terms of the license they now seem to hate in order to come into existence in the first place, is closing that exact path out.
Or in the spirit of YC, is there yarcdis (yet-another-redis-clone-dis) awaiting in the wings?
...what enterprise shops are you working in? Everywhere I've worked the paid software sucked, often in direct proportion to its cost.
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.
Did I get it right?
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."
That doesn't mean it isn't worth exploring but lacking a major piece of functionality means it explicitly can't be "dropped in" to replace redis.
"Starting on March 20th, 2024" doesn't seem right to me.
"... Redis follows a dual-licensing model with all Redis project code contributions under version 7.4 and subsequent releases governed by the Redis Software Grant and Contributor License Agreement."
So it is tied to version 7.4
Open source is about building something together for everyone's advantage. We throw our skills into the pot, be it coding, documentation, or spreading the word. The coolest part? When someone takes the software and does something incredible with it, something we never thought of! That's the power of open source – it goes way beyond what any one person can achieve.
Here's the thing: contributing to open source isn't about getting something back directly for your work. It's about building something awesome for the greater good. You put your stuff out there, and someone else might end up building a million-dollar company on it. That's not exploitation, that's someone being really good at using the tool we built together.
YOU SHOULD NEVER EXPECT THE BENEFIT FROM THE CONTRIBUTIONS YOU DO TO A OPEN SOURCE SOFTWARE BUT INSTEAD EXPECT THE BENEFIT FROM THE SOFTWARE YOU ARE CONTRIBUTING TO.
If you need specific control over how your code is used, open source might not be the best fit. There are permissive licenses that let people modify your work as long as they follow your rules.
The bottom line: open source is about sharing and building something bigger than ourselves. Let's celebrate the ways our contributions empower others, not hold grudges because someone else figured out a killer way to use our work.
At Earthly, a few years ago, the founder and CEO had these same concerns about big cloud providers and switched to a source available license. There was backlash, and after around a year, we switched back to open source. We've discussed things like this a lot, and believe an open source license is best for our product, our users, and our business.
The way that we differ from Hashicorp, Redis, and others that have switched to source available licenses is that the service we offer and generate revenue from isn't just a hosted version of our OSS. It's several services that natively integrate with our OSS but are not open source. This seems like one of the only ways a company that maintains popular OSS can survive without switching licenses: build great OSS that users love, build non-OSS services that integrate with and augment your OSS (and/or open up new use cases), and charge for those services.
If the service a company sells is just a hosted version of their OSS, even if it has a bunch of non-OSS bells and whistles added on, that company is at risk of a cloud provider eating their lunch unless they switch to a non-OSS license.
* Open Source Inside Baseball: https://oxide.computer/podcasts/oxide-and-friends/1086076 * Open Source and Capitalism: https://oxide.computer/podcasts/oxide-and-friends/1564203 * Open Source Anti-Patterns: https://oxide.computer/podcasts/oxide-and-friends/1482742
They don't say so explicitly, but it looks like the community-led open source governance model is gone too? Not already discussed on this thread I think.
In 2020 when antirez stepped down, Redis the company explained:
> "As Salvatore steps back from maintaining Redis, the project’s scale can no longer be managed as a BDFL-style project," explained Gottlieb and Agra. "We see this as an opportunity for Redis to adopt a new model that, hopefully, will promote more teamwork and structure and let us scale up its development and maintenance processes."
> As the Redis Open Source Governance page explains, the project aims "to be as welcoming and inclusive as possible" and toward that end has adopted a Code of Conduct, as many other open source projects have already done.
—https://redis.io/docs/about/governance/
It looks like the "Redis Open Source Governance page" used to be at https://redis.io/docs/about/governance/ ?
Currently 404.
Last scraped by archive.org in October. https://web.archive.org/web/20231030181609/https://redis.io/...
It explained there is a "core team". Not all of whom worked for Redis the company, although largely controlled by Redis the company. So I guess it wasn't exactly community-controlled before, but it's notable there is no longer an "open source governance" model.
antirez's good-bye blog post says:
> I leave Redis in the hands of the Redis community… I’ll just leave Yossi and Oran the task of understanding how to interface with the rest of the Redis developers to find a sustainable development model… I believe I’m not just leaving Redis in the hands of a community of expert programmers, but also in the hands of people who care about the legacy of the community spirit of Redis.
I think they can manage.
[1] https://aws.amazon.com/blogs/opensource/how-to-become-a-redi...
[2] https://redis.com/press/strategic-collaboration-agreement-wi...
"this definition would include hosting or embedding Redis as part of a solution that is sold competitively"
Sure this limits the condition to competing offerings. However in reality that's a huge stop sign. It essentially means "we'll get you" because whatever service/product you offer that somehow includes or so much as touches Redis they can always argue that you are effectively competing. That is they can always make the case that this would have been business to them if only.
I interpret this as "You can't sell Redis as a Service".
You can make any number of applications that use Redis and host the instances yourself, you just can't package Redis and sell/rent a miraculixx-branded version of it.
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.
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.
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 reality is large places will take as much as they can and never give anything unless forced into such a deal. Open source tech is probably tainted in this regard. How many other projects have gone this route for basically the same reason?
I hope this means large tech will actually contribute some money to Redis. I've used Redis for many years and hope they can make some money after giving so much away for so long.
They have still not changed meta description on their page. It still says it is open source ^^
view-source:https://redis.io/
Even Microsoft Windows is source available if you are an important customer: https://www.microsoft.com/en-us/sharedsource/default.aspx
A bit more public and open to anyone is Unreal Engine's source code: https://dev.epicgames.com/documentation/en-us/unreal-engine/...
The majority of people on HN are programmers, the majority of people not on HN are not programmers, the majority of programmers are not on HN.
I can't speak on what the majority of programmers think. Isn't the opinion of people in the open source community the interesting one?
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.
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.
That's not a sustainable relationship for a healthy OSS product, mega cloud corps rake in most of the profits whilst the organizations maintaining them have to handle the burden of increasing customer support issues and developer wages.
The SSPL aka "Free for all, except cloud corps" License should be more common place.
I don't necessarily need redis specifically; infrastructure ecosystems just developed around it because it was both very high-quality and open source. I could probably do most or all of what I do with redis with an rdbms. Or in some cases memcached.
I anticipate switching away from redis.
Wikipedia link: https://en.wikipedia.org/wiki/GNU_Affero_General_Public_Lice...
https://redis.com/blog/redis-adopts-dual-source-available-li...
What a shame.
Nothing IMO.
But many commercial entities won't touch software covered by them, so if wide adoption is one of your desires this could be a significant consideration. You can argue as much as you like about where lines are and how using <component> won't mean they have to open source their entire business, but you'll get nowhere, and the blanket ban will remain. If they really want what your component does they'll do it in-house (and maybe release that under a more permissive licence) or use an alternative if one already exists.
Dual licensing (AGPL with commercial options) usually won't help either: they don't actually want a commercial option because they don't want to pay for things the way they want others to pay their services. Dual licensing can also be an issue for other contributors, it becomes more important to have a CLA⁰ so you can do that at all (legally) and a CLA might put off a lot of potential contributors.
This would not be an issue for me¹², and from your question I assume it wouldn't be for you either, but for some people/projects it could be more important, possibly a blocker.
--
[0] Unless your project is “open source, not open contribution” which is a perfectly valid choice and one I'd likely go for, but again this is not suitable for all people/projects.
[1] “We can't/won't use your stuff under its current licence”. Me: “OK, thanks for letting me know.”
[2] “If you don't do X³ we'll have to go elsewhere”. Me: “OK. Enjoy your trip. Hope it works out for you.”
[3] where X could be a license change or anything else
I am sorry, isnt this the post itself? Or am I missing something?
Between this non-compete clause of their license:
> You may not make the functionality of the Software or a Modified version available to third parties as a service or distribute the Software or a Modified version in a manner that makes the functionality of the Software available to third parties.
..and this clarification in their FAQ:
> A “competitive offering” is a product that is sold to third parties, including through paid support arrangements, that is derived from the Redis’ code-base and significantly overlaps the capabilities of a Redis commercial product. For example, this definition would include hosting or embedding Redis as part of a solution that is sold competitively against our commercial versions of Redis (either Redis Enterprise Software or Redis Cloud).
It’s pretty clear that any SaaS product simply using Redis as a dependency for a completely different product (e.g. Discourse) is in the clear. But it would be nice if they could spell that out as an unaffected use case.
Making the functionality of the Software or Modified version available to third parties includes (...) offering a product or service, the value of which entirely or primarily derives from the value of the Software or Modified version (...).
Since the value is not _primarily_ derived from using Redis, I guess it's fine. I am sure the majority of projects using Redis in some way do not derive their main value from Redis.
I've personally built a little really bad version with only a fraction of the command a couple years ago for fun.
Amazon can absolutely build a fully API compatible service and have that up in no time. It's just silly to try to do this.
The tech itself is usually not mindblowing.
I only install Redis on Ubuntu VMs. I don't pay for hosted Redis (since it's always been rock solid for me).
Will these changes stop me from running `sudo apt install redis`?
Imagine I'm independent provider looking to compete with MongoDB Atlas and ready to Open Source everything I need. But oh wait - I have S3 as my Control plane, EBS, AIM etc - none of which I have option to Open Source.
redis the company, wants a part of that pie.
Certainly not the CNCF.
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.
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.
I like it and I think this is how open source should work to thrive.
I don't know what it would look like, so I won't weigh in on whether or not it would be a good or a bad thing. But it would assuredly be different.
All websites and even value-add proxies likely would not be impacted
The butterfly effect would be massive.
Definitely a different tradeoff that many would not have been confortable in choosing.
Field of use restrictions are a terrible idea, and totally incompatible with “open sourceness”.
If you're running commercial project where you USE redis, not PROVIDE it, you're fine.
Link - https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/...
Context : Redis Inc (fka RedisLabs) started creating ''Redis Modules'' later known as Redis Stack to start differentiating with cloud provider's managed Redis. The idea was to keep Redis Core BSD licensed (one of the most liberal licensing model) but at the same time build a layer on top of this BSD layer to keep differentiating the service.
One of these modules was Redis JSON which allowed you to use Redis as a JSON store. One cloud provider copied the whole codebase (even though it was protected by all the licensing clauses) and it doesn't stop there. JSON.FORGET was a cool command created by one of the exes at Redis & the ''cloud provider'' ended up copying that command as well!
If you're still debating whether a company should continue with a liberal licensing like BSD only to allow cloud providers or other service providers to blatantly plagiarise the codebase, think again.
Like others have said, OSI definition of open source is very outdated and needs to be updated.
For my own use in my company or project as an individual
- Can I have full access to the source, clone it and modify it? YES
- Can I do a pull request to improve it? YES
- Am I allowed to download, use and have it for free in my company even if my project is commercial and is making money from using Redis? YES
- Can I create a product that uses Redis as a technology for free in my startup? YES
- Can I get support if I need it? YES from github as before or as a paid service from the Redis company
- Is there a lot of people to maintain and do bug fixes? YES and they are paid a salary to do so
- Is it a me-and-my-cousin project that will be practically abandoned tomorrow? No. Go check a specific fork's multithreading bugs in github issues. It's scary as fk
- Can I git clone / make / make install it like before? YES
- Is there new features added or planned to be added? I guess this is a YES
- Are the people behind the project paid well enough to maintain and support it? I hope so, certainly it's not best effort after working hours and putting the kids to sleep
- Can I resell Redis as a service taking the source code and running it on my cloud without a paid license? NO (boo hoo hoo)
Personally I don't care if the definition is open source or SSPL or whatever as long as the project is open code, viable, well maintained and improved. Some complaints here sound like this is a religious thing, and I dislike religious freaks.
I am able to use this software for FREE in my company like I used to. I have access to the source code and I can modify it as I want. I can have my commercial web service that extensively uses Redis as a cache for FREE as long as I don't sell Redis itself as a service to hosting customers. Where's the real problem? Where's the problem with Mongo / Elastic / Redis and the likes who try to fight against abusive tactics of AWS?
If I must add a redis repo and then do apt update and apt install redis... Do I care? Sure, it's an extra step but c'mon. It's 2024, not the 90s. The world has changed. AWS has been "screwing open source projects for more than a decade" (tm)
Why are we scared to face the harsh reality?
Same with Mongo in 2018 and Elastic when they changed their licenses. Same thing, again and again. Nags and complaints from people that, 95% of them, have maybe contributed a typo change in the docs - if so. But they have an opinion about things that are given to them for free and still are free and open. What makes you so entitled? Have you ever said THANK YOU to any of the open source folks? Have you monetarily supported any of them, ever?
Antirez has 21k followers and 9 sponsors who donate on Github. NINE! Not 10, not 50, not 1000 sponsors... it's 9 - a carpenter that lost a finger at work can still count them... You want good open source? Make sure the projects are sustainable, viable and their creators receive love and positive criticism to continue writing code for free for the greater good.
It's only AWS who cares about the license change, no-one else is really affected in reality.
If you're not employed by AWS and you have an issue with Elastic, Mongo, Redis et al changing their license, then you are a convenient fool (sorry). You are not paying good service to the community and the open source movement in it's CORE. OSI execs are happy getting millions from bigcorps in exchange to bending their ethics and views in decision making.
Mongo's discussions with OSI in 2018 is a prime example of that.
AWS is your enemy, not licenses that try to fight against this bully.
This is because Redis is a caching database, and pulls the data into memory for it to be faster. This is by design.
Any company can still use Redis for their needs, only leeches like AWS can't.
BSL is not OSI-approved, but it’s a much more reasonable AWS-resistant license. It’s the same license CockroachDB uses, for example.
KeyDB (BSL, acquired by Snapchat) is also an option: https://keydb.dev/
BSL is a much better license, but it’s a gamble on how long KeyDB will be supported. I don’t want to mess around with such a core part of my architecture.