From Fedora Project Wiki
No edit summary
No edit summary
Line 160: Line 160:


<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency mechanism: (What to do?  Who will do it?) Do not obsolete Redis with Valkey <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: N/A  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->





Revision as of 01:19, 13 April 2024

Important.png
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.
Idea.png
Guidance
For details on how to fill out this form, see the documentation.
Idea.png
Report issues
To report an issue with this template, file an issue in the pgm_docs repo.


Replace Redis with Valkey

Important.png
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


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.

Feedback

Benefit to Fedora

With Redis's license change to SSPL we cannot update it further in Fedora since SSPL is not OSI-approved thus does not meet Fedora Packaging Guidelines. Changing to Valkey ensure users are not abandoned with software which cannot be updated any longer in the OS as well as provides them with continued innovation from the Valkey project.

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

Upgrade/compatibility impact

How To Test

User Experience

Dependencies

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) Do not obsolete Redis with Valkey
  • Contingency deadline: N/A
  • Blocks release? No


Documentation

N/A (not a System Wide Change)

Release Notes