The race to replace Redis [LWN.net]

The race to replace Redis

Posted Apr 12, 2024 8:15 UTC (Fri) by sammythesnake (guest, #17693)
In reply to: The race to replace Redis by immibis
Parent article: The race to replace Redis

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

to post comments

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".