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). 😉

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]

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.