Stories
Slash Boxes
Comments

SoylentNews is people

Submission Preview

Link to Story

RHEL's Source Code Access Change is Causing Issues for CentOS SIGs

Accepted submission by upstart at 2024-01-29 20:34:19
News

████ # This file was generated bot-o-matically! Edit at your own risk. ████

RHEL's Source Code Access Change Is Causing Issues For CentOS SIGs [phoronix.com]:

RHEL's Source Code Access Change Is Causing Issues For CentOS SIGs It looks like the Red Hat change restricting access to RHEL sources [phoronix.com] that was announced last year is having the unintended consequence of causing some headaches for CentOS special interest group (SIG) projects.

Published last week on the CentOS blog [centos.org] was the Kmods SIG status update. This is the special interest group maintaining extra kernel modules for CentOS Stream and Red Hat Enterprise Linux. Notable there is the note:

"Due to changes in the way Red Hat releases Red Hat Enterprise Linux source code, the Kmods SIG is currently unable to produce packages for Red Hat Enterprise Linux for legal reasons. We are working with Red Hat to resolve this situation and hope to be able to provide packages for Enterprise Linux again as soon as possible."

Due to restricting access to the RHEL kernel sources among other Red Hat Enterprise Linux source packages, it's causing issues for the CentOS SIG trying to improve the kernel modules experience for RHEL (and CentOS Stream) users...

A seemingly similar kernel change was noted today by the CentOS Hyperscale SIG.This special interest group as a reminder is about enhancing CentOS Stream for large-scale infrastructure like those at Meta / Facebook, X / Twitter, and others:

"The latest version in the Hyperscale SIG is kernel 6.7.1-0.hs1 for CentOS Stream 9. This new kernel is now based on upstream Fedora release kernel rather than the CentOS/RHEL kernel tree. For the foreseeable future, the Hyperscale SIG will be tracking Fedora kernels to build and release into CentOS. The kernel is still built with a RHEL-like configuration, modulo changes for CentOS Hyperscale specifically."

So the CentOS Hyperscale SIG is now basing their fresh kernel builds on Fedora in a RHEL-like build rather than the CentOS/RHEL kernel tree.

The Hyperscale SIG also shared [centos.org] about their work on the latest systemd updates, new experimental GNOME and KDE workstation live media images for CentOS Stream Hyperscale 9, and other leading-edge package updates. The SIG also continues maintaining a DNF/RPM stack with Btrfs copy-on-write support.;

oops-ibm-does-not-own-the-community dept.

Red Hat’s new source code policy and the intense pushback, explained [arstechnica.com]:

When CentOS announced [centos.org] in 2020 that it was shutting down its traditional "rebuild" of Red Hat Enterprise Linux [arstechnica.com] (RHEL) to focus on its development build, Stream, CentOS suggested the strategy "removes confusion." Red Hat, which largely controlled CentOS by then, considered it [redhat.com] "a natural, inevitable next step."

Last week, the IBM-owned Red Hat continued "furthering the evolution of CentOS Stream [redhat.com]" by announcing that CentOS Stream would be "the sole repository for public RHEL-related source code releases," with RHEL's core code otherwise restricted to a customer portal. (RHEL access is free for individual developers [redhat.com] and up to 16 servers [arstechnica.com], but that's largely not the issue here).

Red Hat's post was a rich example of burying the lede and a decisive moment for many who follow the tricky balance of Red Hat's open source commitments and service contract business. Here's what followed.

Code will still flow, if painfully

Rocky Linux [rockylinux.org], launched by CentOS co-founder Greg Kurtzer [arstechnica.com] as a replacement RHEL-compatible distro, announced Thursday [rockylinux.org] that it believes Red Hat's moves "violate the spirit and purpose of open source." Using a few different methods (Universal Base Image containers, pay-per-use public cloud instances), Rocky Linux intends to maintain what it considers legitimate access to RHEL code under the GNU General Public License (GPL) and make the code public as soon as it exists.

"[O]ur unwavering dedication and commitment to open source and the Enterprise Linux community remain steadfast," the project wrote in its blog post.

AlmaLinux [almalinux.org], a similarly RHEL-derived distribution [arstechnica.com], is also working to keep providing RHEL-compatible updates and downstream rebuilds. "The process is more labor intensive as we require gathering data and patches from several sources, comparing them, testing them, and then building them for release," wrote Jack Aboutboul, community manager for AlmaLinux, in a blog post [almalinux.org]. "But rest assured, updates will continue flowing just as they have been."

Letter vs. spirit

The Software Freedom Conservancy's Bradley M. Kuhn weighed in last week with a comprehensive overview of RHEL's business model [sfconservancy.org] and its tricky relationship with GPL compliance. Red Hat's business model "skirts" GPL violation but had only twice previously violated the GPL in newsworthy ways, Kuhn wrote. Withholding Complete Corresponding Source (CCS) from the open web doesn't violate the GPL itself, but by doing so, Red Hat makes it more difficult for anyone to verify the company's GPL compliance.

Kuhn expressed sadness that "this long road has led the FOSS community to such a disappointing place."

Shorter, pithier versions of the GPL-minded community's reaction to Red Hat's news are exemplified by Jeff Geerling's blog post called "Dear Red Hat: Are you dumb? [jeffgeerling.com]," or his YouTube Video "Huge Open Source Drama [youtube.com]." Geerling, who says he's dropping RHEL support from his Ansible and other software projects, says that Red Hat's moves are intended to "destroy" Rocky, Alma, and other RHEL derivatives and that after the "knife in the back" of abandoning full CentOS Linux, the recent moves "took that knife and twisted it, hard."

“Simply rebuilding code”

Mike McGrath, vice president of core platforms engineering at Red Hat, wrote Monday [redhat.com] that he "spent a lot of time walking" last weekend, thinking about the Linux community's reaction to the initial announcement. Red Hat contributes code upstream, doesn't "simply take upstream packages and rebuild them," and maintains and supports operating systems for 10 years, McGrath wrote.

"I feel that much of the anger from our recent decision around the downstream sources comes from either those who do not want to pay for the time, effort, and resources going into RHEL or those who want to repackage it for their own profit," he wrote. "This demand for RHEL code is disingenuous."

While Red Hat previously "found value in the work done by rebuilders like CentOS," the idea that they are "churning out RHEL experts and turning into sales just isn't reality." McGrath points to SUSE, Canonical (Ubuntu), AWS, and Microsoft as competitors using Linux code, but "none claim to be 'fully compatible' with the others."

"Ultimately, we do not find value in a RHEL rebuild and we are not under any obligation to make things easier for rebuilders; this is our call to make," he wrote. "Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere. This is a real threat to open source, and one that has the potential to revert open source back into a hobbyist- and hackers-only activity."

Richi Jennings at DevOps has compiled many more community reactions [devops.com] to Red Hat's most recent source moves. Unlike full RHEL source code, comment on this matter is likely to be consistently available for some time to come.

← Previous story [arstechnica.com]Next story → [arstechnica.com]


Original Submission