The race to replace Redis [LWN.net]

The race to replace Redis

Posted Mar 29, 2024 10:06 UTC (Fri) by ddevault (subscriber, #99589)
In reply to: The race to replace Redis by immibis
Parent article: The race to replace Redis

The SSPL is, in my opinion, essentially a fake license. It is designed, I think deliberately, to be impossible to comply with. That's a feature, not a bug, because it only exists to lend a veneer of open source to a product that the vendor wants you to buy a different license for.

Some of its technical problems are elaborated on in detail here:

https://ssplisbad.com/

to post comments

The race to replace Redis

Posted Apr 1, 2024 16:36 UTC (Mon) by immibis (subscriber, #105511) [Link] (33 responses)

The wording is really bad, I agree. We should make a new one that maintains the spirit and fixes the letter. However that is a reason to *fix* the SSPL, not to reject it outright. Outright rejection happens for other reasons, not this one.

The reaction to the SSPL is similar to the past reactions to the AGPL and the GPL. Nobody wants strings to be attached to the stuff they're getting for free.

The race to replace Redis

Posted Apr 2, 2024 0:29 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (4 responses)

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

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

The race to replace Redis

Posted Apr 2, 2024 7:25 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (26 responses)

The GPL limits itself to covering things that are derived works of the GPLed work. There are no other licenses considered free software that go further than that. The SSPL absolutely goes beyond what would be considered a derived work, and there's absolutely zero clarity on how far that stretches (can you even legitimately run SSPLed software on a server running proprietary firmware? There's an argument that UEFI is a Standard Interface, but in most cases there's no fully free software implementation of UEFI without having to deal with at least some proprietary components, so who knows?). That's a meaningful distinction, and maybe free software licenses *should* try to reach beyond the derivative work boundary, but there's no degree of even rough consensus on that being a good idea right now.

The race to replace Redis

Posted Apr 6, 2024 16:15 UTC (Sat) by immibis (subscriber, #105511) [Link] (24 responses)

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.

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.

The race to replace Redis

Posted Apr 6, 2024 16:26 UTC (Sat) by Wol (subscriber, #4433) [Link]

> The GPL limits itself to covering things that are derived works of the GPLed work. There are no other licenses considered free software that go further than that.

Because any licence that goes further than that is not a copyright licence. It can't be. And it falls foul of the FLOSS requirement not to impinge on unrelated works.

Like in my other comment, are the drafters of SSPL non-lawyers who don't understand the reach (and lack thereof too) of copyright licences?

Cheers,
Wol

The race to replace Redis

Posted Apr 5, 2024 18:09 UTC (Fri) by jschrod (subscriber, #1646) [Link]

> We should make a new one

So, are you connected to Redis, the company?

If yes, it was dishonest to not mention this in your thread-starting comment, IMNSHO.