The race to replace Redis [LWN.net]

The race to replace Redis

Posted Apr 2, 2024 0:29 UTC (Tue) by NYKevin (subscriber, #129325)
In reply to: The race to replace Redis by immibis
Parent article: The race to replace Redis

The problem with the SSPL is that it refuses to draw a clear line and say "You must provide source for everything on this side of the line." How do you fix it? Where do you draw the line?

* At the process boundary (or thereabouts)? Then you've reinvented the AGPL.
* At the VM/container boundary? What if there is no VM/container? What if cloud company X responds by making their VM/container as small as possible and moves all of the supporting infrastructure to the other side of the boundary? What if they run two nested containers and put your code in the inner container?
* At the (physical) machine boundary? That's outrageously expansive and obviously impossible to comply with.

If you're going to claim that the SSPL is a fixable license, IMHO you should at least be prepared to explain where you would like them to draw the line. Because the line's the whole thing. Draw the line in a clear place, and then we can have a civilized conversation about whether the license makes sense. But as long as the line remains a blurry mess, it is impossible to have a serious discussion without one or possibly both sides resorting to the motte-and-bailey fallacy.[1]

Disclaimer: I currently work for Google, and previously worked on a GCP product that was NOT affected by the AGPL or any of its pretenders; opinions are my own as always.

[1]: https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy

to post comments

The race to replace Redis

Posted Apr 7, 2024 16:56 UTC (Sun) by immibis (subscriber, #105511) [Link] (3 responses)

This problem exists for all open-source licenses which impact derivative works.

The race to replace Redis

Posted Apr 12, 2024 8:15 UTC (Fri) by sammythesnake (guest, #17693) [Link] (2 responses)

This is decidedly not so. The term "Derivative Work" is a term of law with vast tomes of treaty, statue law, case law, convention, encyclopedia entries, text books and more clarifying exactly what it means.

Most of the world (181 out of 195 UN-recognised countries, according to Wikipedia) is in the Berne Convention which even provides a pretty substantial consistency between jurisdictions.

Anyone who is unclear what it covers could do worse than simply reading https://en.wikipedia.org/wiki/Derivative_work

The race to replace Redis

Posted Apr 12, 2024 11:25 UTC (Fri) by immibis (subscriber, #105511) [Link] (1 responses)

Where do you draw the line with AGPL?

* At the process boundary (or thereabouts)? Then you've reinvented the LGPL - What if cloud company X responds by making their process as small as possible and moves all of the supporting infrastructure to the other side of the boundary?
* At the VM/container or physical machine boundary? That's outrageously expensive and obviously impossible to comply with.

The race to replace Redis

Posted May 22, 2024 15:30 UTC (Wed) by ssokolow (guest, #94568) [Link]

The key distinction is that the SSPL is trying to broaden the scope of what must be shared beyond the legal precedents for "derived work".

The AGPL is just trying to be a patch on the GPL so that you can't dodge the "users who receive the binary must have GPL'd access to the source" part by doing SaaS.

The GPL and LGPL already lean on "Yes, some people will tie their codebase in multi-process knots to minimize how much they have to share, but we're OK with that. There's a limit to what's practical, scalable, etc." and the LGPL is narrowing the requirements down from "entire derive work" to "just this library... even if that's an uncertain legal requirement in this implementation language".