Redis will no longer be OSS... now what?
![](https://seccdn.libravatar.org/avatar/af8a9293484ed04b89081d848929b19a.jpg?s=120&d=mm&r=g)
Hey everyone, It looks like Redis, Inc. has announced that future versions of Redis are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a fork of Redis coming up, we will likely need to remove Redis from openSUSE. All I can say is... :( [1]: https://redis.com/blog/redis-adopts-dual-source-available-licensing/ -- 真実はいつも一つ!/ Always, there's only one truth!
![](https://seccdn.libravatar.org/avatar/5cdd10d836bdda3796cf6bc1ab2d5a78.jpg?s=120&d=mm&r=g)
On Wed, 2024-03-20 at 18:20 -0400, Neal Gompa wrote:
Hey everyone,
It looks like Redis, Inc. has announced that future versions of Redis are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a fork of Redis coming up, we will likely need to remove Redis from openSUSE.
All I can say is... :(
[1]: https://redis.com/blog/redis-adopts-dual-source-available-licensing/
That's quite bad news. For our packages in Tumbleweed, that means at least the following packages will need to be checked sooner orlater:
dependson redis redis : iredis python-Logbook python-cachelib python-django-cacheops python-django-q python-django-redis python-django-rq python-dynaconf python-logutils python-mocket:test python-pytest-server-fixtures python-redis python-requests-cache python-rq python-rq-scheduler python-rq:test python-sorl-thumbnail weblate
Of course we don't have to drop redis right away - the version we currently ship is still BSD-3-Clause licensed and that is not going to change - we just can't update to redis 7.4 and later (short term, Redis Inc. even commited to backport security fixes to the BSD-3-Clause license source tree; but that is also a question of time). Cheers, Dominique
![](https://seccdn.libravatar.org/avatar/d3a20bec8951854eb1db68a111438a2a.jpg?s=120&d=mm&r=g)
On Wed Mar 20, 2024 at 11:34 PM CET, Dominique Leuenberger wrote:
It looks like Redis, Inc. has announced that future versions of Redis are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a fork of Redis coming up, we will likely need to remove Redis from openSUSE.
Closing of the project is just a bump in the road, which FLOSS community navigate around: https://codeberg.org/redict/redict Matěj -- http://matej.ceplovi.cz/blog/, @mcepl@floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 How fleeting are all human passions compared to the massive continuity of ducks. -- Dorothy L. Sayers: Gaudy Night
![](https://seccdn.libravatar.org/avatar/3d586c792067fd2470d90197c537c3be.jpg?s=120&d=mm&r=g)
I was about to suggest that maybe it will lead to more adoption of of Dragonfly [1], when I realized that project too does not use an OSI approved license. [1] https://github.com/dragonflydb/dragonfly On 3/20/24 23:20, Neal Gompa wrote:
Hey everyone,
It looks like Redis, Inc. has announced that future versions of Redis are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a fork of Redis coming up, we will likely need to remove Redis from openSUSE.
All I can say is... :(
[1]: https://redis.com/blog/redis-adopts-dual-source-available-licensing/
-- 真実はいつも一つ!/ Always, there's only one truth!
![](https://seccdn.libravatar.org/avatar/bacd858b1ad8455b8bc763bd512ca152.jpg?s=120&d=mm&r=g)
I was about to suggest that maybe it will lead to more adoption of of Dragonfly [1], when I realized that project too does not use an OSI approved license.
What I found is KeyDB: <https://github.com/Snapchat/KeyDB> From their README:
KeyDB maintains full compatibility with the Redis protocol, modules, and scripts. This includes the atomicity guarantees for scripts and transactions. Because KeyDB keeps in sync with Redis development KeyDB is a superset of Redis functionality, making KeyDB a drop in replacement for existing Redis deployments.
-nik
![](https://seccdn.libravatar.org/avatar/04ffcb9ba74bfcbacabec9db6cee1c3e.jpg?s=120&d=mm&r=g)
On 20 March 2024 23:20:32 CET, Neal Gompa <ngompa13@gmail.com> wrote:
Hey everyone,
It looks like Redis, Inc. has announced that future versions of Redis are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a fork of Redis coming up, we will likely need to remove Redis from openSUSE.
From what I recall, we use redis with the following services: - pagure (code.opensuse.org) - discourse (forums.opensuse.org) - synapse (matrix.opensuse.org) - calendar-o-o (calendar.opensuse.org) Sidekiq, which is what requires redis in discourse and calendar-o-o doesn't support anything but redis and dragonfly either. This will be a painful migration whenever we have to do it LCP [Jake] https://lcp.world/
![](https://seccdn.libravatar.org/avatar/008a8db3f6a813af5f8064f2be96e100.jpg?s=120&d=mm&r=g)
On Thu, 21 Mar 2024 06:33:58 +0100, Jacob Michalskie wrote:
Sidekiq, which is what requires redis in discourse and calendar-o-o doesn't support anything but redis and dragonfly either. This will be a painful migration whenever we have to do it
I imagine that there will be some work done to work around the change in licensing - if redict (which was mentioned earlier) is a drop-in replacement, I'm sure sidekiq will adjust to being able to support it (unless it's also going through a similar license change). -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
![](https://seccdn.libravatar.org/avatar/af8a9293484ed04b89081d848929b19a.jpg?s=120&d=mm&r=g)
On Thu, Mar 21, 2024 at 9:59 AM Jim Henderson <hendersj@gmail.com> wrote:
On Thu, 21 Mar 2024 06:33:58 +0100, Jacob Michalskie wrote:
Sidekiq, which is what requires redis in discourse and calendar-o-o doesn't support anything but redis and dragonfly either. This will be a painful migration whenever we have to do it
I imagine that there will be some work done to work around the change in licensing - if redict (which was mentioned earlier) is a drop-in replacement, I'm sure sidekiq will adjust to being able to support it (unless it's also going through a similar license change).
Following up on this, it seems like that Valkey is where things are going for the main Redis replacement (with licensing and contributors from the original project, plus better governance than Redis), so I've started to bring it into openSUSE: https://build.opensuse.org/request/show/1179160 There's also an included valley-compat-redis package that can be used to transparently replace redis with valkey, though I have not turned on automatically replacing redis with valkey on upgrade yet. That will require some coordination with the Redis package maintainer (Danilo Spinella) first. -- 真実はいつも一つ!/ Always, there's only one truth!
![](https://seccdn.libravatar.org/avatar/008a8db3f6a813af5f8064f2be96e100.jpg?s=120&d=mm&r=g)
On Fri, 7 Jun 2024 02:30:44 -0700, Neal Gompa wrote:
Following up on this, it seems like that Valkey is where things are going for the main Redis replacement (with licensing and contributors from the original project, plus better governance than Redis), so I've started to bring it into openSUSE: https://build.opensuse.org/request/show/1179160
There's also an included valley-compat-redis package that can be used to transparently replace redis with valkey, though I have not turned on automatically replacing redis with valkey on upgrade yet. That will require some coordination with the Redis package maintainer (Danilo Spinella) first.
Sounds good. We'll likely need to do some testing, as well as validate that Discourse sees valkey as a suitable replacement (as a drop-in replacement, it *should* be). -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
![](https://seccdn.libravatar.org/avatar/5b748275c3dbb1ceee18ed554486547d.jpg?s=120&d=mm&r=g)
On Wednesday 2024-03-20 23:20, Neal Gompa wrote:
Hey everyone,
It looks like Redis, Inc. has announced that future versions of Redis are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a fork of Redis coming up, we will likely need to remove Redis from openSUSE.
All I can say is... :(
If there's one thing that the current millenium has, it's too many reimplementations of everything. On the other hand, that means finding a substitute was never easier.
participants (8)
-
Dominik George
-
Dominique Leuenberger
-
Georg Pfuetzenreuter
-
Jacob Michalskie
-
Jan Engelhardt
-
Jim Henderson
-
Matěj Cepl
-
Neal Gompa