by pauldix on 3/20/24, 10:06 PM with 601 comments
by bionhoward on 3/21/24, 6:29 PM
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.
by jillesvangurp on 3/21/24, 7:50 AM
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.
by pauldix on 3/20/24, 10:24 PM
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.
by margorczynski on 3/21/24, 3:58 AM
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.
by jeswin on 3/21/24, 9:13 AM
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.
by reconditerose on 3/20/24, 10:07 PM
by captn3m0 on 3/21/24, 10:20 AM
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)
by rwmj on 3/21/24, 8:12 AM
by nicce on 3/21/24, 8:15 AM
Good timing.
by lawik on 3/21/24, 7:35 AM
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.
by stavros on 3/21/24, 8:37 AM
by jpfr on 3/21/24, 7:46 AM
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.
by supz_k on 3/21/24, 9:24 AM
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.
by yjftsjthsd-h on 3/21/24, 5:20 AM
> 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...
by tinco on 3/21/24, 10:12 AM
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...
by mirekrusin on 3/21/24, 9:15 PM
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!
by 8xeh on 3/21/24, 2:49 AM
by dark-star on 3/21/24, 8:59 AM
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)
by mindcrime on 3/20/24, 11:03 PM
by west0n on 3/21/24, 1:59 AM
by pizza234 on 3/21/24, 7:58 AM
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.
by fermigier on 3/21/24, 9:40 AM
- https://github.com/dragonflydb/dragonfly (BSL-licensed, aka not OSS).
- https://github.com/Snapchat/KeyDB (BSD-licensed)
Anyone using one of these?
by oytis on 3/21/24, 10:06 AM
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.
by justinclift on 3/21/24, 6:30 AM
by zokier on 3/21/24, 9:23 AM
There will be almost certainly some OpenRedis project, but this move might just kill the wider community interest.
by wmf on 3/20/24, 11:04 PM
by ksec on 3/21/24, 4:45 AM
by xenago on 3/21/24, 4:44 PM
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.
by xarope on 3/21/24, 1:22 AM
Or in the spirit of YC, is there yarcdis (yet-another-redis-clone-dis) awaiting in the wings?
by frontalier on 3/21/24, 10:25 AM
Did I get it right?
by littlestymaar on 3/21/24, 9:20 AM
by RicoElectrico on 3/21/24, 1:00 AM
by keyle on 3/21/24, 8:39 AM
"Starting on March 20th, 2024" doesn't seem right to me.
by luffyzoro on 3/21/24, 11:17 PM
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.
by thtmnisamnstr on 3/21/24, 6:44 PM
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.
by garfieldnate on 3/22/24, 12:29 AM
* 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
by randomdev3 on 3/21/24, 8:43 AM
by jrochkind1 on 3/22/24, 12:42 PM
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.
by whateveracct on 3/21/24, 3:52 AM
by Ekaros on 3/21/24, 8:09 AM
by miraculixx on 3/21/24, 7:27 AM
"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.
by depr on 3/21/24, 9:24 AM
by NelsonMinar on 3/21/24, 9:26 PM
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?
by gregors on 3/21/24, 9:35 PM
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.
by renegat0x0 on 3/21/24, 9:02 AM
They have still not changed meta description on their page. It still says it is open source ^^
view-source:https://redis.io/
by mort96 on 3/21/24, 7:45 AM
by mythz on 3/21/24, 10:40 AM
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.
by jrochkind1 on 3/22/24, 12:33 PM
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.
by devaiops9001 on 3/21/24, 10:01 AM
by theanonymousone on 3/21/24, 12:54 PM
Wikipedia link: https://en.wikipedia.org/wiki/GNU_Affero_General_Public_Lice...
by petee on 3/21/24, 9:30 AM
https://redis.com/blog/redis-adopts-dual-source-available-li...
by imranhou on 3/21/24, 7:59 AM
by c0l0 on 3/21/24, 7:31 AM
What a shame.
by codedokode on 3/21/24, 9:58 AM
by opeon on 3/21/24, 10:20 AM
by erlend_sh on 3/21/24, 8:57 AM
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.
by hintymad on 3/21/24, 12:56 AM
by donatj on 3/22/24, 12:40 AM
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.
by Xenoamorphous on 3/21/24, 9:20 AM
by lifesaverluke on 3/21/24, 9:33 AM
by PeterZaitsev on 3/21/24, 5:31 PM
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.
by whaaatttttttzzz on 3/21/24, 6:21 PM
by dingi on 3/22/24, 10:19 AM
by kristopolous on 3/21/24, 8:04 AM
by CrLf on 3/21/24, 9:20 AM
by wg0 on 3/21/24, 8:26 AM
by tejasbaldev on 3/21/24, 10:19 AM
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.
by SuperSandro2000 on 3/21/24, 9:52 AM
by shantnutiwari on 3/21/24, 1:27 PM
Like others have said, OSI definition of open source is very outdated and needs to be updated.
by cmmn-sns on 3/23/24, 9:54 AM
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.
by externedguy on 3/21/24, 9:57 AM
by lionkor on 3/21/24, 8:01 AM
by ftyhbhyjnjk on 3/21/24, 6:42 AM
by byyll on 3/21/24, 11:00 AM
Any company can still use Redis for their needs, only leeches like AWS can't.
by NathanFlurry on 3/21/24, 9:39 AM
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.