Redis will no longer be OSS... now what?

[Neal Gompa]

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

All I can say is... :(

[1]: https://redis.com/blog/redis-adopts-dual-source-available-licensing/

[Jonathan Wright]

We can potentially look to https://github.com/Snapchat/KeyDB which I've
been loosely working on packaging anyway.

On Wed, Mar 20, 2024 at 5:21 PM 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
> Fedora.
>
> All I can say is... :(
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Neal Gompa]

On Wed, Mar 20, 2024 at 6:26 PM Jonathan Wright via devel
 wrote:
> We can potentially look to https://github.com/Snapchat/KeyDB which I've been loosely working on packaging anyway.

I'll want to test this for Pagure at least, since we're going to have
to switch our recommendations around soon because of this.

[Jonathan Wright]

Looking back at my work on KeyDB, it's basically ready for package review
once we do some de-vendoring work.  I was hoping upstream would do it but
over a year and they haven't, so I guess I'll try to tackle it and PR it
back to them.

https://github.com/Snapchat/KeyDB/issues/493

On Wed, Mar 20, 2024 at 5:29 PM Neal Gompa  wrote:
> On Wed, Mar 20, 2024 at 6:26 PM Jonathan Wright via devel
>  wrote:
> > We can potentially look to https://github.com/Snapchat/KeyDB which I've
>
> been loosely working on packaging anyway.
> >
>
> I'll want to test this for Pagure at least, since we're going to have
> to switch our recommendations around soon because of this.
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!

[Scott Williams]

Assuming KeyDB gets accepted (it looks close from the Bugzilla review), we should obsolete redis for KeyDB in Fedora 40+ and consider eventually doing likewise with EPEL as well, since we aren't going to be able to ship any redis patches moving forward.  I feel less strongly about that for EPEL as for Fedora.  As a Fedora redis user, personally, having KeyDB in-place replace redis on upgrade to Fedora 40 seems like the best possible route moving forward to limit end-user disruption and technical debt for Fedora.

As long as KeyDB's multi-threading isn't enabled out of box, it should essentially be equivalent to redis-6 as I understand it.  We're currently shipping redis-7.2.4 in Fedora 39.  Are there any potential redis-7 specific compatibility problems with KeyDB migration?

[Jonathan Wright]

Anything that was new in Redis 7 is not currently in KeyDB.  This is a
decent list of features I found that would be impacted.

https://www.instaclustr.com/blog/redis-7-new-features/

KeyDB has it on their roadmap to merge in the latest features from Redis 7
but that's not complete yet (nor can I find any published status on that).
EPEL doesn't currently provide Redis for 8/9 because it got pulled in
directly by RH.  RHEL 9 does have a module for redis 7 but the default is
6, so that's easy at least.  There should be no problems with adding KeyDB
to EPEL 8/9 - in fact it doesn't even conflict with redis (though
keydb-devel will conflict with redis-devel as keydb-devel still uses
identical names of some libraries it produces).

Honestly trying to replace redis with KeyDB in Fedora would be a step
backwards and cause headaches so I don't think it's feasible, at least
until redis v7 features are merged into KeyDB.

On Thu, Mar 21, 2024 at 1:05 PM Scott Williams  wrote:
> Assuming KeyDB gets accepted (it looks close from the Bugzilla review), we
> should obsolete redis for KeyDB in Fedora 40+ and consider eventually doing
> likewise with EPEL as well, since we aren't going to be able to ship any
> redis patches moving forward.  I feel less strongly about that for EPEL as
> for Fedora.  As a Fedora redis user, personally, having KeyDB in-place
> replace redis on upgrade to Fedora 40 seems like the best possible route
> moving forward to limit end-user disruption and technical debt for Fedora.
>
> As long as KeyDB's multi-threading isn't enabled out of box, it should
> essentially be equivalent to redis-6 as I understand it.  We're currently
> shipping redis-7.2.4 in Fedora 39.  Are there any potential redis-7
> specific compatibility problems with KeyDB migration?
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Scott Williams]

Redis-6 is currently shipped in EPEL9, so it seems like a more obvious step-forward wrt EPEL.
> Honestly trying to replace redis with KeyDB in Fedora would be a step
> backwards and cause headaches so I don't think it's feasible, at least
> until redis v7 features are merged into KeyDB.

Unfortunately, it's still the best option we have.  Ideally, redis wouldn't have done this, but since redis is no longer license compatible, can we really continue to ship redis-7 in Fedora 40 if we can't patch and maintain it?  If KeyDB were to merge and release a v7 version against the latest BSD code, I agree that it would be a much better target for Fedora 40.  Unfortunately, we're in the awful position of having to choose between a breaking change for a small amount of users or shipping something that we can't patch or realistically maintain.  If we have some clue that a v7 merge/release is on the very near horizon for KeyDB, then maybe it makes sense to keep redis and obsolete it for KeyDB after GA, but it would be preferable, IMO, to have a clean break on Fedora 40 release if possible, which will also give us a better chance to document it so the small amount of impacted end-users wrt v7-specific things can prepare for it.

[Scott Williams]

> If we have some clue that a v7 merge/release
>  is on the very near horizon for KeyDB

This doesn't look promising for v7 in time for Fedora 40 or shortly after, unfortunately: https://github.com/Snapchat/KeyDB/issues/420

The choice of shipping an ever-stale v7 database versus a maintainable v6 one is not a fun one, but leaving it up to Fedora package maintainers to have to potentially come up with their own out-of-band patches for CVEs for redis-7 seems like the worse choice to me.

[Neal Gompa]

On Thu, Mar 21, 2024 at 2:24 PM Scott Williams  wrote:
> > If we have some clue that a v7 merge/release
> >  is on the very near horizon for KeyDB
>
> This doesn't look promising for v7 in time for Fedora 40 or shortly after, unfortunately: https://github.com/Snapchat/KeyDB/issues/420
>
> The choice of shipping an ever-stale v7 database versus a maintainable v6 one is not a fun one, but leaving it up to Fedora package maintainers to have to potentially come up with their own out-of-band patches for CVEs for redis-7 seems like the worse choice to me.

I think the immediate fix is pulling in redict once it makes its first
release: https://codeberg.org/redict/redict

[Jonathan Wright]

On Thu, Mar 21, 2024 at 1:28 PM Neal Gompa  wrote:
> On Thu, Mar 21, 2024 at 2:24 PM Scott Williams 
> wrote:
> > > If we have some clue that a v7 merge/release
> > >  is on the very near horizon for KeyDB
> >
> > This doesn't look promising for v7 in time for Fedora 40 or shortly
>
> after, unfortunately: https://github.com/Snapchat/KeyDB/issues/420
> > The choice of shipping an ever-stale v7 database versus a maintainable
>
> v6 one is not a fun one, but leaving it up to Fedora package maintainers to
> have to potentially come up with their own out-of-band patches for CVEs for
> redis-7 seems like the worse choice to me.
>
> I think the immediate fix is pulling in redict once it makes its first
> release: https://codeberg.org/redict/redict

I very much think we should take a wait and see approach for now.  KeyDB,
while slow, has at least published something.  redict is totally unknown.
Maybe it gets a huge following, maybe it doesn't.

We don't have to make any rash decisions since the current versions of
redis are in good shape for the time being.

[Scott Williams]

My concern there is that it has 7 code contributors with just one person having the vast majority of those commits.  That's not a problem for including the package, but it could be a concern for replacing redis with it given how young the project is and for it having significantly less resources than KeyDB (which has over 500 code contributors).

[Kevin Kofler]

Neal Gompa wrote:
> I think the immediate fix is pulling in redict once it makes its first
> release: https://codeberg.org/redict/redict

Once concern I have with this is the use of LGPL 3.0 *only*. This will not 
be compatible with a GPL 4 or newer. (The upgrade clause in the LGPLv2 that 
allowed that was unfortunately dropped in the LGPLv3, now you have to put 
the "or later" clause on the LGPLed code to be compatible with newer GPL 
versions.)

Kevin Kofler

[Kevin Kofler]

Kevin Kofler via devel wrote:
> Neal Gompa wrote:
> > I think the immediate fix is pulling in redict once it makes its first
> > release: https://codeberg.org/redict/redict
>
> Once concern I have with this is the use of LGPL 3.0 *only*. This will not
> be compatible with a GPL 4 or newer. (The upgrade clause in the LGPLv2
> that allowed that was unfortunately dropped in the LGPLv3, now you have to
> put the "or later" clause on the LGPLed code to be compatible with newer
> GPL versions.)

Also, the discussion under:
https://discourse.writefreesoftware.org/t/redis-switches-to-dual-source-avai...
makes it pretty clear that the person behind the fork has no intent to make 
any compromises on this issue.

For the redis executable, I guess this is not a blocking issue, but they 
also intend to fork the hiredis library (which currently is still BSD-
licensed upstream [https://github.com/redis/hiredis]), and there, LGPL 3.0 
only would really be a problem in the long run.

Kevin Kofler

[Michael Catanzaro]

On Fri, Mar 22 2024 at 02:44:33 PM +01:00:00, Kevin Kofler via devel 
 wrote:
> Once concern I have with this is the use of LGPL 3.0 *only*. This 
> will not
> be compatible with a GPL 4 or newer. (The upgrade clause in the 
> LGPLv2 that
> allowed that was unfortunately dropped in the LGPLv3, now you have to 
> put
> the "or later" clause on the LGPLed code to be compatible with newer 
> GPL
> versions.)

So I'm not an expert on redis, but it's primarily accessed via sockets, 
so the license doesn't actually matter for most users. I expect it will 
probably be fine regardless of the choice of license (as long as it 
doesn't go crazy and use AGPL).

But redis also has "modules" and I'm not familiar with them. The 
modules were switched back to BSD-3-Clause yesterday after I complained 
to Neal and then Neal complained to Drew:

https://codeberg.org/redict/redict/commit/d47ce2f24063728c09c3449e5deef3eddb...

But I'm not sure how much that really achieves. If the modules also 
link to LGPL-3.0-only code, then that probably accomplishes nothing.

I agree that most GPL or LPGL projects won't be willing to touch 
anything that uses an -only license rather than an -or-later license 
because the risk of not being able to "upgrade" the license in the 
future is extreme and prohibitive. And of course permissively-licensed 
projects will not touch anything that uses LGPL-3.0-only or 
LGPL-3.0-or-later anyway. But as long as there is the IPC/socket 
boundary in the middle, most programs should be fine. I wonder about 
these modules, though....

Michael

[Kevin Kofler]

Kevin Kofler via devel wrote:
> Once concern I have with this is the use of LGPL 3.0 *only*. This will not
> be compatible with a GPL 4 or newer. (The upgrade clause in the LGPLv2
> that allowed that was unfortunately dropped in the LGPLv3, now you have to
> put the "or later" clause on the LGPLed code to be compatible with newer
> GPL versions.)

Filed: https://codeberg.org/redict/redict/issues/10 – not holding my breath 
though…

Kevin Kofler

[Onuralp SEZER]

In Addition to that, I would rather wait a little bit and see about another
fork (s) and see ship possible redis-7+ versions instead of downgrading it.
Also PR shows very slow process so I wouldn't go for it.

On Thu, Mar 21, 2024 at 9:24 PM Scott Williams  wrote:
> > If we have some clue that a v7 merge/release
> >  is on the very near horizon for KeyDB
>
> This doesn't look promising for v7 in time for Fedora 40 or shortly after,
> unfortunately: https://github.com/Snapchat/KeyDB/issues/420
>
> The choice of shipping an ever-stale v7 database versus a maintainable v6
> one is not a fun one, but leaving it up to Fedora package maintainers to
> have to potentially come up with their own out-of-band patches for CVEs for
> redis-7 seems like the worse choice to me.
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Scott Williams]

FYI - It looks like there is a redis-7 to keydb-6 path:  https://github.com/Snapchat/KeyDB/issues/527#issuecomment-1370606311

[Carl George]

Redis is not shipped in EPEL9, because it's in RHEL9.  Same with EPEL8
and RHEL8.  It is shipped in EPEL7 at version 3.2, presumably because
updating any further would be an incompatible update.

The license change announcement clearly states it will only be for 7.4
and up.  The prior branches (6.2.x, 7.0.x, and 7.2.x) are still going
to be maintained as per their security policy [0], and I haven't seen
any indication that these maintenance updates will be anything other
than BSD-3-Clause licensed.  The license change commit has only
occurred upstream in their unstable branch (future 7.4), and the 7.2
branch still has the previous license file [1].  This isn't like when
mongodb switched to SSPL for all future versions, including
maintenance/security updates to older branches.  Considering these
factors, F39+ can stay on 7.2.x for quite some time.  F38 can stay on
7.0.x for the rest of its lifecycle. The only thing we can't do is
update any branch to 7.4.x.

Having keydb obsolete redis in Fedora would not be appropriate in my
opinion, because they are still different software, and a user may
want to have both installed at the same time.  Additionally, keydb in
EPEL definitely can't obsolete redis in RHEL.  Maybe at some point
we'll go the obsolete route in Fedora with a change proposal and FESCo
approval, but I don't think we're at that point yet.

[0] https://github.com/redis/redis/security/policy
[1] https://github.com/redis/redis/blob/7.2/COPYING

On Thu, Mar 21, 2024 at 1:19 PM Scott Williams  wrote:
> Redis-6 is currently shipped in EPEL9, so it seems like a more obvious step-forward wrt EPEL.
> > Honestly trying to replace redis with KeyDB in Fedora would be a step
> > backwards and cause headaches so I don't think it's feasible, at least
> > until redis v7 features are merged into KeyDB.
> Unfortunately, it's still the best option we have.  Ideally, redis wouldn't have done this, but since redis is no longer license compatible, can we really continue to ship redis-7 in Fedora 40 if we can't patch and maintain it?  If KeyDB were to merge and release a v7 version against the latest BSD code, I agree that it would be a much better target for Fedora 40.  Unfortunately, we're in the awful position of having to choose between a breaking change for a small amount of users or shipping something that we can't patch or realistically maintain.  If we have some clue that a v7 merge/release is on the very near horizon for KeyDB, then maybe it makes sense to keep redis and obsolete it for KeyDB after GA, but it would be preferable, IMO, to have a clean break on Fedora 40 release if possible, which will also give us a better chance to document it so the small amount of impacted end-users wrt v7-specific things can prepare for it.
>
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Remi Collet]

Le 21/03/2024 à 19:19, Scott Williams a écrit :
> can we really continue to ship redis-7 in Fedora 40 if we can't patch and maintain it?

I don't see any problem keeping Redis 7.2
in Fedora 40 and up for a while.

And having some alternatives (keydb...), to be installed
simultenously (especially for tests)

Then wait for stabilization of the community.

Remi
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Aaron Rainbolt]

On 3/20/24 17:19, 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
> Fedora.
>
> All I can say is... :(

In addition to KeyDB, there's also DragonflyDB: 
https://github.com/dragonflydb/dragonfly I mentioned Redis going 
source-available to the KDE devs and one of them linked this.

[Neal Gompa]

On Wed, Mar 20, 2024 at 8:13 PM Aaron Rainbolt  wrote:
> On 3/20/24 17:19, 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
> Fedora.
>
> All I can say is... :(
>
> In addition to KeyDB, there's also DragonflyDB: https://github.com/dragonflydb/dragonfly I mentioned Redis going source-available to the KDE devs and one of them linked this.

DragonFlyDB is not an open source database. It uses the BuSL license.

[Aaron Rainbolt]

On 3/20/24 19:23, Neal Gompa wrote:
> On Wed, Mar 20, 2024 at 8:13 PM Aaron Rainbolt  wrote:
> > On 3/20/24 17:19, 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
> > Fedora.
> >
> > All I can say is... :(
> >
> > In addition to KeyDB, there's also DragonflyDB: https://github.com/dragonflydb/dragonfly I mentioned Redis going source-available to the KDE devs and one of them linked this.
>
> DragonFlyDB is not an open source database. It uses the BuSL license.

Gosh... sigh. You're right. I saw it was on GitHub and assumed it was 
FOSS. My mistake.

[Jonathan Wright]

DragonflyDB is not an option, they do not use an OSI-approved license.  I
reached out to them a couple of years ago to see if they would swap to one
and they said they don't have an interest in it.

On Wed, Mar 20, 2024 at 7:13 PM Aaron Rainbolt  wrote:
> On 3/20/24 17:19, 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
> Fedora.
>
> All I can say is... :(
>
> In addition to KeyDB, there's also DragonflyDB:
> https://github.com/dragonflydb/dragonfly I mentioned Redis going
> source-available to the KDE devs and one of them linked this.
>
> --
> Aaron Rainbolt
> Lubuntu Developer
> Matrix: @arraybolt3:matrix.org
> IRC: arraybolt3 on irc.libera.chat
> GitHub: https://github.com/ArrayBolt3
>
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Jonathan Wright]

Is this all a misunderstanding?
https://redis.com/blog/redis-labs-modules-license-changes/ seems to claim
that redis-core which appears to cover redis-server and redis-sentinel will
remain BSD-3.

On Wed, Mar 20, 2024 at 7:38 PM Jonathan Wright 
wrote:
> DragonflyDB is not an option, they do not use an OSI-approved license.  I
> reached out to them a couple of years ago to see if they would swap to one
> and they said they don't have an interest in it.
>
> On Wed, Mar 20, 2024 at 7:13 PM Aaron Rainbolt 
> wrote:
> > On 3/20/24 17:19, 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
> > Fedora.
> >
> > All I can say is... :(
> >
> > In addition to KeyDB, there's also DragonflyDB:
> > https://github.com/dragonflydb/dragonfly I mentioned Redis going
> > source-available to the KDE devs and one of them linked this.
> >
> > --
> > Aaron Rainbolt
> > Lubuntu Developer
> > Matrix: @arraybolt3:matrix.org
> > IRC: arraybolt3 on irc.libera.chat
> > GitHub: https://github.com/ArrayBolt3
> >
> > --
> > _______________________________________________
> > devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/[e-mail]
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
>
> --
> Jonathan Wright
> AlmaLinux Foundation
> Mattermost: chat https://chat.almalinux.org/almalinux/messages/@jonathan

[Aaron Rainbolt]

On 3/20/24 20:40, Jonathan Wright via devel wrote:
> Is this all a misunderstanding? 
> https://redis.com/blog/redis-labs-modules-license-changes/ seems to 
> claim that redis-core which appears to cover redis-server and 
> redis-sentinel will remain BSD-3.

That was a bit over five years ago. This was a change to Redis itself, 
not the modules. 
https://github.com/redis/redis/blob/unstable/LICENSE.txt The words "This 
change has zero effect on the Redis core license, which is and will 
always be licensed under the 3-Clause-BSD." have officially proven to be 
a lie.
> On Wed, Mar 20, 2024 at 7:38 PM Jonathan Wright 
>  wrote:
> DragonflyDB is not an option, they do not use an OSI-approved
> license.  I reached out to them a couple of years ago to see if
> they would swap to one and they said they don't have an interest
> in it.
>
> On Wed, Mar 20, 2024 at 7:13 PM Aaron Rainbolt
> <[e-mail]> wrote:
>
>     On 3/20/24 17:19, 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
> >     Fedora.
> >
> >     All I can say is... :(
> >
> >     [1]:https://redis.com/blog/redis-adopts-dual-source-available-licensing/
>     In addition to KeyDB, there's also DragonflyDB:
>     https://github.com/dragonflydb/dragonfly I mentioned Redis
>     going source-available to the KDE devs and one of them linked
>     this.
>
>     -- 
>     Aaron Rainbolt
>     Lubuntu Developer
>     Matrix: @arraybolt3:matrix.org  <http://matrix.org>
>     IRC: arraybolt3 on irc.libera.chat
>     GitHub:https://github.com/ArrayBolt3
>
>     --
>     _______________________________________________
>     devel mailing list -- [e-mail]
>     To unsubscribe send an email to
>     [e-mail]
>     Fedora Code of Conduct:
>     https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>     List Guidelines:
>     https://fedoraproject.org/wiki/Mailing_list_guidelines
>     List Archives:
>     https://lists.fedoraproject.org/archives/list/[e-mail]
>     Do not reply to spam, report it:
>     https://pagure.io/fedora-infrastructure/new_issue
>
>
>
> -- 
> Jonathan Wright
> AlmaLinux Foundation
> Mattermost: chat
> <https://chat.almalinux.org/almalinux/messages/@jonathan>
>
>
>
> -- 
> Jonathan Wright
> AlmaLinux Foundation
> Mattermost: chat https://chat.almalinux.org/almalinux/messages/@jonathan
>
> --
> _______________________________________________
> devel mailing list [e-mail]
> To unsubscribe send an email [e-mail]
> Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue

[Richard Fontana]

On Wed, Mar 20, 2024 at 6:21 PM Neal Gompa  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
> Fedora.

This is quite unfortunate.

We haven't encountered RSAL(v2) before in Fedora AFAIK but I've just
reviewed it and concluded (easily) it should be classified it as
*not-allowed*.
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/497

SSPL of course is already classified as *not-allowed*.

Richard

[Kevin Kofler]

Neal Gompa 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
> Fedora.
>
> All I can say is... :(

Can Microsoft Garnet be a solution?
https://www.microsoft.com/en-us/research/blog/introducing-garnet-an-open-sou...
https://microsoft.github.io/garnet/
https://github.com/microsoft/garnet/tree/main

Released under the MIT license (since 2 days ago) and claims that "Garnet 
can work with existing Redis clients." And the benchmark results they post 
outperforms all 3 of Redis (soon to become proprietary), KeyDB, and 
DragonflyDB (already proprietary from the outstart).

Kevin Kofler

[Kevin Kofler]

Kevin Kofler via devel wrote:
> Can Microsoft Garnet be a solution?
> https://www.microsoft.com/en-us/research/blog/introducing-garnet-an-open-sou...
> https://microsoft.github.io/garnet/
> https://github.com/microsoft/garnet/tree/main
>
> Released under the MIT license (since 2 days ago) and claims that "Garnet
> can work with existing Redis clients." And the benchmark results they post
> outperforms all 3 of Redis (soon to become proprietary), KeyDB, and
> DragonflyDB (already proprietary from the outstart).

Though, Microsoft being Microsoft, they wrote that thing in C#, so it drags 
in the dotnet stack. But at least they did test on GNU/Linux:
https://microsoft.github.io/garnet/docs/getting-started#build-the-project
"You can use either Linux or Windows; Garnet works equally well on both 
platforms."

Kevin Kofler

[Jonathan Wright]

While it may not end up as the right solution to replace Redis, here's the
review for KeyDB:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2270592

On Wed, Mar 20, 2024 at 9:49 PM Kevin Kofler via devel <
[e-mail]> wrote:
> Kevin Kofler via devel wrote:
> > Can Microsoft Garnet be a solution?
>
> https://www.microsoft.com/en-us/research/blog/introducing-garnet-an-open-sou...
> > https://microsoft.github.io/garnet/
> > https://github.com/microsoft/garnet/tree/main
> >
> > Released under the MIT license (since 2 days ago) and claims that "Garnet
> > can work with existing Redis clients." And the benchmark results they
>
> post
> > outperforms all 3 of Redis (soon to become proprietary), KeyDB, and
> > DragonflyDB (already proprietary from the outstart).
>
> Though, Microsoft being Microsoft, they wrote that thing in C#, so it
> drags
> in the dotnet stack. But at least they did test on GNU/Linux:
> https://microsoft.github.io/garnet/docs/getting-started#build-the-project
> "You can use either Linux or Windows; Garnet works equally well on both
> platforms."
>     Kevin Kofler
>
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Scott Williams]

Yeah, I was going to say it depends on the dotnet8 runtime.  There are containers for it, but that's a lot of extra dependency load.  Otherwise, it would be viable.

[Kevin Kofler]

Scott Williams wrote:
> Yeah, I was going to say it depends on the dotnet8 runtime.  There are
> containers for it, but that's a lot of extra dependency load.

It is actually already packaged in Fedora:
https://src.fedoraproject.org/rpms/dotnet8.0

But yes, it is bloat.

Kevin Kofler

[Richard W.M. Jones]

On Wed, Mar 20, 2024 at 06:19:28PM -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
> Fedora.
>
> All I can say is... :(

Another alternative is that someone in the community might fork it.
Can we stick with the last free version for a few months to see how
the pieces fall?

Rich.

[Markku Korkeala]

On Thu, Mar 21, 2024 at 08:29:09AM +0000, Richard W.M. Jones wrote:
> On Wed, Mar 20, 2024 at 06:19:28PM -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
> > Fedora.
> >
> > All I can say is... :(
>
> Another alternative is that someone in the community might fork it.
> Can we stick with the last free version for a few months to see how
> the pieces fall?

Hi all,

just noticed one fork, might be worth keeping eye on:
https://codeberg.org/redict/redict

Best regards,
Markku
> Rich.
>
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-top is 'top' for virtual machines.  Tiny program with many
> powerful monitoring features, net stats, disk stats, logging, etc.
> http://people.redhat.com/~rjones/virt-top
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Mike Rochefort]

On Thu, Mar 21, 2024 at 08:29:09AM +0000, Richard W.M. Jones wrote:
> just noticed one fork, might be worth keeping eye on:
> https://codeberg.org/redict/redict

On the newly launched "Write Free Software" Discourse[0], Drew noted 
that he is creating and leading this fork due to his reliance on Redis 
in his own projects[1].

[0] https://discourse.writefreesoftware.org
[1] https://discourse.writefreesoftware.org/t/redis-switches-to-dual-source-avai...

Cheers,
Mike

[Kevin Kofler]

Neal Gompa 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
> Fedora.
>
> All I can say is... :(

Amazon (AWS) is setting up a BSD-licensed fork, but has not yet decided on 
the final name:
https://github.com/placeholderkv/placeholderkv

We will see whether that or redict will get the most attention. Cloud 
companies like Amazon will probably prefer BSD, whereas contributors worried 
about another "Redis, Inc." coming up and taking their forked code 
proprietary too will most likely prefer the LGPL fork (redict) (unless they 
are unhappy about the use of version 3.0 only of the LGPL by that fork).

Kevin Kofler

[Gary Buhrmaster]

On Sat, Mar 23, 2024 at 3:22 AM Kevin Kofler via devel
 wrote:
> We will see whether that or redict will get the most attention. Cloud
> companies like Amazon will probably prefer BSD, whereas contributors worried
> about another "Redis, Inc." coming up and taking their forked code
> proprietary too will most likely prefer the LGPL fork (redict) (unless they
> are unhappy about the use of version 3.0 only of the LGPL by that fork).

"It is hard to make predictions, especially about the future",
but it appears that many of the recent non-redis contributors
are cloud company entangled (and were previously willing to
contribute under the BSD-3-Clause license).

[Jonathan Wright]

KeyDB builds are in Bodhi and ready for testing for all Fedora versions +
EPEL8/9.

https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2

I'm still keeping an eye on, and chatting with the creators of the other
two, redict and the unnamed one from an AWS employee and will package them
when they have official builds.

In the meantime I'd welcome any testing on the KeyDB packages in Bodhi.

On Fri, Mar 22, 2024 at 11:10 PM Gary Buhrmaster 
wrote:
> On Sat, Mar 23, 2024 at 3:22 AM Kevin Kofler via devel
>  wrote:
> > We will see whether that or redict will get the most attention. Cloud
> > companies like Amazon will probably prefer BSD, whereas contributors
>
> worried
> > about another "Redis, Inc." coming up and taking their forked code
> > proprietary too will most likely prefer the LGPL fork (redict) (unless
>
> they
> > are unhappy about the use of version 3.0 only of the LGPL by that fork).
>
> "It is hard to make predictions, especially about the future",
> but it appears that many of the recent non-redis contributors
> are cloud company entangled (and were previously willing to
> contribute under the BSD-3-Clause license).
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Carlos Rodriguez-Fernandez]

Valkey is another fork, sponsored by the Linux Foundation.

https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-...

It came out just today.

On 3/23/24 11:35, Jonathan Wright via devel wrote:
> KeyDB builds are in Bodhi and ready for testing for all Fedora versions
> EPEL8/9.
>
> https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2 
> https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2
>
> I'm still keeping an eye on, and chatting with the creators of the other 
> two, redict and the unnamed one from an AWS employee and will package 
> them when they have official builds.
>
> In the meantime I'd welcome any testing on the KeyDB packages in Bodhi.
>
> On Fri, Mar 22, 2024 at 11:10 PM Gary Buhrmaster 
> <[e-mail] > wrote:
> On Sat, Mar 23, 2024 at 3:22 AM Kevin Kofler via devel
> <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>  > We will see whether that or redict will get the most attention. Cloud
>  > companies like Amazon will probably prefer BSD, whereas
> contributors worried
>  > about another "Redis, Inc." coming up and taking their forked code
>  > proprietary too will most likely prefer the LGPL fork (redict)
> (unless they
>  > are unhappy about the use of version 3.0 only of the LGPL by that
> fork).
>
> "It is hard to make predictions, especially about the future",
> but it appears that many of the recent non-redis contributors
> are cloud company entangled (and were previously willing to
> contribute under the BSD-3-Clause license).
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail]
> <mailto:[e-mail]>
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> <https://fedoraproject.org/wiki/Mailing_list_guidelines>
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail] <https://lists.fedoraproject.org/archives/list/[e-mail]>
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
> <https://pagure.io/fedora-infrastructure/new_issue>
>
>
>
> -- 
> Jonathan Wright
> AlmaLinux Foundation
> Mattermost: chat https://chat.almalinux.org/almalinux/messages/@jonathan
>
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Jonathan Wright]

This is the one previously known as "PlaceHolderKV".

I forgot to mention but redict is packaged and ready for testing in Bodhi:
https://bodhi.fedoraproject.org/updates/?search=redict-7.3.0~rc

I'll be packing up valkey as soon as they have a tagged release.

After following redict and valkey closely for the past week or so I'm
anticipating valkey becoming the defacto replacement for redis in most
places.

On Thu, Mar 28, 2024 at 1:09 PM Carlos Rodriguez-Fernandez <
[e-mail]> wrote:
> Valkey is another fork, sponsored by the Linux Foundation.
>
> https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-...
>
> It came out just today.
>
> On 3/23/24 11:35, Jonathan Wright via devel wrote:
> > KeyDB builds are in Bodhi and ready for testing for all Fedora versions
> > EPEL8/9.
> >
> > https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2
> > https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2
> >
> > I'm still keeping an eye on, and chatting with the creators of the other
> > two, redict and the unnamed one from an AWS employee and will package
> > them when they have official builds.
> >
> > In the meantime I'd welcome any testing on the KeyDB packages in Bodhi.
> >
> > On Fri, Mar 22, 2024 at 11:10 PM Gary Buhrmaster
> > <[e-mail] > wrote:
> > On Sat, Mar 23, 2024 at 3:22 AM Kevin Kofler via devel
> > <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >  > We will see whether that or redict will get the most attention.
>
> Cloud
> >  > companies like Amazon will probably prefer BSD, whereas
> > contributors worried
> >  > about another "Redis, Inc." coming up and taking their forked code
> >  > proprietary too will most likely prefer the LGPL fork (redict)
> > (unless they
> >  > are unhappy about the use of version 3.0 only of the LGPL by that
> > fork).
> >
> > "It is hard to make predictions, especially about the future",
> > but it appears that many of the recent non-redis contributors
> > are cloud company entangled (and were previously willing to
> > contribute under the BSD-3-Clause license).
> > --
> > _______________________________________________
> > devel mailing list -- [e-mail]
> > <mailto:[e-mail]>
> > To unsubscribe send an email to [e-mail]
> > <mailto:[e-mail]>
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > <https://fedoraproject.org/wiki/Mailing_list_guidelines>
> > List Archives:
>
> https://lists.fedoraproject.org/archives/list/[e-mail]
> <
> https://lists.fedoraproject.org/archives/list/[e-mail]
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> > <https://pagure.io/fedora-infrastructure/new_issue>
> >
> >
> >
> > --
> > Jonathan Wright
> > AlmaLinux Foundation
> > Mattermost: chat <
>
> https://chat.almalinux.org/almalinux/messages/@jonathan%3E
> > --
> > _______________________________________________
> > devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct:
>
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
>
> https://lists.fedoraproject.org/archives/list/[e-mail]
> > Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Carlos Rodriguez-Fernandez]

So, valkey is then the one the AWS employee did.

Thank you Jonathan for the work on this.

On 3/28/24 11:13, Jonathan Wright via devel wrote:
> This is the one previously known as "PlaceHolderKV".
>
> I forgot to mention but redict is packaged and ready for testing in 
> Bodhi: https://bodhi.fedoraproject.org/updates/?search=redict-7.3.0~rc 
> https://bodhi.fedoraproject.org/updates/?search=redict-7.3.0~rc
>
> I'll be packing up valkey as soon as they have a tagged release.
>
> After following redict and valkey closely for the past week or so I'm 
> anticipating valkey becoming the defacto replacement for redis in most 
> places.
>
> On Thu, Mar 28, 2024 at 1:09 PM Carlos Rodriguez-Fernandez 
> <[e-mail] > 
> wrote:
> Valkey is another fork, sponsored by the Linux Foundation.
>
> https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community <https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community>
>
> It came out just today.
>
> On 3/23/24 11:35, Jonathan Wright via devel wrote:
>  > KeyDB builds are in Bodhi and ready for testing for all Fedora
> versions
>  > + EPEL8/9.
>  >
>  > https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2
> <https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2>
>  > <https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2
> <https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2>>
>  >
>  > I'm still keeping an eye on, and chatting with the creators of
> the other
>  > two, redict and the unnamed one from an AWS employee and will
> package
>  > them when they have official builds.
>  >
>  > In the meantime I'd welcome any testing on the KeyDB packages in
> Bodhi.
>  >
>  > On Fri, Mar 22, 2024 at 11:10 PM Gary Buhrmaster
>  > <[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail]
> <mailto:[e-mail]>>> wrote:
>  >
>  >     On Sat, Mar 23, 2024 at 3:22 AM Kevin Kofler via devel
>  >     <[e-mail]
> <mailto:[e-mail]>
>  >     <mailto:[e-mail]
> <mailto:[e-mail]>>> wrote:
>  >
>  >      > We will see whether that or redict will get the most
> attention. Cloud
>  >      > companies like Amazon will probably prefer BSD, whereas
>  >     contributors worried
>  >      > about another "Redis, Inc." coming up and taking their
> forked code
>  >      > proprietary too will most likely prefer the LGPL fork (redict)
>  >     (unless they
>  >      > are unhappy about the use of version 3.0 only of the LGPL
> by that
>  >     fork).
>  >
>  >     "It is hard to make predictions, especially about the future",
>  >     but it appears that many of the recent non-redis contributors
>  >     are cloud company entangled (and were previously willing to
>  >     contribute under the BSD-3-Clause license).
>  >     --
>  >     _______________________________________________
>  >     devel mailing list -- [e-mail]
> <mailto:[e-mail]>
>  >     <mailto:[e-mail]
> <mailto:[e-mail]>>
>  >     To unsubscribe send an email to
> [e-mail]
> <mailto:[e-mail]>
>  >     <mailto:[e-mail]
> <mailto:[e-mail]>>
>  >     Fedora Code of Conduct:
>  > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
>  >   
>   <https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>>
>  >     List Guidelines:
>  > https://fedoraproject.org/wiki/Mailing_list_guidelines
> <https://fedoraproject.org/wiki/Mailing_list_guidelines>
>  >     <https://fedoraproject.org/wiki/Mailing_list_guidelines
> <https://fedoraproject.org/wiki/Mailing_list_guidelines>>
>  >     List Archives:
>  >
> https://lists.fedoraproject.org/archives/list/[e-mail] <https://lists.fedoraproject.org/archives/list/[e-mail]> <https://lists.fedoraproject.org/archives/list/[e-mail] <https://lists.fedoraproject.org/archives/list/[e-mail]>>
>  >     Do not reply to spam, report it:
>  > https://pagure.io/fedora-infrastructure/new_issue
> <https://pagure.io/fedora-infrastructure/new_issue>
>  >     <https://pagure.io/fedora-infrastructure/new_issue
> <https://pagure.io/fedora-infrastructure/new_issue>>
>  >
>  >
>  >
>  > --
>  > Jonathan Wright
>  > AlmaLinux Foundation
>  > Mattermost: chat
> <https://chat.almalinux.org/almalinux/messages/@jonathan
> <https://chat.almalinux.org/almalinux/messages/@jonathan>>
>  >
>  > --
>  > _______________________________________________
>  > devel mailing list -- [e-mail]
> <mailto:[e-mail]>
>  > To unsubscribe send an email to
> [e-mail]
> <mailto:[e-mail]>
>  > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
>  > List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> <https://fedoraproject.org/wiki/Mailing_list_guidelines>
>  > List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail] <https://lists.fedoraproject.org/archives/list/[e-mail]>
>  > Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
> <https://pagure.io/fedora-infrastructure/new_issue>
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail]
> <mailto:[e-mail]>
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> <https://fedoraproject.org/wiki/Mailing_list_guidelines>
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail] <https://lists.fedoraproject.org/archives/list/[e-mail]>
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
> <https://pagure.io/fedora-infrastructure/new_issue>
>
>
>
> -- 
> Jonathan Wright
> AlmaLinux Foundation
> Mattermost: chat https://chat.almalinux.org/almalinux/messages/@jonathan
>
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Jonathan Wright]

Valkey 7.2.4 rc1 was released earlier today.  Package review opened at
https://bugzilla.redhat.com/show_bug.cgi?id=2274206 which Neal Gompa has
taken.

Will update again when packages are in Bodhi testing.

On Thu, Mar 28, 2024 at 1:41 PM Carlos Rodriguez-Fernandez <
[e-mail]> wrote:
> So, valkey is then the one the AWS employee did.
>
> Thank you Jonathan for the work on this.
>
> On 3/28/24 11:13, Jonathan Wright via devel wrote:
> > This is the one previously known as "PlaceHolderKV".
> >
> > I forgot to mention but redict is packaged and ready for testing in
> > Bodhi: https://bodhi.fedoraproject.org/updates/?search=redict-7.3.0~rc
> > https://bodhi.fedoraproject.org/updates/?search=redict-7.3.0~rc
> >
> > I'll be packing up valkey as soon as they have a tagged release.
> >
> > After following redict and valkey closely for the past week or so I'm
> > anticipating valkey becoming the defacto replacement for redis in most
> > places.
> >
> > On Thu, Mar 28, 2024 at 1:09 PM Carlos Rodriguez-Fernandez
> > <[e-mail] >
> > wrote:
> > Valkey is another fork, sponsored by the Linux Foundation.
>
> https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-...
> <
> https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-...
> > It came out just today.
> >
> > On 3/23/24 11:35, Jonathan Wright via devel wrote:
> >  > KeyDB builds are in Bodhi and ready for testing for all Fedora
> > versions
> >  > + EPEL8/9.
> >  >
> >  > https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2
> > <https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2>
> >  > <https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2
> > <https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2>>
> >  >
> >  > I'm still keeping an eye on, and chatting with the creators of
> > the other
> >  > two, redict and the unnamed one from an AWS employee and will
> > package
> >  > them when they have official builds.
> >  >
> >  > In the meantime I'd welcome any testing on the KeyDB packages in
> > Bodhi.
> >  >
> >  > On Fri, Mar 22, 2024 at 11:10 PM Gary Buhrmaster
> >  > <[e-mail] <mailto:[e-mail]>
> > <mailto:[e-mail]
> > <mailto:[e-mail]>>> wrote:
> >  >
> >  >     On Sat, Mar 23, 2024 at 3:22 AM Kevin Kofler via devel
> >  >     <[e-mail]
> > <mailto:[e-mail]>
> >  >     <mailto:[e-mail]
> > <mailto:[e-mail]>>> wrote:
> >  >
> >  >      > We will see whether that or redict will get the most
> > attention. Cloud
> >  >      > companies like Amazon will probably prefer BSD, whereas
> >  >     contributors worried
> >  >      > about another "Redis, Inc." coming up and taking their
> > forked code
> >  >      > proprietary too will most likely prefer the LGPL fork
>
> (redict)
> >  >     (unless they
> >  >      > are unhappy about the use of version 3.0 only of the LGPL
> > by that
> >  >     fork).
> >  >
> >  >     "It is hard to make predictions, especially about the future",
> >  >     but it appears that many of the recent non-redis contributors
> >  >     are cloud company entangled (and were previously willing to
> >  >     contribute under the BSD-3-Clause license).
> >  >     --
> >  >     _______________________________________________
> >  >     devel mailing list -- [e-mail]
> > <mailto:[e-mail]>
> >  >     <mailto:[e-mail]
> > <mailto:[e-mail]>>
> >  >     To unsubscribe send an email to
> > [e-mail]
> > <mailto:[e-mail]>
> >  >     <mailto:[e-mail]
> > <mailto:[e-mail]>>
> >  >     Fedora Code of Conduct:
> >  > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> >  >
> >   <https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>>
> >  >     List Guidelines:
> >  > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > <https://fedoraproject.org/wiki/Mailing_list_guidelines>
> >  >     <https://fedoraproject.org/wiki/Mailing_list_guidelines
> > <https://fedoraproject.org/wiki/Mailing_list_guidelines>>
> >  >     List Archives:
> >  >
>
> https://lists.fedoraproject.org/archives/list/[e-mail]
> <
> https://lists.fedoraproject.org/archives/list/[e-mail]%...
> <
> https://lists.fedoraproject.org/archives/list/[e-mail]
> <
> https://lists.fedoraproject.org/archives/list/[e-mail]
> > >
> >  >     Do not reply to spam, report it:
> >  > https://pagure.io/fedora-infrastructure/new_issue
> > <https://pagure.io/fedora-infrastructure/new_issue>
> >  >     <https://pagure.io/fedora-infrastructure/new_issue
> > <https://pagure.io/fedora-infrastructure/new_issue>>
> >  >
> >  >
> >  >
> >  > --
> >  > Jonathan Wright
> >  > AlmaLinux Foundation
> >  > Mattermost: chat
> > <https://chat.almalinux.org/almalinux/messages/@jonathan
> > <https://chat.almalinux.org/almalinux/messages/@jonathan>>
> >  >
> >  > --
> >  > _______________________________________________
> >  > devel mailing list -- [e-mail]
> > <mailto:[e-mail]>
> >  > To unsubscribe send an email to
> > [e-mail]
> > <mailto:[e-mail]>
> >  > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> >  > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > <https://fedoraproject.org/wiki/Mailing_list_guidelines>
> >  > List Archives:
>
> https://lists.fedoraproject.org/archives/list/[e-mail]
> <
> https://lists.fedoraproject.org/archives/list/[e-mail]
> >  > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> > <https://pagure.io/fedora-infrastructure/new_issue>
> > --
> > _______________________________________________
> > devel mailing list -- [e-mail]
> > <mailto:[e-mail]>
> > To unsubscribe send an email to [e-mail]
> > <mailto:[e-mail]>
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > <https://fedoraproject.org/wiki/Mailing_list_guidelines>
> > List Archives:
>
> https://lists.fedoraproject.org/archives/list/[e-mail]
> <
> https://lists.fedoraproject.org/archives/list/[e-mail]
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> > <https://pagure.io/fedora-infrastructure/new_issue>
> >
> >
> >
> > --
> > Jonathan Wright
> > AlmaLinux Foundation
> > Mattermost: chat <
>
> https://chat.almalinux.org/almalinux/messages/@jonathan%3E
> > --
> > _______________________________________________
> > devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct:
>
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
>
> https://lists.fedoraproject.org/archives/list/[e-mail]
> > Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Jonathan Wright]

Valley 7.2.5 stable was released yesterday.  Builds are in Bodhi and ready
for testing/feedback.

https://bodhi.fedoraproject.org/updates/?search=valkey-7.2.5-1

On Tue, Apr 9, 2024 at 12:54 PM Jonathan Wright 
wrote:
> Valkey 7.2.4 rc1 was released earlier today.  Package review opened at
> https://bugzilla.redhat.com/show_bug.cgi?id=2274206 which Neal Gompa has
> taken.
>
> Will update again when packages are in Bodhi testing.
>
> On Thu, Mar 28, 2024 at 1:41 PM Carlos Rodriguez-Fernandez <
> [e-mail]> wrote:
> > So, valkey is then the one the AWS employee did.
> >
> > Thank you Jonathan for the work on this.
> >
> > On 3/28/24 11:13, Jonathan Wright via devel wrote:
> > > This is the one previously known as "PlaceHolderKV".
> > >
> > > I forgot to mention but redict is packaged and ready for testing in
> > > Bodhi: https://bodhi.fedoraproject.org/updates/?search=redict-7.3.0~rc
> > > https://bodhi.fedoraproject.org/updates/?search=redict-7.3.0~rc
> > >
> > > I'll be packing up valkey as soon as they have a tagged release.
> > >
> > > After following redict and valkey closely for the past week or so I'm
> > > anticipating valkey becoming the defacto replacement for redis in most
> > > places.
> > >
> > > On Thu, Mar 28, 2024 at 1:09 PM Carlos Rodriguez-Fernandez
> > > <[e-mail] >
> > > wrote:
> > > Valkey is another fork, sponsored by the Linux Foundation.
> >
> > https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-...
> > <
> > https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-...
> > > It came out just today.
> > >
> > > On 3/23/24 11:35, Jonathan Wright via devel wrote:
> > >  > KeyDB builds are in Bodhi and ready for testing for all Fedora
> > > versions
> > >  > + EPEL8/9.
> > >  >
> > >  > https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2
> > > <https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2>
> > >  > <https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2
> > > <https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2>>
> > >  >
> > >  > I'm still keeping an eye on, and chatting with the creators of
> > > the other
> > >  > two, redict and the unnamed one from an AWS employee and will
> > > package
> > >  > them when they have official builds.
> > >  >
> > >  > In the meantime I'd welcome any testing on the KeyDB packages in
> > > Bodhi.
> > >  >
> > >  > On Fri, Mar 22, 2024 at 11:10 PM Gary Buhrmaster
> > >  > <[e-mail] <mailto:[e-mail]>
> > > <mailto:[e-mail]
> > > <mailto:[e-mail]>>> wrote:
> > >  >
> > >  >     On Sat, Mar 23, 2024 at 3:22 AM Kevin Kofler via devel
> > >  >     <[e-mail]
> > > <mailto:[e-mail]>
> > >  >     <mailto:[e-mail]
> > > <mailto:[e-mail]>>> wrote:
> > >  >
> > >  >      > We will see whether that or redict will get the most
> > > attention. Cloud
> > >  >      > companies like Amazon will probably prefer BSD, whereas
> > >  >     contributors worried
> > >  >      > about another "Redis, Inc." coming up and taking their
> > > forked code
> > >  >      > proprietary too will most likely prefer the LGPL fork
> >
> > (redict)
> > >  >     (unless they
> > >  >      > are unhappy about the use of version 3.0 only of the LGPL
> > > by that
> > >  >     fork).
> > >  >
> > >  >     "It is hard to make predictions, especially about the
> >
> > future",
> > >  >     but it appears that many of the recent non-redis contributors
> > >  >     are cloud company entangled (and were previously willing to
> > >  >     contribute under the BSD-3-Clause license).
> > >  >     --
> > >  >     _______________________________________________
> > >  >     devel mailing list -- [e-mail]
> > > <mailto:[e-mail]>
> > >  >     <mailto:[e-mail]
> > > <mailto:[e-mail]>>
> > >  >     To unsubscribe send an email to
> > > [e-mail]
> > > <mailto:[e-mail]>
> > >  >     <mailto:[e-mail]
> > > <mailto:[e-mail]>>
> > >  >     Fedora Code of Conduct:
> > >  > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> > >  >
> > >   <https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>>
> > >  >     List Guidelines:
> > >  > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > <https://fedoraproject.org/wiki/Mailing_list_guidelines>
> > >  >     <https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > <https://fedoraproject.org/wiki/Mailing_list_guidelines>>
> > >  >     List Archives:
> > >  >
> >
> > https://lists.fedoraproject.org/archives/list/[e-mail]
> > <
> > https://lists.fedoraproject.org/archives/list/[e-mail]%...
> > <
> > https://lists.fedoraproject.org/archives/list/[e-mail]
> > <
> > https://lists.fedoraproject.org/archives/list/[e-mail]
> > > >
> > >  >     Do not reply to spam, report it:
> > >  > https://pagure.io/fedora-infrastructure/new_issue
> > > <https://pagure.io/fedora-infrastructure/new_issue>
> > >  >     <https://pagure.io/fedora-infrastructure/new_issue
> > > <https://pagure.io/fedora-infrastructure/new_issue>>
> > >  >
> > >  >
> > >  >
> > >  > --
> > >  > Jonathan Wright
> > >  > AlmaLinux Foundation
> > >  > Mattermost: chat
> > > <https://chat.almalinux.org/almalinux/messages/@jonathan
> > > <https://chat.almalinux.org/almalinux/messages/@jonathan>>
> > >  >
> > >  > --
> > >  > _______________________________________________
> > >  > devel mailing list -- [e-mail]
> > > <mailto:[e-mail]>
> > >  > To unsubscribe send an email to
> > > [e-mail]
> > > <mailto:[e-mail]>
> > >  > Fedora Code of Conduct:
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> > >  > List Guidelines:
> > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > <https://fedoraproject.org/wiki/Mailing_list_guidelines>
> > >  > List Archives:
> >
> > https://lists.fedoraproject.org/archives/list/[e-mail]
> > <
> > https://lists.fedoraproject.org/archives/list/[e-mail]
> > >  > Do not reply to spam, report it:
> > > https://pagure.io/fedora-infrastructure/new_issue
> > > <https://pagure.io/fedora-infrastructure/new_issue>
> > > --
> > > _______________________________________________
> > > devel mailing list -- [e-mail]
> > > <mailto:[e-mail]>
> > > To unsubscribe send an email to [e-mail]
> > > <mailto:[e-mail]>
> > > Fedora Code of Conduct:
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> > > List Guidelines:
> > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > <https://fedoraproject.org/wiki/Mailing_list_guidelines>
> > > List Archives:
> >
> > https://lists.fedoraproject.org/archives/list/[e-mail]
> > <
> > https://lists.fedoraproject.org/archives/list/[e-mail]
> > > Do not reply to spam, report it:
> > > https://pagure.io/fedora-infrastructure/new_issue
> > > <https://pagure.io/fedora-infrastructure/new_issue>
> > >
> > >
> > >
> > > --
> > > Jonathan Wright
> > > AlmaLinux Foundation
> > > Mattermost: chat <
> >
> > https://chat.almalinux.org/almalinux/messages/@jonathan%3E
> > > --
> > > _______________________________________________
> > > devel mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > Fedora Code of Conduct:
> >
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> >
> > https://lists.fedoraproject.org/archives/list/[e-mail]
> > > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> >
> > devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/[e-mail]
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
>
> --
> Jonathan Wright
> AlmaLinux Foundation
> Mattermost: chat https://chat.almalinux.org/almalinux/messages/@jonathan

[Leon Fauster]

Am 17.04.24 um 15:59 schrieb Jonathan Wright via devel:
> Valley 7.2.5 stable was released yesterday.  Builds are in Bodhi and 
> ready for testing/feedback.
>
> https://bodhi.fedoraproject.org/updates/?search=valkey-7.2.5-1 
> https://bodhi.fedoraproject.org/updates/?search=valkey-7.2.5-1

Thanks for the work on it. I wonder why valkey conflicts with redis,
redict for instance does not!? Is this a decision for a preferred
upgrade path? What about leaving this decision to the user (keydb, 
redict, valkey, redis on RHEL, etc) and allowing parallel installation
for testing, decision making processes and migration.

[Jonathan Wright]

On Wed, Apr 17, 2024 at 9:43 AM Leon Fauster via devel <
[e-mail]> wrote:
> Am 17.04.24 um 15:59 schrieb Jonathan Wright via devel:
> > Valley 7.2.5 stable was released yesterday.  Builds are in Bodhi and
> > ready for testing/feedback.
> >
> > https://bodhi.fedoraproject.org/updates/?search=valkey-7.2.5-1
> > https://bodhi.fedoraproject.org/updates/?search=valkey-7.2.5-1
>
> Thanks for the work on it. I wonder why valkey conflicts with redis,
> redict for instance does not!? Is this a decision for a preferred
> upgrade path? What about leaving this decision to the user (keydb,
> redict, valkey, redis on RHEL, etc) and allowing parallel installation
> for testing, decision making processes and migration.

It is due to redict renaming some libs, while valkey has opted to retain
"redis" on some lib file names.
> --
> Leon
>
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Leon Fauster]

Am 17.04.24 um 16:44 schrieb Jonathan Wright:
> On Wed, Apr 17, 2024 at 9:43 AM Leon Fauster via devel 
> <[e-mail] > 
> wrote:
> Am 17.04.24 um 15:59 schrieb Jonathan Wright via devel:
>  > Valley 7.2.5 stable was released yesterday.  Builds are in Bodhi and
>  > ready for testing/feedback.
>  >
>  > https://bodhi.fedoraproject.org/updates/?search=valkey-7.2.5-1
> <https://bodhi.fedoraproject.org/updates/?search=valkey-7.2.5-1>
>  > <https://bodhi.fedoraproject.org/updates/?search=valkey-7.2.5-1
> <https://bodhi.fedoraproject.org/updates/?search=valkey-7.2.5-1>>
>  >
>
> Thanks for the work on it. I wonder why valkey conflicts with redis,
> redict for instance does not!? Is this a decision for a preferred
> upgrade path? What about leaving this decision to the user (keydb,
> redict, valkey, redis on RHEL, etc) and allowing parallel installation
> for testing, decision making processes and migration.
>
>
> It is due to redict renaming some libs, while valkey has opted to retain 
> "redis" on some lib file names.

It seems to be just links in the bin directory that overlaps (and not 
libs). Why not putting these links into the compat subpackage including
also the conflict statement. That would allow to install the main 
package side-by-side to the other key-value-db forks.

[Nathan Scott]

On Thu, Apr 18, 2024 at 1:05 AM Leon Fauster via devel
 wrote:
> > Thanks for the work on it. I wonder why valkey conflicts with redis,
> > redict for instance does not!? Is this a decision for a preferred
> > upgrade path? What about leaving this decision to the user (keydb,
> > redict, valkey, redis on RHEL, etc) and allowing parallel installation
> > for testing, decision making processes and migration.
> >
> >
> > It is due to redict renaming some libs, while valkey has opted to retain
> > "redis" on some lib file names.

# rpm -ql redis | grep lib | grep -v build-id
/usr/lib/systemd/system/redis-sentinel.service
/usr/lib/systemd/system/redis.service
/usr/lib64/redis
/usr/lib64/redis/modules
/var/lib/redis

There aren't any lib files in either valkey or redis, and none of the
directories listed above are in conflict between the two packages.

I notice also a Conflict between valkey-devel and redis-devel has
been added, and as much as I appreciate the sentiment (we're all
disappointed with what has happened), I can't see justification for
that either.
> It seems to be just links in the bin directory that overlaps (and not
> libs). Why not putting these links into the compat subpackage including
> also the conflict statement. That would allow to install the main
> package side-by-side to the other key-value-db forks.

+1

https://src.fedoraproject.org/rpms/valkey/pull-request/2

cheers.

--
Nathan