Hacker News Reader

Comment by RobotToaster | Hacker News Reader

The problem is the entire stack has to be released under the SSPL.

Which means if you want to offer it as a service, you can't use it on GNU/linux, since you don't have permission to release it under the SSPL.

edited to add: this could easily be remedied by simply requiring the entire stack to be published under either the SSPL or an OSI/FSF approved license. Such a license (somewhat ironically) probably wouldn't be approved by the OSI/FSF, but it would solve the main issue with it. Although I also suspect the people using the SSPL consider this a "feature not a bug" of their psuedo-open-source licence.

View on HN

How can it be used at all under SSPL then? There are no operating systems on which Redis runs that uses that license.

You only need to do that if you operate it as a service that you sell or give away to others (rather than just running your own internal redis instance)

So yes, this basically prohibits anyone but redis from operating it as a service, unless you write your own operating system for it to run on. (Although presumably they will sell you licences or similar to operate it as a service)

That's why it's dual licensed.

That's essentially why people think its not-free. In essence, it pretends to give you the right to do something, but puts impossible to meet requirements so that in pracitise you cannot do the thing.

In essence, the license says you cannot use it as SASS software, but they didn't want to outright say that, so they did this instead.

That's the point! It's impossible to comply with it. If it were an open source license, it'd require every component to be released under an open source license.

I don't believe that was the intent. If you look at the text it's more focused on the unique software that goes into delivering the service itself ... but since the goal of the SSPL was in many ways to reduce ambiguity compared to the AGPL, I think this perspective should be reflected upon and perhaps incorporated into a future version of the SSPL.

Let's say you deploy a work queue service backed by Redis, with authz/n delegated to Azure AD. You would require a commercial license since you can't publish Azure AD?

A work queue service is not a public Redis service so you have total freedom to do whatever you want in this case

What if Redis Inc think it is and sue you?

They'd be destroying their community

Taking an established open-source project with a healthy ecosystem and community and making it proprietary overnight is already destroying their community.

How is it proprietary? It's using the SSPL which offers copyleft user freedoms

You can split software licenses roughly into two, open-source and proprietary. Since SSPL is not open-source, it's considered proprietary.

What do you consider the AGPL and other copy left licenses? Even the OSI director acknowledges this one needs another look in the fulness of time here

I consider AGPL open-source. Same with other open-source copy-left licenses like GPL or LGPL.

Isn't SSPL compatible with the GPL? If so you could "just" republish your stack under the new license. Not sure how feasible this strategy is in practice, as any company's stack is vast and no one wants to enumerate it all...

> Isn't SSPL compatible with the GPL?

Not sure how that could be the case. SSPL places additional restrictions on the usage of the software, so you cannot relicense GPL code as SSPL.

Reply on news.ycombinator.com