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

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

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

Am 17.04.24 um 16:44 schrieb Jonathan Wright: On Wed, Apr 17, 2024 at 9:43 AM Leon Fauster via devel mailto:devel@lists.fedoraproject.org>> 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 >

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

On Wed, Apr 17, 2024 at 9:43 AM Leon Fauster via devel < devel@lists.fedoraproject.org> 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. > > > >

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

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 Thanks

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

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 >

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

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 <

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

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:

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

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

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

Valkey is another fork, sponsored by the Linux Foundation. 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email

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

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,

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

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

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

FYI - It looks like there is a redis-7 to keydb-6 path: https://github.com/Snapchat/KeyDB/issues/527#issuecomment-1370606311 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

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

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

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

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

> 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

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

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.

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

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

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

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

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

On Thu, Mar 21, 2024 at 08:29:09AM +, 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

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

On Thu, Mar 21, 2024 at 08:29:09AM +, 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].

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

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 >

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

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 < devel@lists.fedoraproject.org> wrote: > Kevin Kofler via devel wrote: > > Can

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

Kevin Kofler via devel wrote: > Can Microsoft Garnet be a solution? > https://www.microsoft.com/en-us/research/blog/introducing-garnet-an-open-source-next-generation-faster-cache-store-for-accelerating-applications-and-services/ > https://microsoft.github.io/garnet/ >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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