> As noted by Matt Asay, who formerly ran open source strategy and marketing at AWS, most developers are "largely immune to Redis' license change."
This is intended by the SSPL; there's no fiasco. The vast majority of the users don't need to do anything, and if they change [to any upcoming fork], it's for ideological, not licensing (concrete), reasons.
> But it feels like there had to be another way this could have worked out.
No, there isn't. FOSS licenses makes devs complain because "cloud companies appropriate open source products"; SSPL license (or similar) makes devs complain because it's not FOSS (even if it doesn't affect them).
> No, there isn't. FOSS licenses makes devs complain because "cloud companies are vultures"; SSPL license (or similar) makes devs complain because it's not FOSS (even if it doesn't affect them).
Somehow this discussion never mentions AGPL, which is widely considered FOSS, and yet companies seem to hate it?
Companies (and their lawyers) hate it because the AGPL (and also the GPL and LGPL) contain a lot of fluffy wording which can be interpreted in a lot of ways.
In contrast take for example the CDDL. It just says: This particular source file is CDDL licensed. If you modify and create a "result" (binary) from it which you distribute you have to share it if someone asks for it.
In contrast licenses like the LGPL for example talk about having to supply the means to rebuild it and such. What that means exactly and where it begins and ends? That's for a judge to decide.
The discussion needs to be split in two: the why of AGPL/SSPL, and the hate against them (and from who).
Re:why - SSPL is intended to be an improvement of AGPL, because according to some, it's possible by a cloud provider to work it around.
Re:hate by big companies - Google has an explicit policy, which says:
The license places restrictions on software used over a network which are extremely difficult for Google to comply with. Using AGPL software requires that anything it links to must also be licensed under the AGPL. Even if you think you aren’t linking to anything important, it still presents a huge risk to Google because of how integrated much of our code is. The risks heavily outweigh the benefits.
I think that there's no way for a license to be formally exact on preventing cloud services to appropriate a code base. AGPL was an attempt (presumably failed), and SSPL failed for the exactness reason (which is the reason why it was rejected).
> No, there isn't. FOSS licenses makes devs complain because "cloud companies appropriate open source products"; SSPL license (or similar) makes devs complain because it's not FOSS (even if it doesn't affect them).
Yes, I do not see what is so bad about the SSPL. It does not affect anyone other than cloud companies. It is essentially like the GPL but stopping a workaround.
It does hinder competition and locks you in, doesn't it? Since you need a licence from the software owner to provide your own hosted solution, and they might give it to you at an huge price or not give it at all.
Say I had MongoDB hosted on some cloud provider before the change to SSPL. I can't keep getting support from the cloud provider for updates or at all, so I'd have to migrate to their MongoDB Atlas product or host it myself (which I wanted to avoid in the first place).
Then they could raise the price (almost) as much as they wanted, just slightly below the point where I'd consider migrating to another DBMS (engineering cost) or self-hosting (DBA cost), in any case affecting me.
Alternatively, had I chosen MySQL or Postgres, well established DBMS not built by startups with a single product that desperately need to make money, I could choose Azure, GCP, AWS or any other provider depending on my needs.
Not sure what percentage of the "vast majority of the users" it is but I will also make a similar assumption that it's large. They will use Redis through their cloud provider until the cloud provider provides a transparent upgrade path to a newer, shinier LF version that is protocol compatible, which they will do. Not for ideological reasons, or even concrete reasons, but just because their touch point is the cloud provider, not the mysterious company behind the actual code.
Probably we'll see Redis APM pretty soon to try to get back some revenue after people move on with their KV workloads in step with the cloud.
> This is intended by the SSPL; there's no fiasco. The vast majority of the users don't need to do anything, and if they change [to any upcoming fork], it's for ideological, not licensing (concrete), reasons.
If you are like me and prefer your libraries to come from a distro (reason: cf xz-utils), then there is a very concrete reason. They won't be in most major distro's, because the distros don't consider the SSPL free.
> The vast majority of the users don't need to do anything, and if they change [to any upcoming fork], it's for ideological, not licensing (concrete), reasons.
This is simply not true. Most normal users are not directly affected but this change, but if they previously used AWS to host Redis, they would now be affected. A big point of open source is that you can find competing hosts to give you the best service, but Redis would want it so that only they are allowed to sell hosting service meaning that you don't have competition. This directly affects users.
Also, it's important to note that Matt Asay works for MongoDB. His paycheck comes from a similar business model as Redis.
---
I think a lot of people are missing the issue here. Let me summarize my own take on this:
1. Redis is no longer open source under any reasonable definition (note that SSPL has very important distinctions from AGPL. They are not the same). And yet companies like Redis/MongoDB/ElasticSearch keeps trying to say they are "open source" and try to change the meaning of the term. It's virtue signaling without adopting the virtue. Lots of beloved companies are proprietary. They should just come out and say they are proprietary and be done with it.
2. Redis performed a rug pull. They previously released they source under BSD which is what attracted users and contributors, then once it became popular they changed the license (which they can legally do because they forced contributors to sign CLAs). Would contributors like Madelyn Olson (who works for Amazon) contributed to Reddis on her free time if it was under SSPL right off the bat? I highly doubt it. Redis knew that as a newcomer they had to parrot "we love open source" but once popular enough they can now force people to put up because of inertia.
I think it's fine to be proprietary, but I would trust a company much more if they don't try to change it midway through, or keep saying BS like how they still embrace open source (which is intellectually dishonest).
Pretty much. I think it's the whole virtue signaling and intellectual hand wavy dishonesty that really bugs me about these companies. They want to have the cake and eat it too.
Do companies like Apple say macOS is open source (I mean the entire OS, not just Darwin)? No. Some people are fine with it because we know this.
It must be hard to see another company make profits from a product you have the IP of. However, availability of Redis in major cloud providers is also a reason for Redis' success.
And is it really a good idea to put your entire business strategy relying on hosting an OSS solution, when container technologies are more relevant than ever, and when you have major players who can leverage economies of scale against you?
Hosting is a DevOps service, not a Software service. It's appealing because of the SaaS economies, but I think OSS companies should try to be a bit more innovative if they want to monetise open source solutions and their assets...
Didn’t Redis Labs do the exact same thing? They took redis which was free and made it commercial?
And now they complain about AWS? Fwiw - I think an earlier post had pointed out that from the commit history AWS had been contributing significant code back to the open source.
Regardless of legalities the model does seem quite unfair.
Small players do the legwork and big tech makes the profit. That doesn’t feel intuitively fair even if technically allowed and in line with the spirit of open licenses
As an end-user I am not more inclined to support the profiteering of a small VC-backed company than an evil megacorporation - at least when the latter does well, I can see some upside in my pension fund.
The Linux Foundation is a 501(c)(6) non-profit trade organization. As such it's normal to look like an industry body of large Linux (and related software) using companies - and in the current tech ecosystem, those are predominantly cloud companies.
Yeah, but saying "The Linux Foundation is behind the fork" gives (to the casual reader like me) some Linus-related legitimacy.
They should have said "The Cloud Industries Pet Trade Org created a new fork so they don't have to pay nominal (to them) sums to support the software."
I think realistically that's what's playing out here.. it's just a matter of time before the OSI approves an SSPL-like variant that brings copy left into the cloud era
Has the opportunity for harmony between open source infrastructure and commercial cloud passed? the infrastructure for most software engineering projects already exists.
could some kind of antitrust lawsuit force clouds to contribute a fair share?
Not affiliated (not my first comment about this) but we are using KVRocks[1] for now at work, which is based on RocksDB by Meta and it works nicely. Developers are nice and reactive and the Redis commands support is large.
We picked this project because of our RAM usage that was exploding with Redis.
The only downside for us right now is the Kubernetes support. There is an operator and a controller being made but no Helm Chart yet to deploy Kvrocks with master and replicas easily. That will be awesome.
Readit News
> As noted by Matt Asay, who formerly ran open source strategy and marketing at AWS, most developers are "largely immune to Redis' license change."
This is intended by the SSPL; there's no fiasco. The vast majority of the users don't need to do anything, and if they change [to any upcoming fork], it's for ideological, not licensing (concrete), reasons.
> But it feels like there had to be another way this could have worked out.
No, there isn't. FOSS licenses makes devs complain because "cloud companies appropriate open source products"; SSPL license (or similar) makes devs complain because it's not FOSS (even if it doesn't affect them).
Somehow this discussion never mentions AGPL, which is widely considered FOSS, and yet companies seem to hate it?
In contrast take for example the CDDL. It just says: This particular source file is CDDL licensed. If you modify and create a "result" (binary) from it which you distribute you have to share it if someone asks for it.
In contrast licenses like the LGPL for example talk about having to supply the means to rebuild it and such. What that means exactly and where it begins and ends? That's for a judge to decide.
Re:why - SSPL is intended to be an improvement of AGPL, because according to some, it's possible by a cloud provider to work it around.
Re:hate by big companies - Google has an explicit policy, which says:
I think that there's no way for a license to be formally exact on preventing cloud services to appropriate a code base. AGPL was an attempt (presumably failed), and SSPL failed for the exactness reason (which is the reason why it was rejected).https://opensource.google/documentation/reference/using/agpl...
Yes, I do not see what is so bad about the SSPL. It does not affect anyone other than cloud companies. It is essentially like the GPL but stopping a workaround.
Say I had MongoDB hosted on some cloud provider before the change to SSPL. I can't keep getting support from the cloud provider for updates or at all, so I'd have to migrate to their MongoDB Atlas product or host it myself (which I wanted to avoid in the first place).
Then they could raise the price (almost) as much as they wanted, just slightly below the point where I'd consider migrating to another DBMS (engineering cost) or self-hosting (DBA cost), in any case affecting me.
Alternatively, had I chosen MySQL or Postgres, well established DBMS not built by startups with a single product that desperately need to make money, I could choose Azure, GCP, AWS or any other provider depending on my needs.
Probably we'll see Redis APM pretty soon to try to get back some revenue after people move on with their KV workloads in step with the cloud.
If you are like me and prefer your libraries to come from a distro (reason: cf xz-utils), then there is a very concrete reason. They won't be in most major distro's, because the distros don't consider the SSPL free.
This is simply not true. Most normal users are not directly affected but this change, but if they previously used AWS to host Redis, they would now be affected. A big point of open source is that you can find competing hosts to give you the best service, but Redis would want it so that only they are allowed to sell hosting service meaning that you don't have competition. This directly affects users.
Also, it's important to note that Matt Asay works for MongoDB. His paycheck comes from a similar business model as Redis.
---
I think a lot of people are missing the issue here. Let me summarize my own take on this:
1. Redis is no longer open source under any reasonable definition (note that SSPL has very important distinctions from AGPL. They are not the same). And yet companies like Redis/MongoDB/ElasticSearch keeps trying to say they are "open source" and try to change the meaning of the term. It's virtue signaling without adopting the virtue. Lots of beloved companies are proprietary. They should just come out and say they are proprietary and be done with it.
2. Redis performed a rug pull. They previously released they source under BSD which is what attracted users and contributors, then once it became popular they changed the license (which they can legally do because they forced contributors to sign CLAs). Would contributors like Madelyn Olson (who works for Amazon) contributed to Reddis on her free time if it was under SSPL right off the bat? I highly doubt it. Redis knew that as a newcomer they had to parrot "we love open source" but once popular enough they can now force people to put up because of inertia.
I think it's fine to be proprietary, but I would trust a company much more if they don't try to change it midway through, or keep saying BS like how they still embrace open source (which is intellectually dishonest).
If this were a divorce, Redis would be paying alimony.
Actually, Later We'll Adjust Your Service
Do companies like Apple say macOS is open source (I mean the entire OS, not just Darwin)? No. Some people are fine with it because we know this.
And is it really a good idea to put your entire business strategy relying on hosting an OSS solution, when container technologies are more relevant than ever, and when you have major players who can leverage economies of scale against you?
Hosting is a DevOps service, not a Software service. It's appealing because of the SaaS economies, but I think OSS companies should try to be a bit more innovative if they want to monetise open source solutions and their assets...
And now they complain about AWS? Fwiw - I think an earlier post had pointed out that from the commit history AWS had been contributing significant code back to the open source.
Small players do the legwork and big tech makes the profit. That doesn’t feel intuitively fair even if technically allowed and in line with the spirit of open licenses
They should have said "The Cloud Industries Pet Trade Org created a new fork so they don't have to pay nominal (to them) sums to support the software."
[1] https://opensource.org/sponsors
> But it feels like there had to be another way this could have worked out.
Serious question: Did Redis try to have it another way, before changing their license to SSPL?
We need an MIT, but with a “you can’t serve this tool over a network in exchange for money” (not a lawyer, obviously) kind of clause.
could some kind of antitrust lawsuit force clouds to contribute a fair share?
We picked this project because of our RAM usage that was exploding with Redis.
The only downside for us right now is the Kubernetes support. There is an operator and a controller being made but no Helm Chart yet to deploy Kvrocks with master and replicas easily. That will be awesome.
[1]: https://github.com/apache/kvrocks