Investigate Offering OSS alternatives to Redis in Gitea Installation

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD

https://gitea.com

MIT License

45.43k stars 5.52k forks source link

Investigate Offering OSS alternatives to Redis in Gitea Installation #32056

Open rmathagiarun opened 2 months ago

rmathagiarun commented 2 months ago

Feature Description

Summary

The Redis License is changing from BSD-3-Clause to RSALv2 and SSPLv1 which are not open source under the OSI definition. We should consider open-source alternatives as a default replacement for Redis.

Proposal

We have a potential drop-in replacement for Redis that would still maintain compatibility with the Redis API.

Valkey

Valkey is a CNCF fork of existing Redis BSD-3-Clause meant to be a drop in replacement that will maintain compatibility.

Screenshots

No response

techknowlogick commented 2 months ago

Thanks for this ticket. What do you see as the next steps for this ticket? Other than the bitnami redis in the helm-chart, I'm not sure that we "provide" redis. Do you mean change our tests to test against valkey instead, or something else entirely?

As a general note, we do make attempts to ensure we only distribute OSS, so if we are accidentally missing it in some area we'd love to resolve that.

rmathagiarun commented 2 months ago

Yes, it will be good to provide support alternatively to valkey.

We found the following matches for "redis" in go.mod:

github.com/redis/go-redis/v9 v9.6.0

And there are references for redis at many places in the code base.

We observed that Valkey has a separate go client - https://github.com/valkey-io/valkey-go?tab=readme-ov-file#features Does it mean that the move to Valkey might require changes in Gitea to use a different client.

lunny commented 2 months ago

Yes, it will be good to provide support alternatively to valkey.

We found the following matches for "redis" in go.mod:

github.com/redis/go-redis/v9 v9.6.0

And there are references for redis at many places in the code base.

We observed that Valkey has a separate go client - https://github.com/valkey-io/valkey-go?tab=readme-ov-file#features Does it mean that the move to Valkey might require changes in Gitea to use a different client.

Even if Redis changed its license, github.com/redis/go-redis/v9 was published under BSD-2. If valkey is compatible with the protocol of Redis. I think there is no motivation to change the library at the moment. Users could choose to use valkey instead of redis and it should work without Gitea's change.

linghengqian commented 2 months ago

Obviously Redis Stack was never OSS, but Redis Client is still OSS. If the Redis protocol compatible server is only in unit tests, then maybe we can add some unit tests for https://kvrocks.apache.org/ ? Apache kvrocks is a distributed key-value NoSQL database compatible with the Redis protocol.
To be honest I'm not sure if a MIT LICENSE gitea product that wraps an Apache-2.0 LICENSE kvrocks product will still be MIT LICENSE.

mkoskl commented 2 months ago

Does Gitea embed or some other way use Redis? Or is it kind of "opt-in"?

techknowlogick commented 2 months ago

Redis is not embedded at all. The library we use is to communicate with redis (or other services that implement the redis API such as options discussed above).

I suspect that our helm chart will swap at some point, but I don't think Bitnami distributes closed source software so unless there is a bug or a security vulnerability that comes out about the version of redis in use we don't need to rush it. Of course, if anyone wants to get that low hanging fruit, it'd be extremely appreciated.