|
|
Subscribe / Log in / New account

The race to replace Redis

LWN.net needs you!

Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing

By Joe Brockmeier
March 28, 2024

On March 21, Redis Ltd. announced that the Redis "in-memory data store" project would now be released under non-free, source-available licenses, starting with Redis 7.4. The news is unwelcome, but not entirely unexpected. What is unusual with this situation is the number of Redis alternatives to choose from; there are at least four options to choose as a replacement for those who wish to stay with free software, including a pre-existing fork called KeyDB and the Linux Foundation's newly-announced Valkey project. The question now is which one(s) Linux distributions, users, and providers will choose to take its place.

A short history of Redis

Redis has a complicated backstory. Salvatore Sanfilippo (also known as "antirez") started the project to use as "a different kind of database" with a realtime log-analyzer application called LLOOGG, because MySQL was not meeting his needs. Instead of creating a relational database, he designed the project as a simple dictionary database that stored a key-value pair in memory—its name is a contraction of "remote dictionary server". It has, of course, matured and accrued many more features over the years. Redis quickly became popular as part of the NoSQL movement, and he was hired by VMware to work on Redis development in 2010. He moved to VMware's spin-off, Pivotal, in 2013 and continued to work on the project.

Around that time, Redis was growing in popularity, with high-profile use by Twitter and Pinterest, among others, and started to appear in Linux distributions. It was packaged for Ubuntu in the 12.04 (April 2012) release, Fedora 18 (January 2013), and others. Support for Redis was added to Amazon Web Service's (AWS) ElastiCache service in September 2013, which took advantage of, and helped bolster, Redis's popularity.

In early 2013, a startup called Garantia Data started offering Redis services and positioning itself as a better alternative to "open source Redis". Garantia took a first round of funding in November 2013 and floated changing its corporate name to RedisDB. After some pushback from Sanfilippo, the company renamed itself Redis Labs, instead, in early 2014. Sanfilippo joined Redis Labs as the lead for open-source development in 2015. He remained with Redis Labs until stepping down in 2020.

In 2018, Redis Labs adopted a new license for its add-on modules that provide features on top of the core database. The company chose to use a modified version of the Apache License, Version 2.0, with an addition called the Commons Clause. This clause restricted selling the software or charging for services. The rationale given for the switch was that cloud providers were "taking advantage of the open source community" by selling services based on open-source code they didn't develop. At the time, the company pledged that Redis "is BSD and will always remain BSD".

It was not the only company to start experimenting with use-restrictive licenses. Venture-backed database companies, in particular, were starting to run toward new licenses to try to ensure they could exclusively sell services using the software. MariaDB had created the Business Source License (BSL) for a product called MaxScale in 2016, and MongoDB launched the Server Side Public License (SSPL) in late 2018. Eventually, Redis Labs settled on a dual-license scheme of SSPL and its own Redis Source Available License (RSAL) for its modules.

The company dropped "Labs" from its name in mid-2021. In announcing the name change, Redis again committed to open source, and said that the company renaming "will not affect the licensing of open source Redis, which has always been and will continue to be BSD licensed". The company also put in place a governance model that would place major decisions about Redis's "architecture, design, or philosophy" with a community "core team". One would expect that team's mandate to include the license for Redis itself. The governance page is no longer on Redis's web site, but is available on the Internet Archive's Wayback Machine. It listed a core team of five members, three from Redis (Yossi Gotlieb, Oran Agra, and Itamar Haber) as well as Zhao Zhao from Alibaba and Madelyn Olson from AWS.

On March 20, Redis announced that "all future versions of Redis will be released with source-available licenses", specifically the SSPL and RSAL. Rowan Trollope, Redis CEO, wrote that maintaining the BSD license was now "at odds with our ability to drive Redis successfully into the future". Future versions, in this case, means Redis 7.4 and later. The announcement's FAQ says that, following the company's security policy, security patches will be backported to previous versions under the original three-clause BSD license.

Cloud versus open source

Proponents of use-restrictive licenses like the SSPL and Redis's RSAL have tried to position this solely as a battle between giant cloud providers like AWS and open source, where use restrictions are the only logical alternative and cloud providers are the only losers. In 2019, Redis Labs then-CEO Ofer Bengal was quoted as saying that there were "many different views" after Redis adopted its source-available licenses for Redis modules, but that it was necessary to compete with cloud providers:

Some people condemned that [license change]. But after the initial noise calmed down — and especially after some other companies came out with a similar concept — the community now understands that the original concept of open source has to be fixed because it isn't suitable anymore to the modern era where cloud companies use their monopoly power to adopt any successful open source project without contributing anything to it.

In the March 20 announcement, Trollope wrote that "cloud service providers will be able to deliver Redis 7.4 only after agreeing to licensing terms with Redis, the maintainers of the Redis code" but, that "nothing changes for the Redis developer community who will continue to enjoy permissive licensing under the dual license".

The choice of the phrase "permissive licensing" is misleading. Redis is able to adopt a non-free license scheme for 7.4 and later versions because external developers had granted their contributions under the permissive BSD license. The terms of the SSPL and RSAL are incompatible with common usage of the term "permissive" in the open source community.

It is also hard to reconcile the claims that cloud providers do not contribute with the actual commits to the Redis repository. A quick examination of the commits since the 7.0.0 release using gitdm shows 967 commits over that time period:

Top changeset contributions by employer
(Unknown)33134.2%
Tencent24024.8%
Redis18919.5%
Alibaba656.7%
Huawei505.2%
Amazon.com505.2%
Bytedance192.0%
NetEase131.3%

Binbin Zhu BinBin Wang, of Tencent, is responsible for nearly 25% of the commits to the project. Some of the contributors without a readily identifiable employer surely are Redis employees, but it's clear that the company has not been working alone. (Note that some single-digit contributors were omitted.)

Changing distribution model

So it should be apparent that code contribution is beside the point. Redis is a venture-backed company that has taken more than $350 million in funding over many rounds since 2011. The company, and its investors, seem to have calculated that they can safely move away from open source to try to capture more revenue.

They have some reason to believe this is the case, if MongoDB's results are any guide. The company went public in 2017 and moved to the SSPL a little more than a year later. Shortly afterward, major Linux distributions stopped packaging the database because it no longer met their licensing standards. But, by that time, the company had set its sights on a platform model that would encourage developers (and their employers) to use and pay for MongoDB and ancillary offerings with the as-a-service model. Distributing a source-available version of MongoDB could be seen as a loss-leader strategy to reach developers that the company wagered did not care about open-source.

As Redmonk founder Stephen O'Grady wrote in 2017:

As developers began to assert control over technical selection and direction in increasing numbers, even in situations where a proprietary alternative is technically superior, the sheer accessibility of open source software gave it an enormous market advantage. Choosing between adequate option A that could be downloaded instantly and theoretically superior option B gated by a salesperson was not in fact a choice.

But open source, noted Grady, "is typically less convenient than service-based alternatives" and if convenience is the most important factor then open source has a problem. Especially when vendors like MongoDB have learned from proprietary vendors that "locking in customers is good for business".

Is it good for business? MongoDB has kept growing, adding customers, and brought in $1.68 billion its last fiscal year. That's more than a 30% increase, and its Atlas database service revenue also increased more than 30%, demonstrating that a lot of companies would rather pay to use the service than try to host it themselves. Despite all that, the company is still losing money—more than $345 million in the same time period.

But, investors may be more interested in stock price than actual profit. The company's stock started around $33 a share when it went public, but is now more than $350 a share. Redis's investors would likely be happy if it can produce similar results.

Forks and alternatives

Venture-backed vendors seem to have, as O'Grady wrote last year, reached a consensus that they can move away from open source. Especially if they are not "actively opposed by other commercial interests, foundations and other interested industry participants". Here, Redis may have miscalculated the industry mood.

When Hashicorp adopted BSL for its projects last year, a fork of its Terraform project appeared within days and was embraced by the Linux Foundation under the name OpenTofu. On March 28, the foundation announced that it was supporting Valkey, a direct fork of Redis 7.2.4, with Amazon Web Services (AWS), Google Cloud, Oracle, Ericsson, and Snap named as backers of the effort.

The Valkey fork got its life just a few days after the Redis license change. Olson wrote that she and "various former Redis contributors" had started working on a fork, using the original three-clause BSD license, with "placeholderkv" as a temporary name. Olson, Zhao, Viktor Söderqvist, and Ping Xie were listed as maintainers. According to Olson this was not an AWS fork of Redis, but "just me trying to keep the continuity with the community". KeyDB was considered, but it has diverged to the point that it "is missing a lot of stuff the community is used to".

The KeyDB fork was created in 2019 for technical, rather than licensing, reasons. The project, which billed itself as "a faster drop in alternative to Redis" was created by John Sully, Eric Blenkarn, and Ben Schermel, who wanted a multithreaded version and were not able to persuade Redis maintainers to go in that direction. Sully and Schermel started a company, also called KeyDB, that offered a proprietary enterprise version. The entire codebase became fully open source under the three-clause BSD license when KeyDB was acquired by Snap in 2022.

The problem with KeyDB as a direct alternative is that it hasn't kept up with Redis since it forked. It still lacks many features found in Redis 7, and Sully indicated that there's little time for him to work on issues "not directly affecting Snap", though the project "would of course welcome outside help and we can certainly name additional maintainers if there is community interest in helping". On March 22, Sully updated another issue and said he was in discussions to "potentially" add maintainers to bring KeyDB closer to Redis 7. It's not clear yet whether Valkey will supplant KeyDB, but Snap's involvement makes that seem likely over the long term.

Drew DeVault, founder and CEO of SourceHut, has also created a fork named Redict based on Redis 7.2.4, but chose to use the LGPLv3. In his announcement post, he said that the choice of license was "a deliberate one which balances a number of concerns". DeVault wanted a license that was copyleft but "as easy as possible for users to comply" with the license and to ease integrations with Redis-compatible modules or Lua plugins that can be used to perform operations within Redis. He also noted that Redict will have no contributor license agreement (CLA), but contributors would be asked to verify contributions with a developer certificate of origin. Despite his connection to SourceHut, DeVault chose to host Redict on Codeberg to "provide a comfortable and familiar user experience for anyone comfortable with the GitHub-based community" of Redis.

Another kind-of contender is Microsoft's Garnet, announced on March 18. According to the announcement, it has been in development by Microsoft Research since 2021. It is a remote cache-store that can cache and manage the same types of data as Redis and is designed to be compatible with the Redis serialization protocol. Garnet is MIT-licensed, written in .NET C#, and is not meant to be a direct drop-in replacement. However, its API compatibility page claims that it can be "regarded as a close-enough starting point" that works "unmodified with many Redis clients". Many, but not all. For example, one user attempted to switch a NodeJS application to Garnet, but found that Redis's FLUSHALL command is not currently supported. Adding support for missing APIs on is on the project's roadmap.

Scramble for alternatives

Once again, Linux distributions are left with a mess to clean up. Neal Gompa opened a discussion on the Fedora development list, noting the license change and the need to remove Redis from Fedora. Jonathan Wright replied that KeyDB might be a replacement; he had been "loosely working on packaging" before the license change. He later said that KeyDB would be "a step backwards and cause headaches" for those looking to replace later versions of Redis. Nevertheless, he wrote on March 23 that he had pushed builds that were ready for testing for Fedora and EPEL 8 and 9.

Shortly after the Valkey announcement, Wright wrote that he would be packaging it as soon as there is a tagged release. Wright also said that he is "anticipating valkey becoming the [de facto] replacement for redis in most places."

Gompa also raised the issue on openSUSE's Factory discussion list. Dominique Leuenberger replied with a list of 18 packages with dependencies on the redis package in Tumbleweed. The initial discussion mentioned Redict and KeyDB as possible replacements, but Valkey had not been announced yet.

Having to find a replacement to ship in place of Redis is not the only problem for community distributions. Jacob Michalskie called out several services in use by the openSUSE project that will need a Redis replacement, including the Pagure code-hosting software (created and used by Fedora as well) used for code.opensuse.org, and the Discourse forum software.

Debian contributor Guillem Jover filed a Request for Package (RFP) for KeyDB as a potential replacement for Redis. Jover said he was not sure if he was up for sole maintainership, but was happy to give a hand. In an email exchange with Jover, he told me that his company had migrated from Redis 6 to KeyDB and it was a "smooth transition". According to Jover, "KeyDB might be lacking some features compared to Redis 7, but we have neither noticed we miss any or felt we were missing out on anything."

Jover said that it was too early to tell whether the newer forks would continue to be maintained, and that Redict's LGPLv3 licensing "might also be problematic for the ecosystem". In a follow-up email after the Valkey announcement, he said "I think we'll probably go further with packaging KeyDB for Debian at least, if it dies out it can always be removed or transitioned out from there."

Path forward

It is, of course, too soon to predict whether one or more of the forks will gain significant traction—but it seems likely that Valkey will be a credible alternative. The possibility of a swift fork with widespread community and industry backing should give pause to vendors who expect a smooth path after abandoning open source.



(Log in to post comments)

The race to replace Redis

Posted Mar 28, 2024 22:58 UTC (Thu) by carlosrodfern (subscriber, #166486) [Link]

Excellent article. Thank you for the analysis.

The race to replace Redis

Posted Mar 29, 2024 2:25 UTC (Fri) by immibis (subscriber, #105511) [Link]

SSPL is a copyleft license based on broadening AGPL. The logic by which SSPL is considered nonfree also makes AGPL and GPL nonfree, which is actually insane. I think the OSI is completely in the wrong on this point. I note that the OSI is mostly a consortium of cloud service vendors.

The race to replace Redis

Posted Mar 29, 2024 3:12 UTC (Fri) by jhoblitt (subscriber, #77733) [Link]

If the SSPL and the AGPL are equivalent (hint: they aren't), then only one of them needs to exist.

There is a line in terms of impingements upon freedoms every open source developers is willing to tolerate. For many, AGPL is close to that line and the SSPL is on the wrong side of it.

There are of course also concerns that SSPL requires legal authorities outside of copyright law.

The race to replace Redis

Posted Mar 29, 2024 3:32 UTC (Fri) by willy (subscriber, #9762) [Link]

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.

The race to replace Redis

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

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]

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]

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.

The race to replace Redis

Posted Mar 29, 2024 7:06 UTC (Fri) by pbonzini (subscriber, #60935) [Link]

The difference is that the SSPL breaks the "License Must Not Restrict Other Software" clause of the open source definition. In contrast the GPL and LGPL have an explicit text saying that they don't extend to other software even if distributed on the same medium, if that constitutes "mere aggregation").

(In addition it's debatable whether it's possible at all to distribute all the required components under the SSPL, which would constitute a restriction on making use of the program in a specific field of endeavor; but that's not necessary given the previous point).

The race to replace Redis

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

The SSPL also doesn't extend to other software existing on the same medium. I think the best way to view it is that it extends the definition of "linking" for the age of the web app, to close loopholes in the GPL that web apps exploit. It stops allowing you to manipulate "at arm's length" to avoid "linking" two programs that are, in reality, still intimately related.

Is AWS DynamoDB (for example) a work? Common sense says that it's still *a* work, no matter how many executable files it's divided up into. And that work is derived from all of the parts that it's derived from. And if any of those are AGPL, so is the whole thing. Except it's not, because the FSF seems to believe each executable file is a separate work just because the interfaces are documented.

SSPL is supposed to fix that.

It also has some wording problems that may make it unusable, but if that's our only objection then we should make a new license like SSPL but with those problems fixed, instead of rejecting it outright.

The race to replace Redis

Posted Mar 29, 2024 8:50 UTC (Fri) by fw (subscriber, #26023) [Link]

The AGPL does not create any additional obligations over the GPL if one does not modify the software. The SSPL obligations apply even if one runs unmodified versions, as distributed by upstream. Certainly this is a major difference.

The race to replace Redis

Posted Mar 30, 2024 18:24 UTC (Sat) by ballombe (subscriber, #9523) [Link]

The AGPL clause is problematic for being meaningless but the AGPL has an escape hatch:
you do not have to accept the license to run the software.

The race to replace Redis

Posted Mar 30, 2024 18:56 UTC (Sat) by pizza (subscriber, #46) [Link]

>The AGPL clause is problematic for being meaningless but the AGPL has an escape hatch:
> you do not have to accept the license to run the software.

Except of course when you have to modify the "source" to configure [1] said software, which is the norm in dynamic/scripting languages.

[1] basic stuff like site URLs, feature flags, database configuration, autentication/credentials, theming, etc etc..

The race to replace Redis

Posted Mar 29, 2024 10:06 UTC (Fri) by ddevault (subscriber, #99589) [Link]

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/

The race to replace Redis

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

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]

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]

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]

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]

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 Apr 2, 2024 7:25 UTC (Tue) by mjg59 (subscriber, #23239) [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. 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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

The race to replace Redis

Posted Apr 1, 2024 0:59 UTC (Mon) by Heretic_Blacksheep (subscriber, #169992) [Link]

Unless you're a lawyer with a specialization in copyright law, you're not qualified to offer such an opinion.

The race to replace Redis

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

> Unless you're a lawyer with a specialization in copyright law, you're not qualified to offer such an opinion.

Even if you ARE a lawyer with a specialisation in copyright law, are you *competent* to offer such an opinion?

Based on my personal experience, a lot of people - professionals especially - are incompetent. As one of my doctor acquaitances said to me - "half of all people are below average intelligence. Doctors are just ordinary people - what does that say about doctors?".

And given what's happened to me and my family, I wouldn't trust a professional as far as I could throw them. I value *experience* far more than qualifications, and there's nobody more dangerous (and unemployable) than the fresh young turk straight out of University with First Class Honours, who thinks he knows everything ...

Cheers,
Wol

The race to replace Redis

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

In comment https://lwn.net/Comments/967874/, immibis wrote about the license

> The wording is really bad, I agree. We should make a new one that maintains the spirit and fixes the letter.

So, it might well be that he is involved in this license change.

The race to replace Redis

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

Unless you're the same, by the same reasoning, are you not qualified to offer this opinion on my opinion? Is any developer allowed to have any opinion on any license? This is a bad take.

The race to replace Redis

Posted Apr 8, 2024 10:40 UTC (Mon) by jubal (subscriber, #67202) [Link]

AGPL is borderline free software, SSPL is not free software thanks to the limits it puts on the fields of endeavour. pray read the debian social contract and the debian free software guidelines. it's perfectly fine to attempt to control use of the software, but any such attempt goes against the established definition of what free software *is*.

The race to replace Redis

Posted Apr 8, 2024 12:48 UTC (Mon) by immibis (subscriber, #105511) [Link]

Sorry, but "limits on fields of endeavour" is simply propaganda. The SSPL places no limit on fields of endeavour, not any more than AGPL does anyway - you could make an argument that AGPL "targets" cloud services just like SSPL does, and you could also make an argument that GPL "targets" monolithically linked programs.

The race to replace Redis

Posted Apr 11, 2024 15:11 UTC (Thu) by jubal (subscriber, #67202) [Link]

please read the debian free software guidelines, and please do not reply to me until you have read it in full. you might want to also read debian's social contract, when you're at it, it's linked from the wiki page.

The race to replace Redis

Posted Apr 11, 2024 9:26 UTC (Thu) by TheBicPen (guest, #169067) [Link]

+1. If anything, SSPL grants additional freedoms to users of software. The OSI says that the additional terms compared to AGPL are restrictions, and hence, SSPL is not an open-source license. By that logic, AGPL itself adds "restrictions" (read: freedoms) to GPL that also make it not truly open-source.

The race to replace Redis

Posted Apr 13, 2024 11:08 UTC (Sat) by jubal (subscriber, #67202) [Link]

i'll bite: what are the additional freedoms?

The race to replace Redis

Posted Apr 13, 2024 18:42 UTC (Sat) by immibis (subscriber, #105511) [Link]

Freedom for the user to fork the service, obviously.

The race to replace Redis

Posted Apr 14, 2024 17:42 UTC (Sun) by jubal (subscriber, #67202) [Link]

that's an additional freedom compared to what, precisely?

The race to replace Redis

Posted Apr 15, 2024 14:40 UTC (Mon) by immibis (subscriber, #105511) [Link]

The user not being allowed to fork the service. Was that a trick question?

The race to replace Redis

Posted Apr 15, 2024 23:02 UTC (Mon) by jubal (subscriber, #67202) [Link]

did you by any chance read the debian free software guidelines and the debian social contract already? thanks in advance. i can't bloody believe that i see people praising damn source-available proprietary software for being source-available in a blasted 2024 and not being ashamed of comparing that bullshit to free software.

The race to replace Redis

Posted Apr 16, 2024 9:59 UTC (Tue) by Wol (subscriber, #4433) [Link]

There's also the apparent failure to understand the difference between "software" ie "all the instructions" ie "a document that could be printed out", and a "service" ie "here's a computer that is running the software".

I can understand some FS fanatics being upset that they are provided with a SERVICE that lets them USE software without being entitled to a copy of said software, but at the end of the day services and software are two completely different things. It doesn't help the discussion if you act as if they're interchangeable ...

Cheers,
Wol

The race to replace Redis

Posted Apr 16, 2024 11:37 UTC (Tue) by immibis (subscriber, #105511) [Link]

The SSPL, like the GPL, does not mandate anyone to provide you with free computers. Only the software is covered.

s/BSL/BuSL/g

Posted Mar 29, 2024 6:22 UTC (Fri) by mirabilos (subscriber, #84359) [Link]

BSL is Boost’s (and not a nōn-free licence), the newcomer does not get to occupy the same name, which is also listed in SPDX.

s/BSL/BuSL/g

Posted Mar 29, 2024 9:46 UTC (Fri) by aragilar (subscriber, #122569) [Link]

s/BSL/BuSL/g

Posted Apr 13, 2024 15:03 UTC (Sat) by Wol (subscriber, #4433) [Link]

> the newcomer does not get to occupy the same name

Okay, I'm not sure of the context here, but this is different IP.

I think copyright licences should be about copyright, not about trademarks, patents, etc, but to explicitly point out that a copyright licence does not give permission to infringe trademark is perfectly okay.

Cheers,
Wol

s/BSL/BuSL/g

Posted Apr 13, 2024 17:13 UTC (Sat) by mirabilos (subscriber, #84359) [Link]

I don’t know what comment you are replying to, but *I* was pointing out that LWN used the wrong shortname for the licence: BSL is Boost’s, the nōn-free licence is shortened BuSL.

s/BSL/BuSL/g

Posted Apr 15, 2024 13:44 UTC (Mon) by daroc (editor, #160859) [Link]

Oh! That makes more sense; I didn't understand when I read your first comment. I've pointed this out to Joe. In the future, please feel free to submit typo (or think-o) reports to lwn@lwn.net; one of us is always watching that address so that we can respond to things quickly.

The race to replace Redis

Posted Mar 30, 2024 11:25 UTC (Sat) by gmgod (subscriber, #143864) [Link]

Like others, I really like this article. It's exhaustive and laid out well.

Regarding the content and the situation, GAFAM has been fuding the hell out of developers to convince them BSD/MIT is the only way... Now they have their ways for minute or no contribution at all (what's missing from this article are the kind of commits that were contributed to "refactor core engine to yield 30% more perf on average" is the not the same as "add a hook to facilitate AWS integration").

I still remember ElasticSearch's lead going mental (as in "really upset and distressed") with how their open-ass licensing was supposed to bring in more contributions and yet only allowed Amazon to get fatter by selling their OSS. It looks like the same story is bound to happen again and again. If you are not happy with anyone else profiting from your software, don't use a license that allows it. If you don't want your lawn to be used by randos, don't open your gate and put a sign reading "public park".

So now the situation has nearly gone full cycle... Proprietary -> hard copyleft -> soft copyleft -> permissive -> ...

I'm sure in 5 years, the time it will still take for consulting to pick it up, the whole "what are you doing, BSD/MIT is the only way if you want contributions" will be transformed into "if you want to make money with it, go proprietary or choose a strong copyleft license so that you don't shoot yourself in the foot by providing downstream with all your patches and not requiring they do the same".

The race to replace Redis

Posted Mar 30, 2024 13:21 UTC (Sat) by pizza (subscriber, #46) [Link]

> I still remember ElasticSearch's lead going mental (as in "really upset and distressed") with how their open-ass licensing was supposed to bring in more contributions and yet only allowed Amazon to get fatter by selling their OSS.

Amazon isn't "selling [ElasticSearch's] OSS" -- It is "selling a service built using ElasticSearch's OSS". That's a _crucial_ difference.

At the end of the day, the _software_ is in of itself irrelevant; what matters is the _services_ the software can be used to provide. When it comes to providing services, it's pretty much impossible to compete with the giant players' scale [1]. Especially when those giant players are (more often than not) deriving the majority of their income from datamining users of those services, an approach that is only feasible once you get to a certain size.

[1] Unlike software that is "one-and-done" with a marginal reproduction cost of effectively zero, providing services has an incremental per-use[r] cost (bandwidth, compute, storage; plus the ongoing infrastructure/management cost of robustly scaling).

The race to replace Redis

Posted Mar 30, 2024 18:42 UTC (Sat) by gmgod (subscriber, #143864) [Link]

I really don't see how any of this is in reply to what I said, on spite of the citations...

BSD/MIT and other permissive licenses allow anyone to do almost anything with the software and most of the recent (and more ancient) license changes we've seen all come down to "oh shit, big companies make big buck based on what we do without contributing back enough to ensure we are sustainable". Whatever added value those company may or may not provide is irrelevant.

The software is not irrelevant when it's part of the service. Try to repeat yourself gas, or breaks, are irrelevant when buying a car and see how far it goes.

Those people just realised it's hard to build a business model where all the work you do can directly be integrated downstream. Downstream thus becomes strictly superior the day they provide anything at all. That's not a good situation to be in when you try to earn a living for that work.

The race to replace Redis

Posted Mar 30, 2024 19:03 UTC (Sat) by pizza (subscriber, #46) [Link]

> The software is not irrelevant when it's part of the service. Try to repeat yourself gas, or breaks, are irrelevant when buying a car and see how far it goes.

(Most) Folks don't care about a "car" in of itself, they care about the "transportation service" it provides/enables. Gas or even brakes aren't a given; transportation services can utilzie altenative fuels (eg electricity0 or eschew friction braking in favor of alternative methods (eg regenerative, reverse thrust, etc).

Similarly, folks don't buy or download "software" for its own sake, they do so because it enables them to achieve certain things.

The race to replace Redis

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

The intention of the GPL is clearly that Amazon can do this, but they have to publish their modified and extended version of the software. AGPL fixes a loophole where they don't have to publish at all. SSPL tries to fix a loophole where they have to publish their modifications but not their extensions.

The race to replace Redis

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

> The intention of the GPL is clearly that Amazon can do this, but they have to publish their modified and extended version of the software.

WRONG WRONG WRONG.

Okay, the GPL was written for the days when SAAS was not a thing, but the intent of the GPL is quite clearly you have NO OBLIGATION WHATSOEVER to share, but sharing is an "all or nothing" proposition.

Cheers,
Wol

The race to replace Redis

Posted Apr 5, 2024 16:36 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

> When it comes to providing services, it's pretty much impossible to compete with the giant players' scale

Actually that very much depends on the amount of margins those giant players want (and think they can afford) to charge. Even on-premises is competitive when the alternative is something someone else slapped a 80% services margin on. Never forget that the giant players are not so numerous and they would be quite happy to constitute an oligopoly for everything other players could not run themselves.

Going proprietary does not protect an ISV it ensures all the other players will invest in something else and gradually squeeze it out of the market (but the money is good VC-side while the squeezing is going on).

Long-term viability seems something open enough your product is accepted, and innovative enough part of the market prefers paying you for early access and a say in the product evolution. And there will be some freeloaders but those freeloaders will also keep cloud giants from making too much profit at your expense. One way or the other the level of margins an Oracle or Microsoft enjoyed before the internet seems out of reach now.

The race to replace Redis

Posted Apr 5, 2024 17:11 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

Also consider this. None of the “traditional” ISVs have made their money on software dev for a long looong time. For a couple of persons that worked on code there was an army of people doing QA sales ticketing and some form of service deploying software on premises (and if you were too small to deploy yourself you’d better partner with some consulting giant that would deploy things for your customers or you would miss out most sales).

Cloud services are not so different you still have a smallish core of people developing things and a mass of people making money out of it by deploying code operationally. I’m not sure the ratio of core people/other people has changed so much.

The race to replace Redis

Posted Apr 1, 2024 17:15 UTC (Mon) by c0r3dump3d (subscriber, #121602) [Link]

As an alternative, there is also dragonflydb: https://www.dragonflydb.io/

The race to replace Redis

Posted Apr 3, 2024 18:29 UTC (Wed) by jonathanspw (subscriber, #154835) [Link]

It does not use an OSI-approved open source license.


Copyright © 2024, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds