The race to replace Redis [LWN.net]

The race to replace Redis

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

The Elasticache service is obviously a derivative work of Redis, so it should be covered. The SSPL attempts to make this explicit, instead of deferring to the FSF's wrong interpretation.

to post comments

The race to replace Redis

Posted Apr 6, 2024 17:55 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (23 responses)

From the perspective of copyright, how is that obvious?

The race to replace Redis

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

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.

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

The race to replace Redis

Posted Apr 8, 2024 10:51 UTC (Mon) by ras (subscriber, #33059) [Link] (6 responses)

I'm not disagreeing with the point you are making, but it seems to me when it comes to copyright nothing is obvious. In fact the definition of "derivative work" applied to software is downright opaque.

The outstanding illustration to me is how badly the AGPL is viewed. If you believe it's detractors it infects everything. According to Cyberax if you believe corporate lawyers he deals with it's pure poison. Yet it's text identical to the GPL in every place bar one, and that place doesn't deal with the definition of derivative work.

In fact given Cyberax's comments on the attitude of Amazon's corporate lawyers to the AGPL I'm surprised Redis didn't consider it to be a good enough AWS repellent. But perhaps they aren't targeting just AWS.

The race to replace Redis

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

> I'm not disagreeing with the point you are making, but it seems to me when it comes to copyright nothing is obvious. In fact the definition of "derivative work" applied to software is downright opaque.

Given that - OF NECESSITY - all copyright licences defer to the law and make no attempt to define it themselves, QUELLE SURPRISE.

The FSF have made it quite clear that they consider linking to create a derivative work, but they have (sensibly) made no attempt to define a linked work as being derivative.

Pick is a p-code engine - I consider the GPL as pretty much useless for trying to get complete works released as GPL. Because it doesn't link, applying the GPL to a Pick program probably is - in practical terms - pretty much identical to applying the MPL, a much weaker copyleft licence.

Yes it's a mess, but that's basically because you're trying to fit mathematical logical concepts into a framework designed for literary not-necessarily-logical works. Round pegs square holes and all that ...

Cheers,
Wol

The race to replace Redis

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

Corporate lawyers are in the business of aggressively trying to make you give away all your rights to them. There's something of a licensing Overton window (let's define upper licenses as more copyleft and lower as more permissive). They will always try to convince you the upper side of the window is toxic poison to shift the window downwards. Once they successful convince everyone the AGPL is pure poison they'll move on to the GPL and then the LGPL, and then MIT and convince you to public-domain everything, and if they somehow manage to succeed at that, they'll try to convince you public domain is bad and you should assign your copyright to *their company* for safekeeping.

They've already succeeded to a moderate extent if you've noticed the large number of developers who don't like the GPL.

The fact that corporate lawyers don't like something tells you more about the corporation than about the something.

The legal definition of "derivative work" is not obvious, but we should probably act as if it's on our side. That's what corporate lawyers do - act as if it's on their side and try to convince everyone it's on their side - and it often works for them. They've succeeded in convincing a lot of developers that some technical step in the creation of software (such as linking) is what creates a derivative work and thereby made a lot of people pre-emptively give up on derivative work infringement "cases" that might have actually been enforceable.

If there's any ambiguity as to whether your work is derivative of a corporation's, you better believe that corporation is going to sue you and find out what the judge thinks, not just shrug its shoulders and say the definition of a derivative work is ambiguous. Free software has to be pursued with the same zealotry, not every single time, but at least enough times that corporations are scared it could happen and don't do it, just like we're usually scared of them.

Otherwise the corporate lawyers win by default.

The race to replace Redis

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

To be fair, when I MIT things instead of GPLing them, it's because I figure that MITing them is the lesser of two evils when the alternative is "Sorry, I'm not accepting contributions because I want the freedom to be able to use my creations for work in non-GPL contexts and I don't want to be 'that CLA guy'."

(i.e. I do ideologically agree with the GPL... but I gotta eat too and MITing is less of a dick move than GPL plus requiring copyright assignment because it's more equitable if other contributors get the same rights for commercial reuse.)

The race to replace Redis

Posted May 22, 2024 17:23 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (2 responses)

What problem do you have with using GPL in your work? Do you only take contracts where the customer is clueless enough NOT to require source code of the creation?

The race to replace Redis

Posted May 22, 2024 18:42 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

> Do you only take contracts where the customer is clueless enough NOT to require source code of the creation?

Please READ what the GP wrote. Don't read into it what he very clearly did NOT say ...

(BTW, I've said it before, I probably won't bother with GPL for most of my code because, you know what, it's a waste of space sticking it on stuff that it doesn't work on.)

Cheers,
Wol

The race to replace Redis

Posted May 25, 2024 6:51 UTC (Sat) by zdzichu (subscriber, #17118) [Link]

That was a question, Neil.