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 |
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) 331 34.2% Tencent 240 24.8% Redis 189 19.5% Alibaba 65 6.7% Huawei 50 5.2% Amazon.com 50 5.2% Bytedance 19 2.0% NetEase 13 1.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]
The race to replace Redis
Posted Mar 29, 2024 2:25 UTC (Fri) by immibis (subscriber, #105511) [Link]
The race to replace Redis
Posted Mar 29, 2024 3:12 UTC (Fri) by jhoblitt (subscriber, #77733) [Link]
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 race to replace Redis
Posted Mar 29, 2024 5:54 UTC (Fri) by immibis (subscriber, #105511) [Link]
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]
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]
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]
(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]
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 race to replace Redis
Posted Mar 30, 2024 18:24 UTC (Sat) by ballombe (subscriber, #9523) [Link]
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]
> 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]
Some of its technical problems are elaborated on in detail here:
The race to replace Redis
Posted Apr 1, 2024 16:36 UTC (Mon) by immibis (subscriber, #105511) [Link]
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]
* 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.
The race to replace Redis
Posted Apr 7, 2024 16:56 UTC (Sun) by immibis (subscriber, #105511) [Link]
The race to replace Redis
Posted Apr 12, 2024 8:15 UTC (Fri) by sammythesnake (guest, #17693) [Link]
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]
* 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 race to replace Redis
Posted Apr 6, 2024 16:15 UTC (Sat) by immibis (subscriber, #105511) [Link]
The race to replace Redis
Posted Apr 6, 2024 17:55 UTC (Sat) by mjg59 (subscriber, #23239) [Link]
The race to replace Redis
Posted Apr 7, 2024 16:55 UTC (Sun) by immibis (subscriber, #105511) [Link]
The race to replace Redis
Posted Apr 7, 2024 19:35 UTC (Sun) by Wol (subscriber, #4433) [Link]
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]
The race to replace Redis
Posted Apr 8, 2024 12:14 UTC (Mon) by Wol (subscriber, #4433) [Link]
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]
IMU.
The race to replace Redis
Posted Apr 8, 2024 16:18 UTC (Mon) by Wol (subscriber, #4433) [Link]
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]
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]
The race to replace Redis
Posted Apr 8, 2024 13:06 UTC (Mon) by immibis (subscriber, #105511) [Link]
The race to replace Redis
Posted Apr 8, 2024 15:53 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
The race to replace Redis
Posted Apr 9, 2024 10:19 UTC (Tue) by immibis (subscriber, #105511) [Link]
The race to replace Redis
Posted Apr 9, 2024 16:29 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
The race to replace Redis
Posted Apr 10, 2024 10:44 UTC (Wed) by immibis (subscriber, #105511) [Link]
The race to replace Redis
Posted Apr 10, 2024 19:46 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
The race to replace Redis
Posted Apr 10, 2024 21:42 UTC (Wed) by immibis (subscriber, #105511) [Link]
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]
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]
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]
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]
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]
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]
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]
The race to replace Redis
Posted Apr 1, 2024 16:21 UTC (Mon) by Wol (subscriber, #4433) [Link]
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]
> 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]
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]
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]
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]
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 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]
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]
s/BSL/BuSL/g
Posted Mar 29, 2024 6:22 UTC (Fri) by mirabilos (subscriber, #84359) [Link]
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]
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]
s/BSL/BuSL/g
Posted Apr 15, 2024 13:44 UTC (Mon) by daroc (editor, #160859) [Link]
The race to replace Redis
Posted Mar 30, 2024 11:25 UTC (Sat) by gmgod (subscriber, #143864) [Link]
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]
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]
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]
(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 race to replace Redis
Posted Apr 6, 2024 16:31 UTC (Sat) by Wol (subscriber, #4433) [Link]
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]
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]
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]
The race to replace Redis
Posted Apr 3, 2024 18:29 UTC (Wed) by jonathanspw (subscriber, #154835) [Link]