> 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.
> 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.
That... makes sense? Otherwise you could release your Free Software and at the same time create a proprietary compiler that cannot be reverse engineered because it would break your IP, but hey, you can license it at a nice recurring fee and you are still producing Free Software!
You're assuming malice, when really it's just impractical in most cases that object to this wording. What if my software build includes a Windows client, which needs some DLL from an install of Visual Studio?
The licence wording as I understand it doesn't differentiate well enough between "large cloud company trying to use my work" and "everyone else".
We can ask "what if" forever. I've never seen an example, you've never seen an example: yeah, it's good to be prepared, but what if we're painting ourselves into corners over things that'll never occur?
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).
I think there is a fundamental "proxy problem" with AGPL-like licenses.
If I put a transparent proxy in front of the service and let users connect to that am I exposing it to them? Almost certainly yes.
What about a proxy that provides a HTTP API for the database and then translates it to the native protocol? Probably also considered exposing.
If I put stock data into the database and put up a website that displays a stock ticker am I exposing the database to them? Very likely not?
But what if the user can also write stock values? What if they can sum the values of various stocks.
Basically there is no clear line where you stop exposing the database to the user and you stop needing to provide the source of whatever intermediate services you are using. So lawyers will recommend erring on the side of caution and just not touching it.
It is a risk if you operate in a way that breaches copyright.
> It's a hugely risky license that can, in some cases, endanger entire companies.
it can no more endanger a company than any other breach of copyright.
It is exactly the same as distributing software using GPL library. Google are fine with GPL because it is not a problem for their particulalr business mode.
> 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.
Yes, it hinders competition for cloud hosting in certain ways.
Someone could set up a separate hosting service for it as long as they made their supporting code FOSS too.
It also lets you self host, including on a cloud platform.
The rules for hosting SSPL software, are not very different from those for distributing GPL software. It certainly seems to be in the same spirit as someone offering software under GPL with a proprietary alternative.
What I do think is unfair is when there is an element of bait and switch.
> Alternatively, had I chosen MySQL or Postgres, well established DBMS not built by startups with a single product
> Someone could set up a separate hosting service for it as long as they made their supporting code FOSS too.
Isn't this more-or-less what the AGPL does? Allow hosting for others, but sharing the server-side code. I get that big providers aren't happy by this for multiple reasons, though
> The rules for hosting SSPL software, are not very different from those for distributing GPL software
They are in the way that they forbid you from competing with them. For a GPL program, I could build my own redistribution (see Linux distros consisting on packaging and distributing software made by others)
> That was how MySQL started, IIRC?
Actually, it seems so, but they used the GPL instead of BSD, and based their business on support and dual-licencing, and was later on bought by Sun/Oracle, being just one of their products and not their only product, like Redis or MongoDB.
> What I do think is unfair is when there is an element of bait and switch.
What's the bait? The expectation to get free development and support forever? The pre-switch Redis code is still BSD licensed, that can't be changed.
Additionally, using SSPL licensed code doesn't concretely change anything for essentially any end user/developer besides BigCos - which are free to use and hack Redis at will as before. As a matter of fact, almost all those who complained about the license change on HN, are actually not affected.
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).
> 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).