Changes/Replace Redis With Valkey

Comments and Explanations
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.

Guidance
For details on how to fill out this form, see the documentation.

Report issues
To report an issue with this template, file an issue in the pgm_docs repo.

Replace Redis with Valkey

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

We should replace Redis with Valkey due to the recent licensing changes in Redis, which have rendered it incompatible with Free and Open Source Software (FOSS) principles. This shift in Redis's licensing can impact Fedora's commitment to FOSS, potentially limiting users' freedom to modify and redistribute the software under the same terms. Valkey, a fork of Redis, emerges as a viable alternative because it retains a FOSS-compatible license and has robust community and developmental support. Adopting Valkey allows Fedora to continue offering users powerful in-memory data structure store without compromising on licensing restrictions.

Owner

• Name: Jonathan Wright
• Email: jonathan@almalinux.org

Current status

• Targeted release: Fedora Linux 41
• Last updated: 2024-04-13
• [<will be assigned by the Wrangler> devel thread]
• FESCo issue: <will be assigned by the Wrangler>
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

Redis previously used the BSD license, which is widely recognized for its compatibility with FOSS principles, allowing users to freely modify, redistribute, and use the software in both private and commercial settings without stringent restrictions. However, Redis's shift to the Server Side Public License (SSPL) represents a significant departure from its FOSS-compatible roots. The SSPL, not recognized by the Open Source Initiative (OSI) as a FOSS-compatible license, imposes conditions on the use and distribution of software, particularly in service environments. This could necessitate users to disclose their proprietary source code if they use SSPL-covered modules in certain ways, conflicting with Fedora's FOSS policies.

In contrast, Valkey, a community-driven fork of Redis, adheres to the original BSD licensing model, thus maintaining full FOSS compatibility. This commitment is bolstered by substantial backing from the Linux Foundation and the migration of many former Redis contributors to Valkey, ensuring a robust development environment and continuity of expertise.

As the package owner of Valkey in Fedora, my interactions with the Valkey upstream project have underscored their strong dedication to working with distributions. The Valkey team is responsive and proactive in discussions, which facilitates effective package management and integration within Fedora. Their commitment to open collaboration significantly benefits Fedora, ensuring that Valkey is not only technically sound but also aligns with Fedora's principles and community values.

This shift to Valkey allows Fedora to maintain its leadership in offering powerful, FOSS-aligned technologies while supporting a project that values open source integrity and collaboration. This is crucial for keeping Fedora at the forefront of providing robust, community-supported software solutions to its users.

Scope

• Proposal owners: add a valkey-compat package which will port Redis configurations to Valkey. Valkey 7.2.5 is 100% compatible with Redis.

• Other developers: N/A

• Release engineering: N/A

• Policies and guidelines: N/A (not needed for this Change)

• Trademark approval: N/A (not needed for this Change)

• Alignment with Community Initiatives: N/A

Contingency Plan

• Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
• Contingency deadline: N/A (not a System Wide Change)
• Blocks release? N/A (not a System Wide Change), Yes/No

Documentation

N/A (not a System Wide Change)