Redis tightens its license terms, pleasing basically no one
- Reference: 1711092789
- News link: https://www.theregister.co.uk/2024/03/22/redis_changes_license/
- Source link:
The official [1]announcement of the change gets right to the point:
Starting with Redis 7.4, Redis will be dual-licensed under the [2]Redis Source Available License (RSALv2) and [3]Server Side Public License (SSPLv1).
It is not the first time Redis has changed its terms. Back in 2018 it [4]changed the license on some of its modules in ways which upset a quite a few open source luminaries.
The Reg has [5]previously described Redis as "the most popular database in the world – if, that is, your world is solely within AWS". Formerly, Redis's source code was available under the [6]BSD 3-clause license – a [7]permissive one which allows developers to make commercial use of the code without paying.
Soon after that change, one of the other big NoSQL database vendors, MongoDB, [8]also changed its license in an effort to reduce commercial exploitation of its code. It created a new license called the [9]Server Side Public License – which is [10]not liked by some open source folks. Even so, a few years later, [11]Elasticsearch also adopted the SSPL – again to the dismay of some purists.
[12]
This controversial SSPL licence is one of the two that Redis is adopting under a dual-license approach, along with the same RSAV that it's been using since 2018 for some of its modules.
[13]
[14]
The change will take effect from Redis version 7.4, and we expect that multiple Linux distributors will drop Redis from their codebases. Discussions are already taking place on the openSUSE and Fedora mailing lists.
However, the disruption will probably be modest and temporary, as alternatives are already available – such as the [15]still BSD-licensed fork KeyDB . There's also [16]Microsoft's Garnet , although that has the drawback of being writting in C#. Another Redis alternative, [17]Dragonfly , is less likely as it's covered by the BSL, [18]as recently adopted by HashiCorp .
[19]
A predictable response to Redis's decision is what happened to HashiCorp's Terraform: the [20]code was forked to become OpenTF , which was [21]later renamed OpenTofu .
[22]Cloud Software Group snubs GPL obligations, say critics
[23]Linux kernel 4.14 gets a life extension, thanks to OpenELA
[24]HashiCorp reportedly considering sale amid growing challenges
[25]Securing open source software: Whose job is it, anyway?
These changes reflect the FOSS community's growing desperation at trying to make open source pay, which has even led to [26]developers sabotaging their own code . Others [27]stop offering free community support , while some are attempting [28]sponsorship approaches .
The SSPL is quite close to the [29]GNU Affero General Public License , or AGPL, and includes most of the text from it – as you can see from [30]this comparison [PDF]. The important difference in the SSPL is its clause 13, which begins:
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License.
The traditional GPL requires, among other things, that if you provide your users with executable binary code, you must also provide them with the source code. Back in 2007, the AGPL extended this so that if you provide your users with that code's function over a network , you must also provide them with the source code, as [31]tl;drLegal explains .
The AGPL is the GPL for SaaS apps: it [32]closes the loophole in the GPL that a SaaS vendor isn't distributing their code. When the AGPL was still quite new, [33]this was sometimes controversial – and [34]sometimes it still is .
The SSPL extends the AGPL, such that not only must you provide the source code of the app itself but the entire service built around it:
"Service Source Code" means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service.
That's the part that the open source folks are upset about. According to [35]industry guardian the Open Source Initiative , the [36]SSPL is not an open source license . It reminds us of how [37]terrified big vendors were of the "viral" GPL.
It also puts us in mind of the more recent events around [38]Red Hat's changes to the ways in which it makes its source code available. This vulture was startled to be invited [39]on stage last month at the FOSDEM conference in Brussels – mostly because he felt compelled to defend Red Hat against accusations of "open washing."
Arguments like [40]this on Stack Exchange about the important differences between the AGPL and the SSPL will continue. Software is only open source if the OSI says it is, but we feel it's important to bear in mind that [41]open source is not the same as free software .
[42]
There is nothing wrong with making money from free software. Even Richard Stallman [43]says so .
If such licenses help software vendors to make money from their efforts, that is a good thing. If they can do that and also prevent vast billion-dollar businesses from exploiting those product and those companies then, for this writer, that's better still. ®
Get our [44]Tech Resources
[1] https://redis.com/blog/redis-adopts-dual-source-available-licensing/
[2] https://redis.com/legal/rsalv2-agreement/
[3] https://redis.com/legal/server-side-public-license-sspl/
[4] https://www.theregister.com/2018/08/23/redis_database_license_change/
[5] https://www.theregister.com/2020/11/23/redis_the_most_popular_db_on_aws/
[6] https://opensource.org/license/bsd-3-clause
[7] https://fossa.com/blog/open-source-software-licenses-101-bsd-3-clause-license/
[8] https://www.theregister.com/2018/10/16/mongodb_licensning_change/
[9] https://www.mongodb.com/legal/licensing/server-side-public-license
[10] https://www.percona.com/blog/why-is-mongodbs-sspl-bad-for-you/
[11] https://www.theregister.com/2021/01/18/elastics_doubling_down_on_open/
[12] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Zf1kxjoFZTNmWSs9I6IB1gAAAAo&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zf1kxjoFZTNmWSs9I6IB1gAAAAo&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[14] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zf1kxjoFZTNmWSs9I6IB1gAAAAo&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[15] https://github.com/Snapchat/KeyDB
[16] https://microsoft.github.io/garnet/
[17] https://github.com/dragonflydb/dragonfly
[18] https://www.theregister.com/2023/08/11/hashicorp_bsl_licence/
[19] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zf1kxjoFZTNmWSs9I6IB1gAAAAo&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[20] https://www.theregister.com/2023/08/28/opentf_forks_terraform_code/
[21] https://www.theregister.com/2023/09/20/terraform_fork_opentf_opentofu/
[22] https://www.theregister.com/2024/03/21/csg_fails_to_honor_agpl/
[23] https://www.theregister.com/2024/03/19/kernel_414_life_extension/
[24] https://www.theregister.com/2024/03/18/hashicorp_sale_report/
[25] https://www.theregister.com/2024/03/08/securing_opensource_software_whose_job/
[26] https://www.theregister.com/2022/01/10/npm_fakerjs_colorsjs/
[27] https://www.theregister.com/2022/01/13/opensource_apacheplc4x_payment/
[28] https://www.theregister.com/2023/04/07/thanksdev_open_source_funding/
[29] https://www.gnu.org/licenses/agpl-3.0.en.html
[30] https://webassets.mongodb.com/_com_assets/legal/SSPL-compared-to-AGPL.pdf
[31] https://www.tldrlegal.com/license/gnu-affero-general-public-license-v3-agpl-3-0
[32] https://fossa.com/blog/open-source-software-licenses-101-agpl-license/
[33] https://www.theregister.com/2008/04/24/ubuntu_affero_launchpad/
[34] https://www.theregister.com/2024/03/21/csg_fails_to_honor_agpl/
[35] https://www.theregister.com/2018/02/03/open_source_turns_20/
[36] https://opensource.org/blog/the-sspl-is-not-an-open-source-license
[37] https://www.theregister.com/2001/06/25/open_source_terror_stalks_microsofts/
[38] https://www.theregister.com/2023/06/23/red_hat_centos_move/
[39] https://fosdem.org/2024/schedule/event/fosdem-2024-3113-rhel-and-centos-and-the-growth-of-openwashing-in-foss/
[40] https://opensource.stackexchange.com/questions/8025/difference-between-mongodb-sspl-and-gnu-agpl?newreg=00d65f9b61e8415a88ab1b09ab40685d
[41] https://www.theregister.com/2018/02/12/open_source_initiative_at_20/
[42] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zf1kxjoFZTNmWSs9I6IB1gAAAAo&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[43] https://www.theregister.com/2023/10/27/open_source_vs_sort_of_open_source/
[44] https://whitepapers.theregister.com/
Re: Open Source developers
Open source != amateur.
Whilst you can release code that you write as an amateur as open source, if it becomes popular then you're going to need to spend more and more time on it, and being paid for that time isn't an unreasonable expectation... particularly when others are making substantial profits using the fruits of your labour. And for many of these larger projects it's not just one person coding them on a couple of hours in the evening in their back room.
The alternative is that the demands of users take up too much of your time and you just drop it...
Re: Open Source developers
I work for an Open-Source company, full time. I get paid for my efforts. The core product is available, on GitHub, under the Apache license. I think I have the necessary expertise to answer.
Most of the code that I wrote is not "contributed", it goes into our product. A small proportion of the code I wrote goes into other OSS products. I don't "contribute" it, either, rather my employer agrees that it is part of how we work. Using OSS tools had this great advantage that we can actually add small bits and get the tools that work for us.
Like Redis Labs, we offer our products on the cloud, or with "enterprise" support, for those who need it. This is how we make a living, so it is actually reasonably important to us. We don't have a competing cloud supplier,, yet. When we start having one, we will indeed have a problem. OTOH, if the name of that vendor thymes with "OWS", we will simultaneously have a major problem and be raking in many millions a year.
Yes, the software industry is a tough place. No, OSS is not a bunch of long-haired hippies - although that, too.
Re: Open Source developers
You may not be "contributing" to these external projects but your employer certainly is, presumably they see value in doing so.
Drew DeVault started a fork called Redict: https://codeberg.org/redict/redict
Licenses help software vendors to make money
One can't help feeling that once they resort to licence-engineering, software vendors might find they'd make more money becoming full-time lawyers.
The interesting thing about the SSPL is that it appears to be, essentially, a "poison pill" licence. Because it requires adopters to make available every aspect of the service, including "hosting software", it effectively precludes using any piece of proprietary software in the provision of the service as well as imposing the burden of distributing not only the software implementing the service, but all of its dependencies.
The interesting thing about the whole situation is there is, basically, no shortage of code: as the article says there are forks and alternative implementations. In that sense, the Open Source movement has over-delivered: we actually have more code than we need.
The problem is maintenance and support, as we all know, and no-one seems yet to have found the solution. However, I doubt that it will be found in staking territorial claims that result in more forks and re-implementations and hence in more precariously-maintained code than we started with.
"Software is only open source if the OSI says it is"
Bollocks.
We all know that [1]OSI claims to have created the term (yes, they "created" it, not just "adopted" it!) but even [2]Wikipedia (known for forgetting the past because they can't find a URL for it) point out that the phrase was already in use.
The OSI have their uses[1] but gatekeeping all of open source is not it[2].
[1] e.g. I'll applaud their early collection of OSS licences in one place, which seemed to help slow the increase in "My One Licence Terms"; OTOH their lack of even references to analyses of the licences and when they are appropriate is a *major* hole.
[2] I'd have more respect if they used wording like [3]"The OSI compliant Open Source Definition" or, even better, had managed to trademark the phrase they "created", but as it stands they are guilty of the same grandstanding and self-adulation that we roast other companies for.
[1] https://opensource.org/history
[2] https://en.wikipedia.org/wiki/History_of_free_and_open-source_software
[3] https://opensource.org/osd
Open Source developers
Sure, they need to eat like everyone else. No argument there.
But I thought they were contributing code on their free time, meaning they already had a job.
It would appear that I was mistaken. These devs are coding Open-Source full-time and expect to be paid for it.
That wasn't how Open Source started. Maybe it's time to go back to the roots ?