The race to replace Redis [LWN.net]

The race to replace Redis

Posted Apr 8, 2024 13:06 UTC (Mon) by immibis (subscriber, #105511)
In reply to: The race to replace Redis by immibis
Parent article: The race to replace Redis

In the above comment Linux clones were a bad example and the first thing that came to mind. Another one is a Linux driver for a trivial hardware device so that most of the driver is Linux code rather than device code. It's generally believed the NVIDIA driver isn't a derivative work of Linux because it's almost all original NVIDIA work with just a Linux shim layer, but this may not be the case for all drivers. Some are quite intertwined with Linux subsystems. The point was supposed to be that linking != derivative and program != copyrightable work.

to post comments

The race to replace Redis

Posted Apr 8, 2024 15:53 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (5 responses)

But in that case, what would be the use of SSPL - if you want to argue that copyright works that way, AGPL already covers the scenarios that SSPL is intended to cover?

The race to replace Redis

Posted Apr 9, 2024 10:19 UTC (Tue) by immibis (subscriber, #105511) [Link] (4 responses)

The FSF's opinion is that it doesn't. Even if it actually does, it can be valuable to make it explicit in the licence so that everyone is on the same page.

The race to replace Redis

Posted Apr 9, 2024 16:29 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (3 responses)

The AGPL explicitly applies to derived works. If the FSF disagrees that the areas the SSPL covers are covered by the AGPL, that implies that it's not obvious that these are derived works.

The race to replace Redis

Posted Apr 10, 2024 10:44 UTC (Wed) by immibis (subscriber, #105511) [Link] (2 responses)

When I link libslice (AGPL), libdice, and sockets to make slicendiceserv, I'm required to release the source code of libdice under AGPL even though it is not a derivative work of libslice.

The race to replace Redis

Posted Apr 10, 2024 19:46 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (1 responses)

No, you're required to release the source code for the entire work that's a derivative of the AGPL work. There's broad (but not 100%) agreement that that argument can be made for other dynamically linked libraries incorporated into the work, but I don't see any widespread argument that purely as a matter of copyright law it can be taken further.

The race to replace Redis

Posted Apr 10, 2024 21:42 UTC (Wed) by immibis (subscriber, #105511) [Link]

What do you mean by "purely as a matter of copyright law"? The libslice license agreement states that to copy libslice, you must do X, Y and Z. Z is releasing the source code of libdice under AGPL. If you don't do that, you have no right to run slicendiceserv on the network as you copied libslice without permission.

There is no need for libslice and libdice to have any relationship, for this to apply. It is as if I make a contract with you: I give you $5, and you refuse to paint John's house. We can enter that contract even if neither of us is a house painter and even if neither of us know where John lives. There's no asking "as a matter of house painting law, can the $5 be related to the house painting?"

The race to replace Redis

Posted Apr 8, 2024 17:45 UTC (Mon) by Wol (subscriber, #4433) [Link]

> It's generally believed the NVIDIA driver isn't a derivative work of Linux because it's almost all original NVIDIA work with just a Linux shim layer, but this may not be the case for all drivers.

This confuses two issues. As far as NVIDIA is concerned, Linux is a derivative work of NVIDIA because Linux has been modified to work with the NVIDIA driver ... and seeing as (was it NVIDIA?) did the modifications they wouldn't have a leg to stand on if they complained. (If it wasn't them wrote the modifications, they probably don't care and by now it's eminent estoppel.)

And as far as Linux is concerned, Linus has always been very clear that the existence of a published A(P/B)I delineates a clear boundary which copyright is deemed not to cross. So whether linking has occurred or not (in many / most cases I would argue it has), there exists a clear grant of licence to create derivative works.

As PJ said, "law is squishy". Imho linking always creates a derivative work, but firstly you need to ask which is the derivative work, secondly whether a licence exists, and thirdly whether any copyright exists to enforce!

As for "is a program a copyrightable work", my answer would be "if it's not trivial, yes it is". But again, what's "trivial"? The mathematical meaning feels completely wrong to most people - the proof of Fermat's Last Theorem is "trivial" - it follows inevitably from the pre-conditions, but it's a heck of a lot of hard slog to do the maths.

A program is a lot like a novel - the basic plot - what the program does - is not copyrightable, but the way you do it *probably* contains a lot of creativity - not directly related to the actual solution - that you can copyright.

Cheers,
Wol