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

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.




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

Search: