Feature request: Replace Redis

[Zepmann]

Context

Docker Mailserver uses Redis. Redis screwed around with their license. Redis was originally licensed exclusively under the BSD-3 license, which is quite compatible with Docker Mailserver's MIT license. However, I believe that their new license is less compatible, and does not align with the values of the community that contributes to DMS.

Description

For the short term I would not change anything, since Redis still works and the way DMS includes Redis relies on standard Debian packages. The currently used Debian version does not offer an alternative yet, I believe. Ideally we will also not use community packages. While I am reluctant to continue to use Redis due to the questionable license (for now a "soft" concern), I am even more reluctant for the risk that stuff breaks (a "hard" concern). :wink:

Valkey is a drop-in replacement for Redis developed and maintained by the Linux Foundation. It uses the BSD-3 license as Redis once used to. I expect that Valkey will be available in the future in Debian's repositories. Once it does, I expect that the pull request to replace Redis with Valkey will be relatively small.

If there would be a roadmap, I would suggest to add this to it. Otherwise, is it an idea to keep this issue open?

Alternatives

• Keep using Redis. I would not recommend this. Many open source projects are switching to alternatives, which shows that such one-sided license changes are frowned upon.
• There are some other drop-in alternatives to Redis being developed as well. For now I expect Valkey to be the best drop-in replacement in the future since it is backed by the Linux Foundation. It's fine if another replacement is a better fit if my expectation is wrong, of course.

Applicable Users

The entire community, including users and contributors.

Are you going to implement it?

Yes, because I know the probability of someone else doing it is low and I can learn from it.

What are you going to contribute?

If no one else is interested in implementing this, I'll be happy to make an attempt. To keep changes and maintenance to a minimum, I will wait until Debian includes Valkey or another drop-in alternative.

[glime-ai[bot]]

Please note that this response was created using generative AI, leveraging previously available information from the repository. This information may be helpful. However, it is our strong recommendation that you carefully consider the information before blindly applying it.

---

It seems you are concerned about the licensing changes of Redis and are considering alternatives for Docker Mailserver. Currently, Docker Mailserver uses Redis as part of its setup, and the integration relies on standard Debian packages. The recent licensing changes by Redis have raised concerns about compatibility with Docker Mailserver's MIT license.

As you mentioned, Valkey, developed by the Linux Foundation, appears to be a promising alternative due to its BSD-3 license, which aligns more closely with the original Redis license and Docker Mailserver's values. However, Valkey is not yet available in Debian's repositories, which Docker Mailserver relies on for its package management.

Given this situation, your approach to wait until Debian includes Valkey or another suitable drop-in replacement seems prudent. This would minimize the changes required in Docker Mailserver and ensure stability. Keeping the issue open or adding it to a roadmap, as you suggested, could help in tracking this transition and encourage community discussion and contributions.

If you decide to implement this change yourself once a suitable alternative is available in Debian, it would indeed be a valuable contribution to the project. It's also wise to monitor other potential alternatives that might emerge as viable options.

This comment was generated by Glime.

[polarathene]

I'm aware of the recent events, but I'd like to wait for things to settle first.

Either Redis will realize their mistake and address the issue, or a fork will establish itself as the replacement over time. I've seen this back and forth with various other well established projects in the past too, and sometimes within 1-2 years it circles back to the original project.

v14 will upgrade to Debian Bookworm. Perhaps that releases backports repo will get valkey, or you'll need to wait until a future Debian release introduces the packages. We're still waiting on Dovecot upgrade too IIRC, which Dovecot maintainers have been reluctant to push for Bookworm until they make a new release last I checked.

Generally we prefer to minimize the use of community repos to get new packages as they sometimes introduce maintenance burdens (in the past we've had this with Dovecot community builds and plugins/extensions becoming out of sync requiring us to build them ourselves).

---

That said. DMS does support using an external Redis instance AFAIK, so if any changes are needed to adapt that to Valkey or similar, we'd be open to contributions there. That would be the advised approach to using an alternative to Redis for now, while the packaged redis service would be still in our container image, it wouldn't be run which should be acceptable?

[Zepmann]

@polarathene

Either Redis will realize their mistake and address the issue, or a fork will establish itself as the replacement over time. I've seen this back and forth with various other well established projects in the past too, and sometimes within 1-2 years it circles back to the original project.

True. A good approach in the meantime is to not remove support for Redis even if an alternative is available. Just make something like Valkey the default and offer Redis as an (unsupported, so no additional testing needed) alternative.

We're still waiting on Dovecot upgrade too IIRC, which Dovecot maintainers have been reluctant to push for Bookworm until they make a new release last I checked.

Correct. Dovecot's community repo will only host 2.4 for Bookworm. For that 2.4 needs to be released. I haven't seen a date for that yet. In the meantime we need to stick with 2.3 and accept a minor downgrade.

Generally we prefer to minimize the use of community repos to get new packages as they sometimes introduce maintenance burdens

Another problem (unrelated to this issue) is ARM, which is not supported by Dovecot's repositories. The gap between versions will grow larger if Dovecot does not provide ARM packages and if we don't get them from somewhere else. Otherwise just stick with whatever is stable and secure.

That said. DMS does support using an external Redis instance AFAIK, so if any changes are needed to adapt that to Valkey or similar, we'd be open to contributions there. That would be the advised approach to using an alternative to Redis for now, while the packaged redis service would be still in our container image, it wouldn't be run which should be acceptable?

I am aware. As I wrote, it is a "soft" concern for now. Ideally I host my entire mail stack including its dependencies from a single project. Technical stability for mail is very important to me, so a "hard" concern always gets higher priority. That is why I suggest for now to do nothing. I just opened this issue to make it easy to refer to and fix the moment it is convenient.

I do not expect that any changes to DMS are required to use an external instance of Valkey as a drop-in replacement. I agree that this is likely a viable workaround for now, but it does not solve this issue. This issue is not only relevant for a single instance, but for the project and the community as a whole. I think it is important to take a stand against anyone who decides to singlehandedly change the legal and social contract under which the community operates. Today it is Redis, tomorrow it is another dependency.

Now I am not saying that we have to make every upstream dependency soft and easy to replace. However, I do think it pays off to keep track of issues and go with the flow of the community concerning drop-in replacements that exclusively operate under the licenses that we like. 😃

[georglauterbach]

I'm also all for replacing Redis due to their recent "changes"... it's a shame really. I agree with what's been said already, and we will wait a bit. This issue has been marked appropriately already - it won't be closed automatically.

[georglauterbach]

I have personally now made the switch to Valkey for all of my services in my private infrastructure that were using Redis before. I can confidently say that everything works flawlessly and as expected.

My stance: We can go forward with this.

[Zepmann]

I share your opinion, @georglauterbach. However, incorporating support for Valkey in DMS seems to not be worth the trouble at the moment. At the time of writing, Debian and Ubuntu packages are not available through official repositories. At risk of speaking out of turn since I am only a contributor: A guideline for DMS is that community repositories are not used. In order of preference (where a discussion could be had to swap positions 1 and 2, but for Valkey right now it is irrelevant):

1. The original project provides up-to-date Debian stable packages for all architectures that DMS supports. DMS supports amd64 and arm64 as far as I am aware. Valkey does not provide any Debian packages.
2. Debian stable provides packages for all architectures that DMS supports. These will likely be older, but (as the name of the repository implies) stable and supported. Debian currently does not offer Valkey.
3. Community repositories provide up-to-date Debian stable packages for all architectures that DMS supports. There is a community repository for Valkey, but I advise against using this due to problems in the past related to the use of such repositories.

But not all hope is lost! A maintainer of Valkey expects that it will be available through official repositories at some point in the future. See this discussion. While I am very eager to replace Redis with Valkey, I would hate to do a lot of work when a ready-made solution exists in the future. This is especially true for more of a principle issue and not a technical issue, since Redis still works.

To clarify a bit more: yes, we could definitely replace Redis with Valkey right now if needed without relying on Debian packages. One way is to simply grab the build artifacts from this page. Another method is to set up (cross-)build environments. I would consider both of these to be dirty fixes introducing unnecessary complexity and possibly technical debt. It could be done (quickly or nicely) if there was a technical need, but currently I see it as too much effort for too little gain.

[georglauterbach]

I completely agree. What I meant to say was that, in case we need to decide whether we want to do it at all, I'd vote for, not against it :) You are 100% correct @Zepmann, though. No need to change anything yet; it would indeed incur unnecessary load.

I've marked it as "Accepted" in the backlog for now. Implentation has not started, and it will not start before Valkey becomes easily installable.