Feature request: Replace Redis about docker-mailserver HOT 4 OPEN

@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. 😃

from docker-mailserver.

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.

from docker-mailserver.

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?

from docker-mailserver.

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.

from docker-mailserver.