620 comments

[ 3.0 ms ] story [ 322 ms ] thread
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/)
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.

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.
> open source permissive licenses for complex programs

Like the AGPL3?

https://spdx.org/licenses/AGPL-3.0-or-later.html

Copyleft isn't permissive. It's a viral license that sets restrictions on derivative works, forks and contribution.
Permissive meaning “freedom” (the eff definition) in this case.
And thank deity for it!

Holy cow am I so glad for every line of that viral leftist restrictive code!

The more GPL code there is in the world, the better off everyone (consumers and business owners both) are.
What virus ever gave you the option of "oh in that case, no thanks, I'll do it some other way" ?
> Revenue through hosting continues to be the big driver for all of these projects, which is what is motivating the license changes.

Yeah, isn’t this just massive cloud providers eating the lunch of Redis etc? I don’t know enough about the licensing but I highly empathize with these small-mid sized companies building foundational tech that is commoditized and upcharged by an oligopolistic cloud behemoths. Surprised it's taken this long.

Question: what other alternatives than license changes are there, assuming we want a healthy ecosystem of both businesses and open source?

TimescaleDB has an open core style license that seems to prevent the cloud services from repackaging their DB.

It's not technically fully open source, but it's pretty close to it.

Actually, I just took another look and they now market their "open core" as the apache edition (or perhaps have diverged from the "community edition" now)

> open source code only with licensed builds

That isn't open source.

> 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.

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.

Developers are entirely to blame - the fraction of developers meaningfully contributing to FOSS or advocating for supporting it is tiny. Just ‘import foo’ and holy smokes - free shit, yes please!
I can't see how you can shoulder the blame of (possible) failure of FOSS dream on developers. Devs (usually) don't control budgets and can't really ask for money to pay for freely licensed code. If blame is to be given then I'd point to money handlers for not acknowledging this situation.

Then there's the question of what I should be paying anyway. Who among all those non-free developers are paying in turn to all the professionals whose code they build on? Are proprietary developers somehow exempt from paying themselves? If and when I choose to pay I like to think all that contributed are getting the benefit.

There's a long line of professionals behind every code that should have been paid. Certain percentage might have tried to get paid. And even some who in fact did get paid.

Easy, there is no need to try to use every tool under the Sun.

Do as we did before the GNU days, analyse what really matters for a specific project development, pay for those tools, and keep using them until they aren't suitable any longer.

Ha. I'm not sure your remark really responds to my concerns. I do use very small set from all the things. And do pay (small amount, I admit) money to some of them.

If I choose to pay for a tool and the tool maker doesn't pay for their tools, then how much better off we are? I can't really see this next iteration of non-GNU ecosystem faring that much better if only few benefit.

And for that matter, I did pay money for non-free tools. And bought Linux on those CDs distributors used to sell. Then the free-er ones somehow got better, so that revenue stream had nowhere to go. As I said, there's no easy way to pay for free stuff.

Just in case anybody needs it, here's a fork from the last commit before the license change.

https://github.com/mindcrime-forks/redis

what a perfect org name for capturing these rug pulls, second to "github.com/lol-our-incredible-open-source-journey" or "gitlab.com/but-aws-gonna-steal-our-shit"
Honestly, I created it just to keep things organized. I fork a lot of projects for different reasons, but mostly just to keep a copy around for when "weird shit happens". Eventually I had some many forked projects in my "mindcrime" org that they got in the way, so creating a "mindcrime-forks" and moving all the forks there seemed like an obvious choice.

I also did a "mindcrime-templates" for template pom.xml files, and silly little "starter projects" of various sorts that I can clone down and and have something set up the way I like it, with minimal scaffolding, and then start morphing it into whatever I need.

The use of the word "permissive" here to describe super-strong copyleft licenses is uh, interesting. https://en.wikipedia.org/wiki/Permissive_software_license
That doesn't seem accurate?

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?

Redis is using the wrong definition of permissive.
What does dual license mean here? Does that mean that Redis is subject to one of the two licenses, or to both of them?
You can choose either license.
That's not strictly accurate. SSPLv1 is only a choice for the source code. One can elect to use RSALv2 for both binaries and source code.
So far, the most viable route of FOSS monetization seems to be "open core". Android, SQLite, GitLab, VSCode, Docker to name a few.
Open core companies, including Redis, are the ones switching to fake open source licenses.
Indeed Redis was open core before the switch, sorry that I didn't check. And being open core was not enough for them, SMH.

Maybe such is the destiny of foundational open source server software... If it's "cloudable" no profitable business will come out of it.

Redis was open before the trademark was acquired from antirez by Garantia Data, who then re-branded themselves as RedisLabs, and then as Redis. This was definitely not a predestined outcome, there are plenty of other foundational open source server software that transitioned to a software foundation. While I worked on the redis core team (https://redis.com/blog/new-governance-for-redis/), I advocated to move it to a foundation.
Foundations don't pay the bills either; see Linkerd.
Yes, but the point is that the project started as, and gained success as, a not-paying-the-bills endeavour. The fact that RedisLabs desires to get enough to pay a bunch of staff is not actually a requirement for redis to exist and thrive, they just happen to own the trademark.
Exactly. Redis (the company) had plenty of opportunity to monetize either a cloud offering or their enterprise offering. They have a lot of cool technology like vector search and time series extensions that people will readily pay for. They could have found a path of moving the core to a foundation and continuing to make money with their added value. They're choosing to get the value they can out of the open-source stack. It might work out well for them, but I can't believe it will be good in the long term for Redis users.
> Maybe such is the destiny of foundational open source server software... If it's "cloudable" no profitable business will come out of it.

I really hope it's not true, but many clues suggest it might be.

I like the concept of open core with a very liberal license. Perhaps there should be a special "MIT-X" (an example, it would be certainly not compatible) license with a clause borrowed from that of Llama2 for large organizations, as Additional Commercial Terms [0].

[0] https://ai.meta.com/llama/license/

You means this?

"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."

KeyDB, a multithreaded drop-in replacement for Redis, under MIT, owned by Snap.

https://docs.keydb.dev/

I realise they use the term "drop in replacement", but without Lua support it really isn't.

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.

Is SQLite "open core"?
Yes! There are modules such as encryption, compression and more thorough test suite (for safety-critical users) that SQLite authors only offer at charge.
Also known as Shareware/Public Domain back in the old days before GNU's adoption.
This on the heels of microsoft's garnet announcement (https://news.ycombinator.com/item?id=39752504)... Would be a shame to see this be the death knell of redis.

Or in the spirit of YC, is there yarcdis (yet-another-redis-clone-dis) awaiting in the wings?

Great to see we have alternatives. I think Redis management doesn't understand how people choose software these days.
That is why enterprise shops than get all the cool toys, because many devs aren't willing to pay for their tools, and then they wonder when their toys aren't available any longer as the creators got enough CV coverage to get a proper job, doing proprietary software for big corps.
> That is why enterprise shops than get all the cool toys

...what enterprise shops are you working in? Everywhere I've worked the paid software sucked, often in direct proportion to its cost.

Stuff like Clion, Visual Studio, Unity Pro, Photoshop, Outsystems, Qt, macOS/Windows vs Linux Desktop, ....
Having recently left a job that let me run Ubuntu and started a job that forces me to use Windows, that is an excellent example of the proprietary/paid option being awful in comparison to the FOSS option. The rest I've not used so can't say with any confidence.
It starts by not expecting every OS to be a UNIX clone.
> Great to see we have alternatives.

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.

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).
Garnet was released a few days ago, how exactly is it making Redis lose its edge in performance?

maybe we wait for a few months before making wild statements like this, software is not about chasing the latest hype

the trend of milking revenue from a few sources with license changes is cringe.
People always said that the model for making money off open source is support - some company uses e.g. Postgres and they require specialists to help them out and put out fires in their on-prem setup.

But in the age of the "Cloud" companies will simply use the managed offering provided by Amazon/MS/Google/etc. basically destroying any financial opportunities for the maintainers and other people around the project. Also nobody wants to work their ass off on some OSS just to see AWS raking in milions off it without contributing back anything.

Disclosure: I work for Amazon, but I don't work directly on Redis related cloud services. I am close to the Open Source Program Office, and I care a lot about the people who do the hard work required to collaborate on open source projects.

Madelyn Olson did the hard work for years to earn the trust of other Redis core developers to become a core maintainer, all while employed by AWS to do that work. She and other AWS developers have contributed a lot to the core Redis engine. Some may say that they too worked their asses off for the Redis community.

You can read more about some of those contributions here: https://aws.amazon.com/blogs/opensource/behind-the-scenes-on...

I think most people are aware of the occasional contributions from the behemoths. Sometimes, entire projects. But charity is not a sustainable business model. When you provide a service offering the marginal returns go to the provider. In the B2B world, that’s a golden deal for these companies. Normally, you’d have a rev share or something like it. So it’s very understandable there’s a shift in the industry. It’s probably for the better for everyone.
"Occasional contributions" don't earn an invitation to become a Redis core maintainer. Please stop diminishing the tireless work of FOSS maintainers.
I’m obviously talking about corporate FOSS contributions overall, not any individual contributor. There’s also a difference being on FAANG payroll vs maintaining without financial stability, which is the reality for most FOSS maintainers.
They get paid for it. Don't try to spin this as if it's someone people working on it in their spare time out of the goodness of their heart. It's just their job.

Amazon simultaneously wants to be "part of the community" but also extract the maximum amount of profit via AWS. Amazon can just do a deal with Redis to share a percentage of the profits from their Redis usage. They don't have to, but they could. But no, they insist on having it for free, and we should be grateful that benevolent Amazon with their $23 billion operating income (from AWS) deems Redis worthy for a contributor or two (which is of course entirely in their own interest). Give me a break.

Amazon Inc. wants to maximize profits. Okay fair. I'm not against capitalism. But it holds others to a different standard by insisting they only (not Amazon) should be beholden to some different type of post-capitalist post-scarcity "let's all share together in community" type of model and cries crocodile tears when they model of extracting the maximum in profits while giving the minimum in return blows up in their face. You reap what you sow.

Amazon needs to either hold everyone to the same standard as they have for themselves or stop whining.

> They get paid for it. Don't try to spin this as if it's someone people working on it in their spare time out of the goodness of their heart. It's just their job.

No, you can't have this both ways. I'm the main contributor from AWS, and I've worked many times on weekends because I care about open source. I like helping people, I don't need to be paid to do it. Many of the AWS folks that made changes were normal engineers that were excited to be part of Redis. https://github.com/redis/redis/pull/10419 and https://github.com/redis/redis/pull/8621 are both examples of features someone from AWS built in their free time. We're all upset about this. Not because Redis deserves to get paid, it's that they acted like they were being good stewards of the open-source community and then they changed their mind.

I'm sure you do, but that changes nothing about the problematic nature of Amazon's relationship with a lot of projects it interacts with, which is really what this is about: "Amazon thinks that by throwing some contributions at a project offsets for depriving a project of its main revenue". Well, it doesn't. My landlord and Tesco doesn't accept code contributions as payment. This is why this keeps happening again and again with all sort of projects. You reap what you sow.
> My landlord and Tesco doesn't accept code contributions as payment

Your landlord and Tesco aren't an open source project.

If for instance I get paid $X to specifically work on Redis by Y. The open source project now has effectively a full time engineer they aren't paying for, one that likely would not be a full time engineer for redis otherwise.

You cannot have "Amazon engineers contribute to redis" and "Amazon pays redis $X every month" and Amazon is only an example here, it could be Costco or IKEA or whatever.

So your argument is that instead of having OSS contributions from some of the best engineers in the world, redis (and other now OSS software) should compete with FAANG to pay those engineers.

Guaranteed one of the FAANG companies would just develop the tools internally instead if paying redis.

> You cannot have "Amazon engineers contribute to redis" and "Amazon pays redis $X every month" and Amazon is only an example here, it could be Costco or IKEA or whatever.

Wouldn't be better for both Redis, community and OSS movement if

1) Redis was fully OSS

2) AWS has a deal with Redis Labs were they share some X% of the revenue of their income for managed Redis (ElastiCache)

3) Redis Labs with that revenue can hire more maintainers

3a) Redis Labs with that revenue can pursue a competitive offering to ElastiCache (booom!)

4) AWS can still hire their developers and try to make them core maintainers to steer Redis development into implementing features they want/need

It's really impossible for me to paint AWS as the good citizen here and Redis Labs as the villain.

EDIT: I also wonder what history would have been if antirez started or moved to an AGPL3 licensing early on.

All this hinges in redis being a for profit with OSS software and not competing with AWS, that isn't happening though AWS won't happily fund their competitors and definitely wont contribute developer time to it.

Redis is partly where it is because of large FAANG companies contributing to redis, that cannot be discounted.

I don't have the time but go strip out all commits from FAANG companies employee and see if redis would be the product it is currently.

I'm not saying AWS is right but at the same time that is what redis decided to allow when they used the model they did. Now that they see they could be making a ton of money they want to retroactively change their licensing which is arguably also bad.

It's a money grab both ways which is what I have an issue with.

I'm pretty sure we will see AWS fork redis just before the license change and keep developing from there. They could even also then have all new code be proprietary as far as the current license allows that.

My argument is the industry in general is probably going to be worse of after this move than before.

> Redis is partly where it is because of large FAANG companies contributing to redis, that cannot be discounted.

Redis is offered as a managed offering by AWS and other because it was already very popular between developers that were clients or potential clients of cloud vendors. That it is/was used also by FAANG companies doesn't change a thing in this part of the story. (And no, I don't believe Redis is popular because it was used by FAANG companies which also contributed back)

AWS has no problem with running and contributing to AGPL projects. This entire wave of taking OSS closed started with Mongo switching away from AGPL for the same reasons that Redis is doing it today.

All of these companies trying to sell OSS are unhappy that AWS is competing with them on maintenance. AWS is more or less fully living up to the ideals of OSS - they share the code, they contribute to the core, they share processes and so on (to a greater or lesser extent). That's why the FSF or SFC have no problems with AWS.

However, these companies don't want to collaborate with AWS on building Redis or Mongo or whatever. They want AWS to be their customer, or at least to stop being their competitor. And FOSS has never been about preventing others from becoming your competitors.

> All of these companies trying to sell OSS are unhappy that AWS is competing with them on maintenance. AWS is more or less fully living up to the ideals of OSS - they share the code, they contribute to the core, they share processes and so on (to a greater or lesser extent).

Can you point me to the code describing some of the secret sauce used by AWS? If AWS was a real good OSS citizen, they would use FLOSS software and create FLOSS automation to operate it at scale, no? We have hundreds of such tools out there: Linux kernel, IPVS, keepealived, HAProxy, Kubernetes etc etc etc. These are all plumbing that are FLOSS. Why isn't AWS publishing their own plumbing as FLOSS so I can potentially run a mini-AWS in my datacenter?

I was only talking about their Redis service or Mongodb service. As far as I know, they are sharing their contributions as required by the license (or even beyond, in the case of Redis' former BSD license).
> instead of having OSS contributions from some of the best engineers in the world, redis (and other now OSS software) should compete with FAANG to pay those engineers.

This already happens. Amazon is never the main contributor. That blog post talks about 33 commits for MariaDB for 2023. Like, that's great and all, but that project doesn't run on those 33 commits. It's the same with Elastic; when they did their license change I looked a bit at the commit history, and something like >95% was by Elastic.

And all these projects that did license changes are fine.

reconditerose wrote above:

> At that time Redis created an open governing board that took over, with a majority of contributions coming from the community during this time (~25% of contributions came from Redis engineers, ~75% from the community, including ~3% that came from me personally).

So, while I believe you're true in the general case, you appear to be wrong about Redis in particular.

I question whether AWS is depriving Redis of their revenue. You just can’t pay every single open source author for their work, too much overhead in maintaining all the contracts, especially if the software is offered as a service. You need the billing in place, certifications, support contracts, data sharing agreements, etc. As a company you want to optimize the number of business partners you have to deal with, and this is the value AWS offers, not Redis.
>We're all upset about this. Not because Redis deserves to get paid, it's that they acted like they were being good stewards of the open-source community and then they changed their mind.

I'm an open-source zealot and I have no beef with the SSPL.

Redis is still an open-source project for 99.99999999999% of entities on Earth. The only people crying foul about this are tech giants and the corporate drones at the OSI. Sorry if this sounds harsh, but normal people don't care about either of you.

I'm not going to shed a tear for your trillion $ market cap company being asked to contribute a little more in exchange for all the wealth they siphon from the rest of the world.

If the tech giant you're cheerleading for is such a fan of open-source, why don't they open-source the management layer like the SSPL asks? This would resolve this beef overnight, right?

The SSPLv1 has fatal flaws that were identified by the open source community during its review for OSI approval. Some of those flaws were attempted to be addressed in the SSPLv2 draft that was never finalized, which is an acknowledgment that the flaws exist.

There isn’t really any way for someone who wanted to offer software licensed under SSPLv1 to comply with the obligations of the license in good faith. This is what makes those obligations a “constructive restriction” [1].

[1] https://meshedinsights.com/2021/01/27/all-open-source-licens...

There are some conditions that don't fit with the OSD (in the view of some, opinions are divided). That's fine. It's allowed to have licenses that don't fit with the OSD. These licenses are not flawed in any objective sense.
The important thing here is that distributions are gonna start moving the packages to non-free repos or removing it altogether. So you'll have to get it as if were a closed source project anyways.
Who is this ‘we’ - you are speaking about people who want the good bits of redis but not the responsibility of helping it sustain a business model built on open source? Your enabling of AWS’s corporate FOSS-washing hasn’t helped redis sustain the model you want it to.
There is no spin here. There are people that work for Amazon that work on FOSS projects out of the goodness of their heart, just like folks who are independent developers, or folks who work for startups, or folks who are just getting started.

When a FOSS maintainer tells you they sometimes do work on the weekends for the love of the community [1] you believe them. The evidence (with timestamps!) is there for all to see in the pull requests and commit history.

[1] https://twitter.com/reconditerose/status/1770697315671535707

Without denying the good intentions and inputs of the individuals going above and beyond to contribute - AWS as a whole contribute peanuts to these projects relative to what they make from them - they have it in their power to make these projects sustainable via healthy revenue sharing but don’t.
You write as if you have all the facts, but I doubt you do.

There are services with varying partnership terms, and there have been services launched with an intent to build long term mutually beneficial relationships that help ensure FOSS projects are well resourced.

“AWS, working with Grafana Labs, will be contributing licensing revenue and code to help make Grafana even better, not just for the AWS service, but also for open source users and Grafana Cloud customers.”

https://aws.amazon.com/blogs/opensource/how-aws-and-grafana-...

You are right - I don't have the details on Amazon's agreements with FOSS projects - have you made them public?

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.

> make these projects sustainable

You’re just showing your ignorance of redis. The project is sustainable without the company as the vast majority of work on the project is done by those who don’t work for the company.

What isn’t currently sustainable is the company. That’s all.

In that case you will have to excuse my conflating this special case with the multitude of other projects the same thing has happened to in the past and will likely continue happening to. I will watch with interest on how the contributors self-organise and prevent the exact same thing happening to whatever fork comes out.
RedisLabs actually was a somewhat hostile takeover of the project by a complete outsider. It commercialized Redis prior, kept trying to trademark the project name, change the company name to RedisDB to confuse users. A few of those attempts were halted by antirez and the community, but after they had thousands of customers he relented. At the time he complained about his own financial challenges and reluctance, but it gave him a just reward at the cost of legitimizing RedisLabs. The history of that company was always as exploitive to Redis OSS and feigning being good citizens. While you may be right in general, this is actually a case of those exploiting OSS winning.
I think the industry's criticism of AWS is understandable, msw. I believe it is time for AWS to come up with a more sustainable method to support the open-source community. By sustainable, I mean financial support and dedicated resources for contributing back to open source. Given your position, I hope you can initiate this type of change. Allocating 0.5 or 1% of AWS's revenue or even profit from each service that utilizes open-source software is unlikely to significantly affect the financial statements, yet it would represent a significant contribution to the open-source community.
We’ve done that. See one example in a sibling reply.
Having an example of doing that is great, but the comment said "each". For example, it matters if Redis got such an offer.
What I meant is a systematic approach to review and reconsider the support mechanisms for all of AWS's current open-source offerings, including those that AWS uses behind the scenes but does not disclose to the public, not just a few services or examples.
Countering a criticism of how Amazon interacts with the projects it uses to drive a large section of its profit with "don't dimish the work FOSS maintainers!" absolutely is a spin. Or some other bad-faith behaviour. It sure as hell isn't a meaningful engagement with the core issues, is it?

> There are people that work for Amazon that work on FOSS projects out of the goodness of their heart

So they work for free then?

Didn't think so.

They just have a job they like. That's great. But lots of people have jobs they like. And lots of people work on weekends. But don't try to spin this as an act of altruism, because it's not.

Why pay redis though? Vs "the community"

How much does redis pay those aws engineers for their contributions?

> They get paid for it. Don't try to spin this as if it's someone people working on it in their spare time out of the goodness of their heart. It's just their job.

I know devs doing exactly this today. Devs who when the actions of their employer would have forced them to diverge from being able to do so, stuck to their convictions so much that they chose to terminate that employet contract so they could continue to do exactly that "in their spare time out of the goodness of their heart."

I will fully admit that I am not that kind of individual, I lack the capacity to contribute meaningfully in that way, but there are certainly many out there in our industry who are.

The beef I have here is that Redis also takes credit for community work. Most of the heavy lifting came from antirez, who created and ran the project up until 2020. (It's worth conceding that Redis did compensate antirez). At that time Redis created an open governing board that took over, with a majority of contributions coming from the community during this time (~25% of contributions came from Redis engineers, ~75% from the community, including ~3% that came from me personally). They own the trademark and the repository, so they can do what they want, but I take issue with the optics that this is really AWS or GCPs or some other vendors fault that Redis decided to blind side it's development community. Redis gave some of us a heads up this was happening, but most people are finding out by a blog post that Redis dissolved the previous open-governance (a fact they barely address in the blog post). We had to drop weeks of work on the floor because we could not longer finish it.
That’s very interesting context and doesn’t look too good on the “Redis governing board” indeed.
https://web.archive.org/web/20231030181609/https://redis.io/...

(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
It seems clear to me (speaking only for myself) that the core team didn't have a say in project governance decisions and changes here. :-(
If core team's pay depends on it maybe they did have a say... Developers also grow up and start families you know
> But charity is not a sustainable business model

Wasn't Dwarf Fortress charity funded for a long time?

It was also just two guys with a moderate paycheck doing what they loved.

They only hit it big when they got the game prettified and on Steam.

Yeah but they got moderate paychecks for like a decade? Isn't that a "sustainable business model"?
So when cloud providers like AWS are contributing to an open source project that they also host, I wouldn't call it "charity". The self-interest is obvious.

The problem is that it may not match the self-interest of other contributors. Especially when there is a "main" company that owns the IP of the open source that is not them.

But note how Amazon forked ElasticSearch when it became no longer open source, to their "OpenSearch" OpenSearch is Apache-licensed. Amazon engineers maintain it. This is not charity exactly, Amazon makes money from selling hosting of it.

In the "classic" age of open source, most projects were collaborations, where different people who got paid by differnet employers worked on it on company time, because their employers used it for their operatons. And were willing to pay to contribute to the software they used. Most of these were not in the business of selling software. They did not expect to make direct money from their contributions to the software.

This is how apache httpd began for instance. I think some of the employers of contributors were non-profit as well.

I think that's actually the only sustainable model for open source. A single company paying people to develop open source software and hoping to make money from that -- was probably never actually sustainable.

If the current economic conditions don't support people working on the clock to contribute to open source software that their employers use -- because software has gotten too complex, or because companies have gotten much more stingy or unwilling to pay for such things -- then indeed we won't have much open source anymore, we'll have proprietary source-available licenses like this.

The work was still on the behalf of AWS and their goal to make money and out compete Redis. it seems like this thread is forgetting that?

The alternate future seems to be a headline like "Redis shuts down and stops development" anyway, so how is this different?

What do you think Redis should do? Continue to let the cloud providers run them out of business? And all because Amazon was gracious enough to fund 1 employee working on it? I think this thread is missing that response.

No, the goal was to make Redis better for its community, which has positive downstream effects for everyone (users, Redis as a service providers-including Redis Ltd, etc.)

And these efforts involved more than one developer. It is only that one of them happened to be a core team member (which required working in good faith for the interest of the Redis community as a whole—a “commitment to the project”).

https://redis.com/blog/redis-core-team-update/

You dodged the core part of my comment and question. Why?

Amazon isn't running and charging for redis as a platform to make redis in the world a better place.

On the “downstream” side of this equation (managed services), the goal is to build a business that delights customers to the point where they part with their money to enjoy it. The ultimate goal there is naturally revenue and profit margin oriented, but _how_ you advance that goal matters a lot. In my experience, focusing on the customer first increases the chances of success.

When such a line of business has a core component that is open source, the growth and health of the “upstream” project, its developers, and the user community is an essential component in its continued success. This is why folks on the ElastiCache team has been increasing their investments in both the upstream project code and in helping to maintain it as a “community-led” project under the previous governance structure.

Those investments increased the provision of digital public goods (as open source licensed software is generally considered to be a “digital public good” even if it is not technically in the public domain). Increasing the provision of digital public goods is generally seen as in service of the public good, as it (more often than not) makes the world a better place.

I think I agree with someone else in this thread. This reads like spin and fluff. We all make quality improvements when we use open source software because we run into our own issues. Were also on a hacker forum, you don't need to respond to me like were at some business partner meeting.

What do you want redis to do though as they are run out of business by amazon and the rest? Who pays for the rest of the developers?

It reads like Amazon is trying to bully their code supplier. The code was out there, and without negotiating Amazon decided on their own "one developer sending TLS upstream seems fair". I'm sure amazon will negotiate with Redis for some amount in the end. Or have the one developer write the drop in replacement if the code is only worth one persons time and some other random commits? Then maybe Amazon can even open source it with no restrictions?

Do you at least see and understand the perspective, that giant companies are making tons of money off software that is out there from smaller people. Giving back what is perceived not that much if anything?

This is like seeing an employee of Philip Morris pointing out that they have employees volunteer to tell kids how smoking is not healthy or like when British Petroleum funds research on green energy... I'm sorry but you're a cog in a machine which is fine but we have structural problems at play here that can't be swept under the rug
> one of my colleagues unknowingly was part of Amazon’s embrace and extend phases so ah… yeah it’s not all bad.
(comment deleted)
May be its time for people to look at memcached again. It is still actively maintained and last release was two days ago.
Unfortunately memcached is missing some features that make Redis very powerful for uses beyond a simple KV cache (for that simple cache usage neither are as important, granted):

1. Replication

When using Redis for things like Session storage, a Job Queue, etc it's important that all hosts (web/app servers) see the same data, which means you either need them to all rely on one single server (which introduces a SPOF) or you need to be able to replicate the data, so that when the primary instance has an issue, a hot spare takes up the load with an existing dataset already in place.

2. Lua

This is slightly less important, but it provides a lot of power: systems like Qless (https://github.com/seomoz/qless) use Lua to run a job queue that executes within Redis, so you get atomic writes for free, and you aren't tied to a specific application language to get a usable queue with consistent features/results.

Microsoft Garnet, licensed under MIT. Uses the same protocol meaning Redis client licenses still work.
> 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...

This is a good decision. Companies like amazon have a habit to rip everyone else.
Their Q&A essentially says you can no longer build anything that is commercial using Redis, except as a partner. That's exactly the opposite of what the SSPL License says.

"this definition would include hosting or embedding Redis as part of a solution that is sold competitively"

Sure this limits the condition to competing offerings. However in reality that's a huge stop sign. It essentially means "we'll get you" because whatever service/product you offer that somehow includes or so much as touches Redis they can always argue that you are effectively competing. That is they can always make the case that this would have been business to them if only.

> "this definition would include hosting or embedding Redis as part of a solution that is sold competitively"

I interpret this as "You can't sell Redis as a Service".

You can make any number of applications that use Redis and host the instances yourself, you just can't package Redis and sell/rent a miraculixx-branded version of it.

I contributed a few LOC to Redis in the past (before "Redis Labs" had taken over), but never signed a CLA or assigned Copyright (that's not even possible in my country of origin). I realize that under the permissive license that I published my contributions under, they can very well do what they are doing. That they are doing it, is disappointing nonetheless. I guess there are more people like me out there, with vastly more important contributions, who feel about the same. I, for one, will not contribute to the project under this new license any more.

What a shame.

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.

> knew that was coming and disagreed. Or knew it was coming and didn't want to take the hit to their reputation

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.

More likely they just had been running a project/company for a while and wanted to move onto new and more interesting things. And/or just cash out.
Alternative title: Redis is no longer open source but rather source available.
Not sure why this is downvoted, it’s accurate.
Aren't those two interchangeable?
They are. The change is that the source is no longer (as?) free.
No really. Many proprietary software are source available but far from being open source.

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/...

That Windows page seems to be from 2015. Wonder if that still applies.
Yes, it does still apply
To a lot of people (if not the majority outside hacker-news), yes.
Why is the opinion of people unfamiliar with the field of programming (i.e the majority outside hacker news) interesting?
You're implying the majority of programmers are HN users, not true ofcourse. HN is just a different, possibly older breed compared to the average programmer. I would say it's not even debatable that the majority of programmers would still consider this open source (since the source is still open), and haven't heard of the term source available. The more accurate statement is, its no longer free (as in freedom).
Incorrect. I'm implying that the majority of HN users are programmers.

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?

Perhaps you thought I meant the majority of all people, I meant the majority of all programmers outside HN (hold a different definition of open source than the more extreme one used here). Not that it matters - but I would say non-programmers have an even higher percentage of people with a different definition.

I mean sure, the more upset reactions from the more invested parties are the more interesting ones. I just take issue with people fighting to use a more-incorrect, less-used definition which serves no purpose other than to try make entities like Redis look bad.

Nope. This is tied to the whole "Free as in speech, not beer" thing.

Open Source has core definitions around the freedoms (the "speech") allowed to people when making use of that source code.

Source available makes the source code available for free (the "beer") along with certain specific freedoms, but not all of the freedoms that would be required to be Open Source.

Whether or not you think those missing freedoms are important is a matter of personal opinion, I suppose. I think they are, which is why I try to avoid source available software if there is a reasonable open source alternative.

Source available need not be free as in beer, though. A company can charge for it, and of course restrict distribution.
Very true. I suppose I should have clarified that source available in the context of a lot of these formerly open source projects, and not as a blanket term.
You seem to be conflating open source with free software—open source implies free as in beer, not speech.
Yes, except some people are trying to redefine English. Open source means the source is open - you can see it.
Famously, "open" is usually considered to be the same as "visible". When people say that a door is open, they typically mean that they can see the door.
Doors are not code but using the same analogy, yes, "open" door would mean the ability to see inside. Not to steal things from inside and resell them.
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.

This is true for copyleft licenses, but not for permissive licenses. And you can still get a copy of the old version under the old license from someone who downloaded it before the license change.
That may be true if a codebase is licensed under the GPL and has a diverse copyright ownership. But the 3 clause BSD is not that.

3 clause BSD gives everyone permission to use it in new works that are made available using license terms of one’s own choosing, so long as the obligations of those 3 clauses continue to be met.

> 3 clause BSD gives everyone permission to use it in new works that are made available using license terms of one’s own choosing, so long as the obligations of those 3 clauses continue to be met.

But what I get from this is: The project switched away from 3 clause BSD to something that is less permissive.

The 3 clause BSD gives all the permissions that are needed for someone to add restrictions via their own license terms.

Licenses like the GPL come with an obligation that one not add restrictions when passing the software on to others.

So how did RedHat add restrictions on gpl code base of CentOS?
RedHat says that you can't get future versions if you exercise your GPL freedoms. You are free to redistribute the latest version of RHEL or CentOS or whatever, including all source code for all packages in their repos. But they will never give you another version of any of their software if you do so.
But the less permissive licence effectively only applies to new modifications to the (contributed) code, which is allowed by BSD, but not by GPL.
When will developers learn that the BSD does not protect you or your users? I understand the philosophical reasons some folks like BSD/MIT-style licenses, but at the end of the day they are not much more than public domain: anyone can take someone’s work and contributions, make improvements and keep the entire thing — original work and contributions, as well as improvements — proprietary.

If you care about a software commons, if you care about benefiting from the improvements others make to your own software, if you care about your users benefiting from the improvements others make: use a copyleft license!

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.

I see it ending in another way, long term FOSS will be considered a phase in the industry, never to be repeated again, as the industry settles back on trial and demo versions, without full features available on the free tier/source code.
That might make sense if the tools in question were created by corporations who used OSS as a pseudo demo.

Redis the project/tool existed long before Redis the company owned it.

Vagrant existed before HashiCorp owned it.

Significantly: both companies dropped permissive licensing after the creator of their (original) products stepped away, and both are venture capital backed companies.

So we could just as easily say "I see that long term people will preemptively fork projects the moment they are owned by a VC backed company"

Which many developers only adopted, because they didn't had to pay anything, while the tool maker's salaries were being burned by VC money.
> because they didn't had to pay anything, while the tool maker's salaries were being burned by VC money

I think you somehow missed the point where Redis the project existed and was extremely popular before it was owned by what is now Redis the company.

The competition for redis in the early days wasn't paid alternatives, it was other open source alternatives; Redis just provided a more featured solution.

Which people adopting Redis didn't had to pay for, if they had to, they would rather suffer with those other less capable open source alternatives instead.
The point is that it wasn't developed by VC money. It was bought with VC money after the fact.

It wasn't a "demo" for a paid product funded by corporate dollars or VC funding, it was just a thing that someone created, and released as an open source project.

It's hilarious that you think the companies dropping open source licenses for the products they bought are going to stop the industry using open source. As I said originally, it's going to have the opposite affect: it's going to make the industry embrace the very nature of open source and create forks of projects, the moment there's a sniff of a corporate buy out, specifically because of this type of activity.

Dreamers will be dreamers.

The ongoing uptake in open core, shows where it goes.

The question here is what motivates individual developers to write big projects and then release them as open source. I think vague dreams of million-dollar deals are part of this for a lot of people. As the developer community becomes more aware of what a grind open source maintainership is, people are already less interested in taking on that responsibility. If we also prevent big money buyouts from happening, I wonder what's left to motivate a future developer to create the next redis.
Redis was created for the same reason most of us create open source tools: to scratch an itch, to solve a problem (or improve a solution).

I find it hard to believe many if any would see "create an open source tool" as a method to become a millionaire.

Free software existed long before mass investment by VCs. The business arguments for open source existed long before the low-interest-rate period.

We are probably not going to see mass investment by VCs in free software for awhile (perhaps never, but that is pretty strong), but developers will keep scratching our itch.

And maybe more and more developers and users will realise that AGPL/GPL/LGP are the only licenses which truly protect one’s software.

> maybe more and more developers and users will realise that AGPL/GPL/LGP are the only licenses which truly protect one’s software.

I don't think this is a fair assessment of the cause of the issue with redis, or hashicorp, or elasticsearch etc;

This wasn't some nefarious third party taking all the community good will and contributions and creating a private fork to kill the original projects.

If you don't want some corporate asshole to turn your open source project into a get rich quick scheme, don't give control of your project to that asshole.

We basically need to see the big users of these projects hiring staff to contribute to the fork and destroying the original project for that to work well i think. We need to invalidate the business model of "buy opensource project, be a giant asshole" by causing billions of losses t( vcs and proving there is no mote like there can be buying closed source before thia bs goes away.
We need to normalize the idea that if a company uses something open source they automatically get someone to contribute to the project. That couple be hiring people in house to maintain it, it could be paying a consultant, it could be donating to a charity that maintains it. Probably some other way as well. However if you are a company getting value from open source you really need to put some money into keeping it maintained.

The above applies to private people as well. You use how many different pieces of software, what are you doing to ensure they stay maintained. (if you are like most nothing...)

I think it comes down to is the project there to make money or not. If it's mainly for money then it would never start out open source (ie AWS) but if it's a solution to a problem that can be improved via collaboration then it'll be Open Source (ie OpenStack). This hasn't really changed over the years.

What we are seeing here, as others have pointed out, is that companies are buying Open Source solutions and then close sourcing them because they view it as a money maker which in the end leads to forks.

> companies are buying Open Source solutions

so the original owner of said OSS being sold is making money by selling it to this company (who might be told, or is sold the idea that said OSS could be monetized).

This is no different to a startup making their own acquisition the end goal.

I doubt that. What has been proven clearly in the industry is that FOSS works excellently as a way for businesses to collaborate on common infrastructure. Linux is by far the biggest success in this area, but there are also things like Kubernetes, clang, Python and others.

What does not work, not long term, is trying to build a business around selling a FOSS solution - RedHat is probably the only notable exception here. But having multiple companies invest in a common tool that they all use as part of their infrastructure has worked wonders.

Linux - IBM, Intel, et al

Kubernetes - Gooogle, Microsoft, Amazon,...

Python - Facebook, Google, Microsoft,...

clang - Google, Apple, Intel, IBM,...

Yes, massive corporations who nevertheless don't want to take on the burden of developing a solution of this magnitude alone, or that want network effects so that their suppliers can't sell them bespoke solutions.
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)?

It sounds like a win-win to me.

> I'll just use the fork

For personal projects maybe yes, doesn't work for companies, they can't chase for thousand different forks of Redis and try to understand why feature isn't working properly on their version. Unless single fork emerges as a winner

Why would there be thousands of forks? We only need one good one.

I'm predicting such a fork backed by several core committers, and possible several cloud providers will emerge pretty quickly because they all need this to continue to exist as free and open source. AWS is not going to pay Redis a cent. Nor is Azure. Or Google. Or people commercializing open stack. All of those offer Redis support currently. Lots of their users use it.

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 don't like it either but I can see it working.

The reason this inevitably faceplants is lack of access to real user feedback.

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.

Do those users actually exist, thought?

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.

MariaDB had a chance but most have moved back to MySQL after the fork moved further away
What are you talking about? At some megacorp I work at, we had a similar situation where some other braindead product changed its license. Even since, there's, on average, 30% engineering position, maintaining the old deprecated version before the license change.

When it comes to large corps, the prices paid for these products is already so large, because of the scale, that it often times makes more sense to employ your own, instead. These kind of decisions are taken all too often. We'll spend a good few sprints exploring possibilities/mapping differences/POCing to more accurately estimate all these findings and their ROI before deciding. This can also include tough migrations. At a previous megacorp; ELK did a nasty? Migrated to OpenSearch.

So, hard no on your take.

[flagged]
This is the issue: FOSS has largely become free labor for SaaS companies.
It is, however, also incredibly realistic.

People are not using open source for the hippie philosophy. They are using it because it is free (as in beer), but even more importantly: they are using it because non-free licenses are a terrible pain in the ass.

Legal aspects are a headache, and the amount of effort to get someone in your company to pay even a tiny amount for some library or service is a serious hurdle.

I would not be surprised if adopting a non-free library would take a typical company ~40 man hours of work. At current rates, that translates to quite an expensive license.

Just getting open source adopted in my company takes around 10 man hours, and that is for something like a compiler that is only for internal use. If we will ship/expose it to customers we do due dalliance that probably amounts to 40+ man-hours to verify we can accept the license terms for that use and that the project doesn't have some hidden license issue (someone copied in code with a different license, link to something with a different license...).

Getting close source is even more work though - now we need someone to negotiate license terms (that is make sure our proposed use is compatible with the license we buy). We also make sure there is no risk of using their code (what if the closed source binary library has some AGPL3 code in it). I'm not even sure how to go through that process.

That may be true, but a lot of the creators of open source do in fact do it for the "hippie philosophy." That disconnect will eventually kill it. Why work hard to just be free labor for SaaS companies and people who don't care about you?
The problem I’ve seen historically is when a company is founded around one project or ecosystem.

Someone like Microsoft or Google could take software like this, pay the original developer, and still see tons of ROI offering it as a canned cloud service. And to a certain degree they don’t care about the profitability of that 1 thing if it helps sell the rest of their system. Quite honestly, they won’t care about competition using it if it’s already common. People want X, they’re using it, you can offer it. You’re paying a handful of people for street cred, a guarantee it will continue to work well with your stuff, and input into direction.

Folks like RedisLabs, MongoDB, Hashicorp, etc. think they can do the same with a marketplace offering. But they’re reliant that the particular product is profitable on its own. They’re also reliant on the cloud customer being willing to establish another relationship with another vendor, even when they can automatically deploy and bill through their existing provider.

We’ve seen folks behind OSS projects hop from company to company over time and the project continues to thrive. I haven’t seen a company restrict a license and the project do so… at least that I can think of. I might be wrong.

Your use of "slaves" is a remarkably offensive way to describe volunteer software developers.
After reading about the situation that Lasse Collin was in with xz before their mental health problems were exploited by a likely state actor I'm 100% not fucking apologizing for using that word to describe how unpaid maintainers of critical open source software are being treated. It is more or less fucking appalling and if I have to use shocking language to get the point across I absolutely fucking will. And I'm tired as fuck of how we can't use any strong language to talk about situations that demand strong language because some theoretical person might take offense to it. This is fucking bullshit and needs to change, and we need fewer language gatekeeping assholes who aren't making anything better. So sick of this shit.
> Do you not see how incredibly entitled this is?

No. I think part of the value of Redis to date was exactly that it was BSD licensed. When I started using it, I showed many other developers what they could do with it, and those devs took Redis to work, and built products and some bought services/products from Redis. Without the open source product, Redis the company would likely not exist as it does today. Times change, and the right strategy for Redis the company probably looks a lot different than when they started it on the back of Antirez's still awesome software.

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.

[1] https://www.microsoft.com/en-us/research/blog/introducing-ga...

Looks neat, but probably only for internal MSFT usage.

For what it's worth... Microsoft was quoted in the Redis press release as a cloud provider that has partnered officially with Redis under this new licensing scheme.

What only for MSFT usage? It looks like it's MIT licensed and.. Written in C# which is very interesting.
There are many drop in replacements (we use keydb), but, depending on the features you use, there are a lot of api compatible (but sometimes lacking features) compatible drop ins. We migrated of a large redis cluster overnight; 0 software changes.
Beyond forks, at this point Redis is an API target that has been implemented by other databases (Dragonfly, Upstash, AWS ElastiCache Serverless).
Which is why I think Redis (the company) will change the protocol and it will end up fragmenting the community.
> 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.

Cynical take: Oracle didn’t need MySQL to be a profit center since it already offers a much more expensive alternative. They enjoyed good ROI by fragmenting the MySQL community, chilling usage and external development, and therefore slowing down the whole project.
MySQL is used as upsell, when it can't take the requirements any longer, there is Oracle RDMS over there with a nice upgrade deal discussed over lunch.
(comment deleted)
Interestingly, there is some nuance. One of the two licenses seems to be copyleft, but it's just not currently approved.

EDIT: Ironically, the SSPL seems to be more open than the copyleft counterpart (AGPL) - the difference is that it enforces releasing the whole service source. Any discussion assuming that the new dual licensing model is hurting the users' freed is actually unfounded.

---

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.

> but it's just not currently approved:

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.

Right, thanks for the correction. For reference, the v2 withdrawal thread is here: http://lists.opensource.org/pipermail/license-review_lists.o....

With the current expectations, no license will solve the problem of making software open and prevent companies from "stealing" it. The "stealing" point is not necessarily my opinion; just pointing that there's always noise about it.

Both were noped by lawyers pretty quickly (who actually know their stuff and how licences work, rather than random engineers), so I'm not sure what you are trying to suggest...
> (who actually know their stuff and how licences work, rather than random engineers)

The whole licensing diatribe is more ideological than concrete, so it's actually about "random" engineers more than lawyers.

> so I'm not sure what you are trying to suggest...

First, that most, if not all, of the criticism of dual licensing, in particular WRT the Redis case, is unfounded/uninformed. The SSPL is liberal when it comes to "engineering" freedoms (fork/distribute); the restriction is a business one (SSPL is very close to AGPL).

Second, most importantly, with the advent of cloud engineering, as of now, there's no licensing that makes everybody happy. And this implies that there will be plenty of complaints no matter what (just look at the dual licensing threads):

- if a company adopts standard FOSS licenses, there will be complaints about cloud companies leeching off open source projects

- if a company adopts non-standard but still liberal licenses (e.g. SSPL), there will be complaints about companies betraying the FOSS principles

Is this going the way of elastic and aimed at service providers like AWS using it without paying for it?