The race to replace Redis [LWN.net]

The race to replace Redis

Posted Apr 7, 2024 16:55 UTC (Sun) by immibis (subscriber, #105511)
In reply to: The race to replace Redis by mjg59
Parent article: The race to replace Redis

The same way it's obvious that Linux clones are derivative works of Linux. "Work" does not mean "program". It can be larger or smaller than a program.

to post comments

The race to replace Redis

Posted Apr 7, 2024 19:35 UTC (Sun) by Wol (subscriber, #4433) [Link] (5 responses)

I thought in computing, "clone" meant "copy from scratch". Which, legally, is NOT a derivative work. Otherwise, SCOG could have easily won their lawsuit.

In copyright law, a true computing clone cannot infringe copyright. Which means copyright licences are worth about as much as scrap paper.

Cheers,
Wol

The race to replace Redis

Posted Apr 7, 2024 20:13 UTC (Sun) by immibis (subscriber, #105511) [Link] (4 responses)

There would likely be a fair use exception to copying the Linux API, but the work that copied it would still have copied it. See Oracle vs Google.

The race to replace Redis

Posted Apr 8, 2024 12:14 UTC (Mon) by Wol (subscriber, #4433) [Link] (3 responses)

And to the best of my knowledge Oracle lost that fair and square.

Google's primary defence was "APIs cannot be copyrighted" and, iirc, they won that by a slam dunk in the District Court. Oracle managed to get it overturned at the appeal level, but wasn't the appeal overturned?

Cheers,
Wol

The race to replace Redis

Posted Apr 8, 2024 15:03 UTC (Mon) by paulj (subscriber, #341) [Link] (2 responses)

I think you may be wrong. APIs were found to be copyrightable. However, there are some defences available to copyright infringement, including fair use. And Google eventually prevailed on a fair use defence.

IMU.

The race to replace Redis

Posted Apr 8, 2024 16:18 UTC (Mon) by Wol (subscriber, #4433) [Link] (1 responses)

I was worried about that. So I guess it didn't go to the Supremes, because the argument there probably was "Google won anyway, so why should we hear it?". Ouch!

If it comes up again, the new defendant should be free to make the same arguments that APIs are not copyrightable, and appeal any loss, but hopefully the "fair use" argument will put any predators off. Not a pleasant state of affairs.

Cheers,
Wol

The race to replace Redis

Posted Apr 9, 2024 20:06 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

It went to the Supreme Court: https://arstechnica.com/series/series-oracle-v-google/

They ruled that Google's use was fair use.

The race to replace Redis

Posted Apr 7, 2024 20:57 UTC (Sun) by mjg59 (subscriber, #23239) [Link]

So Linux is a derivative work of AT&T Unix? This… really does not seem like an argument you want to make.

The race to replace Redis

Posted Apr 8, 2024 13:06 UTC (Mon) by immibis (subscriber, #105511) [Link] (7 responses)

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.

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