The race to replace Redis [LWN.net]

The race to replace Redis

Posted Mar 29, 2024 3:32 UTC (Fri) by willy (subscriber, #9762)
In reply to: The race to replace Redis by immibis
Parent article: The race to replace Redis

The FSF, Debian and Red Hat have all concluded that the SSPL doesn't meet their definitions of Free Software. Harder to make those groups out as shills for Big Cloud.

to post comments

The race to replace Redis

Posted Mar 29, 2024 5:54 UTC (Fri) by immibis (subscriber, #105511) [Link] (4 responses)

The last I saw was that the FSF hadn't made a determination and the others were just following the OSI determination.

The race to replace Redis

Posted Mar 29, 2024 12:18 UTC (Fri) by jzb (editor, #7867) [Link] (2 responses)

It looks like RMS has weighed in, though I think you're correct that the FSF hasn't made an official determination. (If it has, I have not been able to find it.)

This is what he had to say about it:

We have not yet studied the SSPL. Many other things have seemed to be higher priority. But since it has been rejected as "open source", I suppose it won't qualify as free either.

I tend to think that trying to impose copyright-based rules that stretch beyond the bounds of one single program is abuse of copyright, based on what I learned in the past.

The SSPL's use restriction and requirements to convey "all programs that you use to make the Program or modified version available" — basically, the entire stack underneath an SSPL'ed application — renders it non-free in my (not a lawyer) opinion. That touches a lot of software well outside the scope of the program, and is nearly impossible to comply with.

The race to replace Redis

Posted Apr 4, 2024 16:33 UTC (Thu) by kpfleming (subscriber, #23250) [Link] (1 responses)

It *is* impossible to comply with if any of the software in that stack was received under licenses that are not compatible with the SSPL and for which the user does not have relicensing permission. Certainly any software under any GPL-family license would fall into this category, and since most (if not all) SSPL-licensed software is developed to run on Linux, you don't need to look far to find an impossible-to-comply situation.

If the drafters of the SSPL hadn't chosen to require that all of the "Service Source Code" itself be made available under the SSPL, but instead permitted that code to be distributed under any SSPL-compatible license, much of this problem would disappear. Presumably they made that choice for what they considered to be a good reason.

The race to replace Redis

Posted Apr 4, 2024 21:08 UTC (Thu) by Wol (subscriber, #4433) [Link]

> If the drafters of the SSPL hadn't chosen to require that all of the "Service Source Code" itself be made available under the SSPL, but instead permitted that code to be distributed under any SSPL-compatible license, much of this problem would disappear. Presumably they made that choice for what they considered to be a good reason.

Or are they non-lawyers going under the (somewhat common) misapprehension that mixing source modules under different licences can change the licence ... a lot of people seem to think that mixing GPL and BSD magically transmutes the BSD code into GPL code ...

Cheers,
Wol

The race to replace Redis

Posted Mar 29, 2024 12:28 UTC (Fri) by seyman (subscriber, #1172) [Link]

The FSF has not commented on the SSPL, to the best of my knowledge. I've always interpreted it as them agreeing with the OSI verdict and not seeing any benefit to piling on with theirs.

Debian and Fedora have explained why they consider the SSPI not Free. People can judge for themselves if they're just going along with the OSI or thinking for themselves.