Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Can someone please explain why this is bad to me or my company, who don't offer a paid, hosted Redis installation? As far as I can see, this license means that Redis the company gets some exclusivity on who can run a hosted version of their product, and everybody else gets it for gratis, with source we can change libre.


It’s not “open source” now.

Your view on its impact is orthogonal to this reality. People’s view on this reality is orthogonal to its impact

Personally, I’ve grown tired of this debate. Redis is clearly commercial software. None of my “freedoms” rely on redis, the way they might on more core or primitive softwares like Linux, Bash, or a browser. The real (but non-exclusive) value of the invention lies in commercial applications. I’ll bring out my “it’s not OSS” pitchfork when VI or eMacs changes their licenses. I care deeply about open source software, but not all source code matters.

Contributing is a thankless task that benefits people’s profit driven interests. It’s understandable that contributors would like to try for some of that profit, and this doesn’t seem to be too aggressive either. Yea, the relationship changed, because they were “giving it away” prior. But so what, life is full of changes. There is only a handful of organizations this will impact and they’re all rich corporations that don’t need my pity. The project is mature, so most remaining work is likely feature adds required by mega-scale and niche commercial uses cases, that’s just not work people usually do for fun.

Pardon my aggression - it’s rhetorical- but redis doesn’t need to exist in this world. It certainly doesn’t need anyone’s emotions.


> There is only a handful of organizations this will impact and they’re all rich corporations that don’t need my pity. The project is mature, so most remaining work is likely feature adds required by mega-scale and niche commercial uses cases, that’s just not work people usually do for fun.

There is still a long tail on this. For example, wikipedia offers a cloud like platform thar people who contribute to wikipedia can sign up for free to, get some web space where they can make small unofficial tools, provided that the tool is somehow related to wikipedia. This includes redis hosting among other things (https://wikitech.wikimedia.org/wiki/Help:Toolforge/Redis_for... ). The license change would probably effect that use case ( the RSAL would prohibit that. The situation with the SSPL is less clear (IANAL))


Well, if you've grown tired of this debate, maybe I shouldn't reply, but maybe someone else wants to have it: Sure, it's not OSI-OSS, but what does that mean for the world, in practical terms?

OSI-defined OSS means "comes with no restrictions, except maybe redistribution", whereas this license adds another restriction (you can't run the software as a service without offering the source, as I understand it). How does this restriction affect us?

It surely can't be that OSS as defined by the OSI is the only good thing, and anything else is horrible, it has to be a continuum. Why is this license so bad, when it only affects AWS? How are my liberties being restricted?

It doesn't really answer anything to say "it's not open source", because that just implies that we already agree on why that's bad.


There is larger community impact of not being FOSS. Most immediate, distros will not package it anymore. Overall you will not be able to include Redis in FOSS projects in the same way anymore. In longer term this means that Redis will not enjoy similar integration with other projects; FOSS projects tend to prefer using/depending/integrating other FOSS projects, so Redis becoming non-FOSS means that it loses that preferred status. And so on.


That may end up being a net win for all involved: distribution users will get an up to date package direct from the source instead of a 5 year old version (or whatever) patched to hell, and the project will stop getting reports about versions modified by packagers.


Sure, it's not OSI-OSS, but what does that mean for the world, in practical terms?

One practical consequence: Linux distributions will drop the new Redis, and ship its OSS fork or an alternative protocol-compatible cache. Or perhaps continue with the pre-license-change version for a while, which is a kind of fork. What was the relatively simple "apt install redis" will now be "apt install freeredis" or "apt install awesome-cache" or "apt install redis73". So you will have churn.

I don't have an idea how many installations are via the official docker image; they won't change, but even there now you have a legal risk, however tiny: will Redis Inc. come after us for our usage? Legal departments are allergic to risk: witness their aversion to GPL variants, especially GPLv3 and AGPL. So perhaps there will be pressure to avoid Redis, again causing churn.


The restriction isn't that "you can't run the software as a service without offering the source." You're thinking of the AGPL, which is recognized as an open source license by the OSI. Redis's license has changed to the SSPL, which requires anyone who runs Redis as a service to release the source code to "all programs that you use to make the Program or modified version available as a service" under the SSPL. This makes it effectively impossible for a cloud provider to actually try to comply with the license, as it would require a massive engineering effort to write a new operating system, new device drivers, new programming language implementations, new web stack, etc all licensed under the SSPL.


Well I always welcome a healthy discussion so feel free to answer. I’ve really just grown tired of seeing outrage that software which was previously “OS as defined by the famous organizations” changes to protect their commercial interests.

Like you said, there’s a continuum, and I really don’t think that “you can’t sell this as a service” is a huge restriction on freedom. Especially when I can still use the software (even commercially) if I host it myself. Many of these services (Redis, Elastic Search, Mongo, etc) wouldn’t really exist without commercial use cases, and I really care more about protecting individuals freedoms and the use case of a human using a machine in their own hands for their own use. The extent of my interest in OSS being good/bad (if you can make that claim at all) is in the impact to individuals at home.

Also, the server side license just feels like the modern viral license we should have. GPL ensures all code running together is forced open, and AGPL ensures clients are open, and this ensures that the server is open. Seems good to me the same way GPL or AGPL are good.

I view it like government regulation. Bureaucracy is waste and I’m all for enriching society and creating new jobs and products with better commerce… but environmental protections and safety protections help society. If your business can’t exist without endangering someone, I won’t miss it. If your business exists solely to resell free software (explicitly designed for commercial use) that someone else made, and they don’t want to give it to you for free anymore, I won’t care it if you need to change up your business.


I think the disconnect here is that people think "it's either SSPL or GPL, and I want the GPL", when in reality it's probably "it's either SSPL or no more development", in which case I'd prefer the SSPL.

If I don't mind antirez not working on Redis any more, I can always fork it and do my own development.


That Redis cannot be included in many Linux distributions anymore. Is that enough of a practical impact?


Its no longer open source, if being open source isn't one of your requirements then it probably doesn't directly effect you.

It might indirectly effect you as some free labour from the open source community might dry up. E.g. your linux distro might no longer package it and you might have to rely on packages maintained by redis which might not be as well integrated into your distro (although lots of users probably don't care about that)


> E.g. your linux distro might no longer package it and you might have to rely on packages maintained by redis which might not be as well integrated into your distro (although lots of users probably don't care about that)

This might be me living in a bubble, but OS packages for this kind of server software really feel like a relic the past.

Containers have been around for a decade and we now have tools like podman that run without privileges or daemons. I run my freakin' Raspberry Pi 4GB as a pure container host, just because it makes the system cleaner and more reliable at almost no cost.

Now I'm sure some people still want to `apt install redis`, for example to squeeze every last ounce of performance out of hardware, and more power to them if that's what gives them the best results.

But Debian maintainers have to do a lot of dull, unfun work to update, test, and bugfix native packages for Redis and Mongo and RabbitMQ and... is that really a good use of their precious, unpaid time? To make the UX and performance only slightly better than 'podman run redis'?


"open source" has always been a marketing term. It doesn't mean anything because it's never meant anything.

The GNU people fought the good fight on free/libre software, but they lost because companies are greedy and devs are lazy at their day jobs.


The people who coined the term (OSI) gave a definition when they coined the term. That definition is almost universally accepted in the software world. Redis no longer meets that definition.

Just because something is a marketing term doesn't mean its meaningless. You can't sell non free range eggs as "free range" simply because its a marketing term. Etc


The term “free range” is almost meaningless when buying eggs - even the opening paragraph of Wikipedia explains this:

“Free-range eggs are eggs produced from birds that may be permitted outdoors. The term "free-range" may be used differently depending on the country and the relevant laws, and is not regulated in many areas.”

Bad choice of example!


It is far from a marketing term : opensources products can be used without talking to legal departements.

For big compagnies, this a game-changer because you can spare yourself months of "work".


AGPL is an “open source” license per OSI - I assure you if you use code licensed under it at many big companies, you might avoid a meeting with legal but will instead get one with HR…


> opensources products can be used without talking to legal departements.

Pretty much every company I've worked at has wanted legal signoff for use of any open source project. Granted, compliance with that directive was often spotty. But some did have a tool to scan our repositories for dependencies, and flag things that had licenses not on an approved list (which, no, was not the entirety of OSI-approved licenses).


> For big compagnies, this a game-changer because you can spare yourself months of "work".

I believe I already stipulated that companies are greedy and devs are lazy. I hope you don't consider your comment a counterargument.


It opens you up to a larger litigation surface. Previously, you didn’t risk having to explain to a court that you’re really not offering Redis as a service even though your service is using Redis.

Copyleft licenses are limited to the software itself, but SSPL expands this to ”including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software”. If there’s even the tiniest risk of having to comply with that, I’d stay clear of anything SSPL licensed.


That makes sense, thank you.




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

Search: