IMHO this is gonna kill Redis Labs just like Hashicorp is getting owned and seeking a buyout, and not stop anyone from ripping off Redis Labs, because the folks who truly suffer from this are the small startups who just want to use Redis cache without legal bullshit, whereas for AWS to fork Redis is doable and they could even turn it around and make their fork permissively licensed which suddenly makes Redis Labs into the worse choice in terms of license.
It’s a hard choice to make, but imho either keep your code proprietary or stick with “Apache OR MIT” … all this stuff about switching licenses partway down the line is really lame and just seems destined to backfire.
Open Source is about user ownership of software. If we try to get around that with legal trickery to make a buck, then it’s not going to hurt the big corpo teams, but rather the users. Big corpo teams are users too, they don’t want to deal with this legal mess either. Like it or not, Redis has always been a permissive open source project which is why it has been a success. Changing that is changing the equation in that regard going forward and portends bad outcomes for everyone involved.
I'm assuming people are forking this as we speak. Kind of sad to see companies cut themselves off from their own developer communities.
I understand why they do it. I just don't agree it works long term.
Most Redis users have never paid the company behind it even a single cent. Me included. So, I can appreciate them doing this in order to make some money. Except it won't change my behavior; I'll just use the fork. Just like the vast majority of other Redis users, external Redis contributors, all of the cloud providers currently offering Redis commercially, and by the time this runs it course probably a fair bit of current Redis employees.
Given the large amount of commercial users and cloud providers offering Redis, I don't think it will take long for them to get organized even. They pretty much have to given that they have lots of users paying them for this.
There are some precedents with Terraform, Elasticsearch, Red Hat, and a few other big players now dealing with a lot of their target users and potential customers depending on open source forks. As a business strategy alienating future users like that seems misguided.
When Oracle took ownership of Sun's open source projects (including such things as mysql, hudson, openoffice, etc.), they quickly lost control of most of that. Oracle's attempts to convince the world to use their closed source offerings never amounted to much. Even with Java, they more or less gave in and openjdk is where the action is these days. Except for a few banks, very few people use the Oracle JDK. There's no need, Oracle has long ago stopped pretending there's any advantage to that. All the development happens on OpenJDK. There are half a dozen different companies offering certified builds.
Anecdotically, I consult on Elasticsearch and Opensearch. Most of my recent clients default to Opensearch. It's just the way it is. They all go for the free and open source option.
The point here is that this can only end in one way: the creation of a Redis fork that will be used by the vast majority of current Redis users.
Microsoft introduced an almost drop in replacement 3 days ago[1]. It is claimed to work with most Redis clients. I believe this will change things quite a bit a least for Azure users.
I think the long term game works if you look at it from a Broadcom style prospective. You're not looking to snag many users but rather the few very expensive ones who have built themselves around the product. From the Businesses prospective they'll pay the increased prices to avoid moving completely or in the short term during migrations.
To avoid the short term, providers could "buy time" and keep prices low until the project deviates far enough from forks, making migration much harder, then increase prices.
Either way, long term they can end up with a lot of money from a few companies rather than continuing to support many mixed sized companies.
I see it ending in another way, long term FOSS will be considered a phase in the industry, never to be repeated again, as the industry settles back on trial and demo versions, without full features available on the free tier/source code.
Cynical take: Oracle didn’t need MySQL to be a profit center since it already offers a much more expensive alternative. They enjoyed good ROI by fragmenting the MySQL community, chilling usage and external development, and therefore slowing down the whole project.
> Most Redis users have never paid the company behind it even a single cent. Me included.
Most users never will. That's the fallacy made by MBA types. They dream up some lofty sums "if only everyone paid us money". What they don't realize is that most users will find alternatives.
And Redis as a company can get some cash from certain amount of clients that decided to stick with Redis (even in Oracle's case, this was a non-trivial amount of money)?
For personal projects maybe yes, doesn't work for companies, they can't chase for thousand different forks of Redis and try to understand why feature isn't working properly on their version. Unless single fork emerges as a winner
Revenue through hosting continues to be the big driver for all of these projects, which is what is motivating the license changes.
The trend indicates that only open source libraries work for companies that own projects. If it's a program (e.g. server software like a database) then it's either source available or under a foundation. It's tough and I don't know what the answer is here.
I'd love to see a model that causes the pendulum to swing back the other way with open source permissive licenses for complex programs, but I don't see a viable way yet. Maybe trademark enforcement and open source code only with licensed builds?
Either way, I'm sure we'll continue to see the rise and fall (or license change) of popular open source software for years to come. There's too much benefit for developers and companies to start out open source. And there's too much pressure later on to change it.
At the very least, I'll give Redis credit for giving far more value to the world than they've captured. By an absolutely massive margin.
It'll be interesting to see how long a fork takes to land and if it'll be successful. And it'll be interesting to look at Redis (the company)'s revenue growth curve in 5 years.
> Revenue through hosting continues to be the big driver for all of these projects, which is what is motivating the license changes.
Yeah, isn’t this just massive cloud providers eating the lunch of Redis etc? I don’t know enough about the licensing but I highly empathize with these small-mid sized companies building foundational tech that is commoditized and upcharged by an oligopolistic cloud behemoths. Surprised it's taken this long.
Question: what other alternatives than license changes are there, assuming we want a healthy ecosystem of both businesses and open source?
Personally, I don't find foundations to be a magic solution for this problem. There are many examples where a single company has decided to basically "fork" their way out of foundation housing and the community is left with the same outcome.
It would also help that many developers would acknowledge that we are no different from other professionals, expecting to be paid for our own work, while not wanting to give a dime for the work tools doesn't scale.
Those producing work tools also have bills to pay.
In a way, developers themselves are to blame for the failure of the FOSS dream.
Slowly we are back to the public domain/shareware days.
People always said that the model for making money off open source is support - some company uses e.g. Postgres and they require specialists to help them out and put out fires in their on-prem setup.
But in the age of the "Cloud" companies will simply use the managed offering provided by Amazon/MS/Google/etc. basically destroying any financial opportunities for the maintainers and other people around the project. Also nobody wants to work their ass off on some OSS just to see AWS raking in milions off it without contributing back anything.
More Open Source projects should adopt SSPL, or experiment with LLama 2 style limitations on the size of companies which may use the work for free (for example, Open Source but not if you're a multi-billion cloud megacorp). When individual developers contribute back, they weren't doing it to enable AWS to freeload.
AWS of course is the single biggest reason why projects are flocking to more restrictive licenses. The right thing to do for AWS would have been to respect the work of the original authors (/company) and throw their weight behind an offering supported by the original developers. Instead, AWS builds a competing product when they see an OSS product succeeding. Third party vendors stand no chance after that due to the tighter integration and marketing muscle.
Not to mention, Amazon and AWS give so little back to Open Source despite being a big (the biggest?) beneficiary. Google, Microsoft and even Oracle do more for Open Source than Amazon.
I am fine with SSPL and AGPL as long as there is no CLA which makes me sign me rights over to someone else. I have never contributed to a project with a CLA and unless an employer pays me for it I do not think I ever will.
Some time ago I tried to argue for a FOSS license that would disallow code from being used by AI. I got a lot of negative feedback saying that this wouldn't be FOSS because it imposes restrictions etc. The same is true for the SSPL. But for long term FOSS viability, I think we may need to impose some restrictions to protect ourselves from big bad megacorps who effectively exploit FOSS developers.
> AWS of course is the single biggest reason why projects are flocking to more restrictive licenses
Don't forget that AWS is one of the biggest reasons so many OSS projects became popular. Redis, Mongo, ES, HashiCorp stuff, a complete big data ecosystem, got wider recognition through AWS's offering. Many people have yet to learn about dozens of obscure databases (that have been in development for years) simply because AWS or other big cloud providers have not pushed them.
Also, many projects receive a lot of contributions (bug reports, PRs, patches) due to liberal licenses increasing their use and popularity. I'm not particularly eager to contribute to anything with SSPL/BSL/etc-like licenses simply because I don't want to waste my time on something I can't use liberally in the future.
People are forgetting that Redis became big exactly because of it being both free and open. If Redis came out with limitations similar to LLama 2 it would have been dead in the water since the main consumer is enterprise, while LLama 2's primary popularity is because it was one of the first to provide a high quality LLM to individuals for personal use. A KV store that's compatible with RESP is nothing particularly special, shoot Microsoft just released their own (garnet) under an MIT license. The value of Redis was always it being both free and open source and the community that supported it. As of now they just dropped the biggest reason to use Redis.
> The right thing to do for AWS would have been to respect the work of the original authors (/company) and throw their weight behind an offering supported by the original developers
That's what they do in some cases - their managed Grafana and Prometheus are a cooperation with Grafana Labs. But it's the only one I'm aware of, practically all other ones (MongoDB, Redis, Memcached, MySQL, PgSQL, etc.) aren't.
> AWS of course is the single biggest reason why projects are flocking to more restrictive licenses
Should be general competition, including AWS, right? AWS does not host a Terraform service, yet HashiCorp feels the pressure from quite a number of competitors that offer Terraform as a service.
Open-source still has a long-term advantage. Long-term, either AWS goes out of business, “enshittifies” their “enhanced” version, and/or open-sources it themselves. Meanwhile, the open-source version never goes away or gets worse: at worst it will bitrot, but that’s only if nobody is using it enough to put in the bare minimum of maintenance (then when AWS inevitably degrades, there’s a good chance someone makes an open-source rewrite).
I guess but AWS is the one being a good steward of actual open source software. It's hard to say they're the evil ones when it's because of them we still have an OSS ElasticSearch for anyone to use as they please.
No one forces you to make OSS, you can be closed source from the beginning and no one will fault you. But companies releasing OSS as a growth hack because it's seen as a donation to the software commons and then rug pulling deserve every fork coming to them. Debian and Fedora don't include JSMin (not that it's relevant anymore but still) because the license says you can't use it for evil making it not OSS.
That's what OSS means -- everyone, even the worst person you know, especially the worst person you know, can use the software for anything they want.
Redis Inc. is moving the https://github.com/redis/redis/ project away from the three part BSD license to a dual license using two non-OSI approved license. This comes after previous comment from them saying that "... the Redis core license, which is and will always be licensed under the 3-Clause- BSD". (https://redis.com/blog/redis-labs-modules-license-changes/)
For those worried about EOL, Redis 7.4 will be the first release under the new license, leaving 7.2 as the last release with the old one. Redis supports 2 additional releases at a given time: latest major.(minor-1), (major-1).(last-minor).
This roughly means that 6.2 will go out of support once 8.0 is released, and 7.2 will go out of support once 7.6, or 8.0 is released.
Looking at prior releases, my guess would be to expect a 8.0 release around Mar-May 2025. So if you're relying on Redis under the 3BSD license, plan accordingly.
Note that Ubuntu packages redis under the `universe` repo, which means security upgrades are only available to Ubuntu Pro customers. So Ubuntu 20.04 will stop redis upgrades on Apr 2024, except for Ubuntu Pro users under ESM.
Debian 11/12 track Redis 6.0/7.0, so they are responsible for backporting the patches from 7.2. Unsure how this will happen once 7.2 stops receiving security updates, and they only go to the 7.4 branch.
Also note that you might be impacted indirectly (even if your usage of redis fits with the new license), because your distro will likely drop redis from its official repos in the next release, so should account for that in the next distro upgrade cycle.
(I maintain https://endoflife.date/redis, happy to merge PRs if someone has clarity on how this might impact EOL/Support)
So the technical founders of both Redis and Hashicorp managed to step down before their respective businesses take on a shitstorm by steering away from FOSS. Unless I have my timelines wrong.
I wonder if they knew that was coming and disagreed. Or knew it was coming and didn't want to take the hit to their reputation. Agree or not with the move, there is a reputation hit. Or was it them leaving that enabled the change to be pushed through?
This is entirely speculation and just something I noticed with Hashi and now see repeat with Redis.
Can someone please explain why this is bad to me or my company, who don't offer a paid, hosted Redis installation? As far as I can see, this license means that Redis the company gets some exclusivity on who can run a hosted version of their product, and everybody else gets it for gratis, with source we can change libre.
And this is why it is a bad idea for open source contributors to transfer their copyright.
If hundreds of commits are baked into a software - under an open source license but without the full copyright transferred to a central legal entity - then it becomes impossible to change the license post-hoc.
Slightly off-topic: Until last week, we used Redis for Laravel queues and cache in our blogging platform. We decided to get rid of Redis and use the database. The reason was that we are planning to allow self-hosting of our software so removing a dependency is a huge win to reduce complexity (didn't know about the license change then). There are a lot of arguments against using a relational DB for queues, but from our testing, it just worked! So, we just went with it in production. Surprisingly, there are no noticeable performance issues so far.
We initially used Redis because, well, Laravel recommends it. But, what I learned is that Redis is not a requirement until you absolutely need it.
> 24. Will Redis accept community contributions under the new license?
> Redis remains a proponent of the open source philosophy and maintains a large number of open source projects. For those who wish to contribute, we remain open to accepting future contributions – as we have done with our source available modules over the past five years.Going forward, acceptance of the contributor license agreement (CLA) by the contributor is necessary in order for us to consider the contribution.
So they don't mind changing the license on their code, but they wouldn't want to have to be subject to the same terms from anyone else...
OSI lost touch with their mission. This SSPL license is clearly an open source license in the full spirit and original intent of open source. It is more aggressively copyleft than AGPL is.
Their reasoning[0] for not considering it open source is that due to the requirement that all interfacing software (my words) must also be open source it restricts the possible fields the software can be used in. Reread that sentence! that's exactly the intent of the original GPL license, and follows directly from the philosophy of its progenitor.
If the original GPL was proposed today, then following this reasoning the OSI would not have approved it. Imagine today the Nginx project would switch its license from MIT to GPLv2. Just regular old GPLv2. Would the OSI also complain that previous contributors thought they were contributing towards the "greater good" and now their software is embedded in a proprietary product, just because nginx plugins now have to be open source as well?
The OSI shouldn't be chasing some vague "greater good". They should be protecting the spirit of open source. Which includes copyleft licenses like GPL, AGPL and SSPL.
Am I the only developer, working for corporation that is using other mega corp's cloud, using redis personally and at work - who sees this as good news?
This change means that cloud providers will have to share premium they're charging customers for offering redis as cloud service.
Developers still have access to source code, you can use it personally and for commercial products, you can use it on your cloud VMs, dockers, k8s etc. as before.
The only affected parties are competing cloud providers - they'll have to share their premium.
What's wrong with that?
Sounds like solid way to build sustainable business around open code.
Also putting together all this other stuff into single package (JSON, vector, probabilistic and time-series) sounds great!
Because once you have strings attached, you need to constantly be aware of it. Sure, this only targets cloud providers, but what if a company wants to host a redis instance for its subsidiaries? Or you expose direct Redis access to certain partners? Or insert any other perfect innocent scenario. Suddenly you need to hire a lawyer.
No, the competing cloud providers would pass that extra premium right to the customers. So the affected parties are those individual customers who want to buy managed Redis from the cloud - the prices will go up for them (if Redis Labs plan were to work)
I am personally fine with running Redis myself, but I can completely understand the people who don't want to bother with this, and get a hosted version -- and pay as little as possible for it.
> Sounds like solid way to build sustainable business around open code.
Yeah, that’s basically my question: how else do they make money? I’d bet that there’s at least one order of magnitude more people who use any of the major cloud providers’ hosted Redis service than who pay for a support contract, and probably at least two orders more than contribute anything substantial to the open source project. At some point you need recurring revenue or development is going to slow dramatically.
Classical "bait-and-switch". Bait users and developers with a fully-open and freely-licensed project, wait for it to gain enough market share, then switch the license to a more restrictive one...
In a few days, a clone called "Libredis" or "Freedis" will probably appear that the community and developers will move to.
So yeah, it might be annnoying buit in the long term it won't matter much anymore (same as the company)
This incident reflects the increasing profit pressure on Redis Inc. Furthermore, Redis' competitive edge in performance is declining, especially with the emergence of alternatives like Dragonfly and Garnet (disscussed here https://news.ycombinator.com/item?id=39752504).
[+] [-] bionhoward|2 years ago|reply
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.
[+] [-] jillesvangurp|2 years ago|reply
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.
[+] [-] volongoto|2 years ago|reply
[1] https://www.microsoft.com/en-us/research/blog/introducing-ga...
[+] [-] lethedata|2 years ago|reply
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.
[+] [-] WhyNotHugo|2 years ago|reply
[+] [-] pjmlp|2 years ago|reply
[+] [-] mmahemoff|2 years ago|reply
[+] [-] miraculixx|2 years ago|reply
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.
[+] [-] Shakahs|2 years ago|reply
[+] [-] thrdbndndn|2 years ago|reply
It sounds like a win-win to me.
[+] [-] lamontcg|2 years ago|reply
[deleted]
[+] [-] throwaw12|2 years ago|reply
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
[+] [-] pauldix|2 years ago|reply
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.
[+] [-] klabb3|2 years ago|reply
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?
[+] [-] _msw_|2 years ago|reply
[+] [-] justinclift|2 years ago|reply
Like the AGPL3?
https://spdx.org/licenses/AGPL-3.0-or-later.html
[+] [-] pjmlp|2 years ago|reply
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.
[+] [-] michaelmrose|2 years ago|reply
That isn't open source.
[+] [-] margorczynski|2 years ago|reply
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.
[+] [-] jeswin|2 years ago|reply
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.
[+] [-] jeltz|2 years ago|reply
[+] [-] elric|2 years ago|reply
[+] [-] dig1|2 years ago|reply
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.
[+] [-] Salgat|2 years ago|reply
[+] [-] sofixa|2 years ago|reply
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.
[+] [-] hintymad|2 years ago|reply
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.
[+] [-] that_guy_iain|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] armchairhacker|2 years ago|reply
[+] [-] Spivak|2 years ago|reply
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.
[+] [-] reconditerose|2 years ago|reply
[+] [-] captn3m0|2 years ago|reply
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)
[+] [-] rwmj|2 years ago|reply
[+] [-] nicce|2 years ago|reply
Good timing.
[+] [-] lawik|2 years ago|reply
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.
[+] [-] stephenr|2 years ago|reply
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.
[+] [-] softwaredoug|2 years ago|reply
[+] [-] stavros|2 years ago|reply
[+] [-] jpfr|2 years ago|reply
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.
[+] [-] supz_k|2 years ago|reply
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.
[+] [-] yjftsjthsd-h|2 years ago|reply
> 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...
[+] [-] tinco|2 years ago|reply
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...
[+] [-] mirekrusin|2 years ago|reply
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!
[+] [-] Ferret7446|2 years ago|reply
[+] [-] theamk|2 years ago|reply
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.
[+] [-] acdha|2 years ago|reply
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.
[+] [-] 8xeh|2 years ago|reply
See: https://news.ycombinator.com/item?id=38841284
[+] [-] dark-star|2 years ago|reply
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)
[+] [-] mindcrime|2 years ago|reply
https://github.com/mindcrime-forks/redis
[+] [-] west0n|2 years ago|reply