Hacker News new | past | comments | ask | show | jobs | submit login
Redis' license change and forking are a mess that everybody can feel bad about (arstechnica.com)
70 points by pjmlp 20 days ago | hide | past | favorite | 70 comments



From the article

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


This argument cannot be made in favor of the SSPL, considering the SSPL is literally the AGPL (like, verbatim) with extra terms.


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


In that particular case, simply distribute the DLL with the source code. Microsoft lets you: they even have "redistributable" in the name!


You're arguing the example, not the concept What if it depends on something that's not created to be redistributable?


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?


Hah well, that's true. But there may be tougher cases than the one I came up with.


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's no mystery why companies hate AGPL. It's a hugely risky license that can, in some cases, endanger entire companies.

https://opensource.google/documentation/reference/using/agpl...


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.


Then Buy A License.

Most code today with AGPL is dual-licensed.


> 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

That was how MySQL started, IIRC?


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


People don’t complain about the license or cloud companies, they complain about losing control and features they’ve grown accustomed to.

If this were a divorce, Redis would be paying alimony.



ALWAYS:

Actually, Later We'll Adjust Your Service


The relicense doesn't bother me. That straight up lie, though.


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.


What benefits your pension fund isnt a particularly good measure of fairness either ;)


The Linux Foundation looks like an industry body for cloud companies at this point. Has it always been like this?


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.


There is also android/AOSP which is big, comparatively and runs on linux


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


The OSI is the same way [1] and they are the ones pushing for business friendly non-copyleft licenses.

[1] https://opensource.org/sponsors


I assume in the early days it was backed by IBM more so than the hyperscalers no?


They even host non Linux related stuff nowadays, like Zephyr.


Probably, if you follow the money.


The author ends with

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


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


Yeah.

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.


Isn't that covered by AGPL/SSPL? I mean, they do allow you to serve the tool over a network in exchange for money, if you provide all your source code modifications (and possibly more under SSPL).


Not sure about SSPL, but AGPL is a much more complex licensing that also places static linking restrictions.

The complexity and ambiguity of pretty much all GPL licenses gives legal teams pause.


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.

[1]: https://github.com/apache/kvrocks


It is strange that cloud providers don't give back to open source. Even 1% of revenues would likely adequately fund teams. However, the aren't the only ones that are being "greedy". Eventually, someone will try to become a billionaire from a popular project (either the original creator or someone else). Capturing a fraction of revenue isn't enough for these folks.

I feel that a new license model is needed to incentivize better behaviors on all sides.


I don't think it's strange to be honest. Like, if you make your code available under a permissive license like BSD, it's… permissive. Companies don't have a moral or ethical or legal obligation to contribute back. AWS saw an available software, and did what they do and packaged it up and offered a service. Does it suck for Redis? Sure. But they shouldn't have used BSD license to begin with. There's a reason why FSF spent so much time focusing on their license (not that I'm saying everyone should be using copyleft license).

A charitable interpretation is that Redis was being naive. A more realistic interpretation is that Redis knew a proprietary license would not have allowed it to be widely adopted, and that only a standard permissive license would have allowed it to be adopted, and now that it's popular they can force a change due to inertia on developers' side.

I just think something like Redis has no place being open source. And we should just be honest about it instead of beating around the bush. This whole "we will spend our R&D making a free software and make money on hosting" never had any legs because the obvious conclusion is someone can also make money on hosting your software without having put in the R&D work. If yet another new company comes to the market saying "we love open source" we should just be skeptical. The business model likely just doesn't make sense in the long run.


I have a model: https://gavinhoward.com/2023/12/is-source-available-really-t... .

Other people will have to decide whether it is a better model.


I'd consider moving to an OpenCache project. Made the move to OpenSearch.

There does seem to be more competition and alternatives in the cache space



Thanks for sharing, any idea who is behind it?

The idea I hope for is a single fork many work on rather than a bunch of forks with everyone trying to become the one



> The biggest thing was a fork of the Redis project, Valkey, that is backed by The Linux Foundation and, critically, also Amazon Web Services, Google Cloud, Oracle, Ericsson, and Snap Inc.



Have you looked at Microsoft’s Garnet?


Yup, 2 weeks ago, thanks for the reminder

https://news.ycombinator.com/item?id=39752504


Rowan sounds like a typical VC techbro that doesn't understand their product and costumers.

On the other hand, I understand they are pissed that AWS is making money from their work and they get nothing back.


>On the other hand, I understand they are pissed that AWS is making money from their work and they get nothing back.

Well, depending on how you look at things, it was never their work. Their business is and was exactly the same as AWS. However they paid money for the rights to the Redis name and copyright from the original developer after running their business for years in similar manner as AWS.

Of course they rebranded their company into Redis after acquiring the name.

Also it's not like AWS didn't contribute to Redis. I find it plausible that others might have contributed more to Redis than Redis themselves, if we exclude the contributions by the original developer when he was independent.

Correct me if I'm wrong, but as far as I know Redis (the company) focuses mainly on building custom stuff on top of Redis, instead of Redis itself.



Yes "What I don't understand is making the future of open source in the hands of what OSI says it's correct and wrong. Read the terms of the license, and understand if you are fine with them." Is well put


> On the other hand, I understand they are pissed that AWS is making money from their work and they get nothing back.

That's fundamentally the way the cookie crumbles, with opensource software. Some companies might be better making money from your code, or might be better at integrating it into a global solution. If you're afraid that might happen, then you shouldn't make your software opensource..

And anyway, didn't AWS contribute about 5% of the code?


The way I see it, if you create or contribute to an open source project, you need to leave your ego at the door and be ok with the world benefiting from it without giving you anything back. If they aren't ok with it, they shouldn't have made it open source in the first place.


In this case the creator left the company a year ago or so.


Time flies, it was actually 4 years ago: https://redis.com/blog/new-governance-for-redis/


It's not a mess. Jeff Bezos can't make money on the back of other people's work, boo-hoo.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: