Hacker News Reader

Comment by BeefySwain | Hacker News Reader

All the conversations about SSPL seem to go the same way:

- Someone complains about the extra restrictions imposed on AWS (lets be real, it's basically just about AWS)

- People point out that SSPL is basically AGPL+, and that for the vast vast majority of people it doesn't make any difference

- People counter that the SSPL is written ambiguously/untested in court, and so while it might seem like it's AGPL+ and doesn't matter for most users, you can't rely on that

- People complain about rug pulling (valid, IMO)

My question is this: Can there be a AGPL+ that is OSI approved? Could there be a "AAGPL" that GNU releases that covers this (very common, and IMO valid) "need" for open source companies to not be cannibalized by cloud providers?

Is this conceptually unacceptable, or is it just that the SSPL is poorly executed?

View on HN

> Is this conceptually unacceptable, or is it just that the SSPL is poorly executed?

In my opinion it's the latter. There's a minor change you could make to the SSPL that would take it from "practically impossible to comply with" to something that just about anyone building a service with FOSS dependencies could comply with: https://www.terracrypt.net/posts/the-sspl-is-not-a-reasonabl...

Essentially, add EUPL-like license compatibility clauses for dependencies to the SSPL.

I'm not saying this is exactly what we should do to accomplish that goal, but I think it's worth considering, and probably has a reasonable shot at being considered a free software license.

Problem comes down to, what is cloud provider?

My company has a piece of software we will sell you that requires Redis/PostGres. For fee, we also offer hosting of said software. Are we now a service provider? Our software does come with ability to manipulate the data in Redis so do we have open source our entire code base? Would we get stuck in lawyer battle royale?

We have resellers coming on board so interface is being built that lets them deploy our software for their customers so Redis will be deployed by us and given to reseller? Are we cloud provider then?

Now, I think reality is Redis wouldn't see as cloud provider because we don't go "Here is Redis, do whatever you want." Lawyers however get paid to think of worst thing that could happen and our lawyers said "Eh...... I'd hate to have these terms hanging over your head."

That's why alot of people recoil at SSPL.

Luckily, Valkey is drop-in replacement for us, testing is almost completed and likely we will switch when paperwork is all completed.

I agree with your analysis and I sympathize with Redis in some way.

It seems to me that it's painfully obvious what a cloud provider is, but that everyone is afraid of what a lawyer could convince a judge in the Eastern District of Texas to think a cloud provider is.

The technical definition should be something akin to offering raw R/W connectivity to redis databases for arbitrary purposes.

Offering a redis-backed SaaS should not be covered.

Tbh it seems far past time for the OSI to come out with a blessed license with well defined terminology so we can stop watching every large OS project invent their own way of combating AWS/etc

Why would the Open Source Initiative bless a non-open source license?

They already have AGPL, these are just a slight step further.

actually the sspl can’t be a fork of the agpl. Because osi and thus the agpl do not discriminate users and this includes cloud providers. A license like the sspl discriminates a certain user base.

> not be cannibalized by cloud providers

That would be discrimination against certain groups/persons, so not acceptable under the OSD.

https://opensource.org/osd

People keep talking about how the licence change was to prevent the likes of AWS from "taking and giving nothing back"... and completely ignore that AWS was paying an engineer to contribute to Redis in a significant way.

Reply on news.ycombinator.com