An anonymous reader quotes a report from ZDNet: IBM managed the open sourcing of Granite code by using pretraining data from publicly available datasets, such as GitHub Code Clean, Starcoder data, public code repositories, and GitHub issues. In short, IBM has gone to great lengths to avoid copyright or legal issues. The Granite Code Base models are trained on 3- to 4-terabyte tokens of code data and natural language code-related datasets. All these models are licensed under the Apache 2.0 license for research and commercial use. It's that last word -- commercial -- that stopped the other major LLMs from being open-sourced. No one else wanted to share their LLM goodies.

But, as IBM Research chief scientist Ruchir Puri said, "We are transforming the generative AI landscape for software by releasing the highest performing, cost-efficient code LLMs, empowering the open community to innovate without restrictions." Without restrictions, perhaps, but not without specific applications in mind. The Granite models, as IBM ecosystem general manager Kate Woolley said last year, are not "about trying to be everything to everybody. This is not about writing poems about your dog. This is about curated models that can be tuned and are very targeted for the business use cases we want the enterprise to use. Specifically, they're for programming."

These decoder-only models, trained on code from 116 programming languages, range from 3 to 34 billion parameters. They support many developer uses, from complex application modernization to on-device memory-constrained tasks. IBM has already used these LLMs internally in IBM Watsonx Code Assistant (WCA) products, such as WCA for Ansible Lightspeed for IT Automation and WCA for IBM Z for modernizing COBOL applications. Not everyone can afford Watsonx, but now, anyone can work with the Granite LLMs using IBM and Red Hat's InstructLab.

This week, The Register reported: If you are still running RHEL 7, which is now approaching a decade old, there's good news. Red Hat is offering four more years of support for RHEL 7.9, which it terms Extended Life Cycle Support or ELS.

If you are running the free version, CentOS Linux 7, that hits its end-of-life on the same date: June 30, 2024. CIQ, which offers CentOS Linux rebuild Rocky Linux, has a life cycle extension for that too, which it calls CIQ Bridge. The company told The Reg: "CIQ Bridge, essentially a long-term support service tailored for CentOS 7 users on the migration path to Rocky Linux, is offered under an annual, fixed-rate subscription. CIQ Bridge includes access to CentOS 7 extended life package updates for an additional three years and security updates for CVSS 7 issues and above. Security updates for CVSS 5 and 6 are available at an elevated subscription tier. CIQ Bridge is designed to support CentOS 7 users until they are ready for CIQ guidance and support in migration to Rocky Linux." CIQ believes there's a substantial market for this, and points to research from Enlyft that suggests hundreds of thousands of users still on CentOS Linux 7.

Red Hat Enterprise Linux 9.4 has been released. But also released is Rocky Linux 9.4, reports 9to5Linux: Rocky Linux 9.4 also adds openSUSE's KIWI next-generation appliance builder as a new image build workflow and process for building images that are feature complete with the old images... Under the hood, Rocky Linux 9.4 includes the same updated components from the upstream Red Hat Enterprise Linux 9.4
This week also saw the release of Alma Linux 9.4 stable (the "forever-free enterprise Linux distribution... binary compatible with RHEL.") The Register points out that while Alma Linux is "still supporting some aging hardware that the official RHEL 9.4 drops, what's new is largely the same in them both."

And last week also saw the launch of the AlmaLinux High-Performance Computing and AI Special Interest Group (SIG). HPCWire reports: "AlmaLinux's status as a community-driven enterprise Linux holds incredible promise for the future of HPC and AI," said Hayden Barnes, SIG leader and Senior Open Source Community Manager for AI Software at HPE. "Its transparency and stability empowers researchers, developers and organizations to collaborate, customize and optimize their computing environments, fostering a culture of innovation and accelerating breakthroughs in scientific research and cutting-edge AI/ML."
And this week, InfoWorld reported: Red Hat has launched Red Hat Enterprise Linux AI (RHEL AI), described as a foundation model platform that allows users to more seamlessly develop and deploy generative AI models. Announced May 7 and available now as a developer preview, RHEL AI includes the Granite family of open-source large language models (LLMs) from IBM, InstructLab model alignment tools based on the LAB (Large-Scale Alignment for Chatbots) methodology, and a community-driven approach to model development through the InstructLab project, Red Hat said.

SiliconANGLE looks at how starting in 2021, Microsoft and Red Hat have formed "an unlikely partnership set to reshape the landscape of cloud computing..." First, their collective open-source capabilities will lead to co-developed solutions to simplify the modernization and migration of Red Hat technologies to the cloud, seamlessly integrating them with Microsoft's Azure platform, according to João Couto, EMEA VP and COO of cloud commercial solutions at Microsoft. "We have acquired GitHub, which is also one of the largest repositories of open source worldwide," he said. "In that context, it makes a lot of sense to work together with Red Hat."
Transcribed from their interview: What we have been doing so far is making sure that we are co-developing solutions together with Red Hat. And making these solutions available to our customers — making it easy for customers to transform, to modernize [their] Red Hat technology running on-prem, and moving them into cloud using our own Microsoft cloud technology, but Red Hat solutions, in a very, very seamless, integrated way. And also leveraging all the entire portfolio of Red Hat automation tools, so that they can make it easier for customers not just to do the migration, but also to do management, run the operation, and all the troubleshooting also from the customer-care perspective. So that's basically an end-to-end partnership approach that we are taking...

"[Customers] get an integrated support experience from Red Hat technical teams and Microsoft technical teams. And this means that these two technical teams are often colocated, so whenever a customer has a challenge, they are being answered by Microsoft and Red Hat technical teams, all working together to solve this challenge from the customer. So this brings also an increased level of confidence to customers to move to cloud...

"We have both engineering teams from both sides working together to achieve this level of integration between the two solutions. So when you talk about Red Hat Enterprise Linux or when you have the Azure Red Hat OpenShift, which is a new solution that we have recently launched — these are solutions that using open source, are bringing in an additional level of integration, flexibility, automation to customers. So that they can migrate, and manage, their solutions in a more seamless way, and in a more easy way. So we are embedding this kind of overlying partnership from an open source perspective to bring these innovations live to customers."

SiliconANGLE reports that to help organizations detect vulnerabilities earlier, Red Hat has "announced updates to its Trusted Software Supply Chain that enable organizations to shift security 'left' in the software supply chain." Red Hat announced Trusted Software Supply Chain in May 2023, pitching it as a way to address the rising threat of software supply chain attacks. The service secures software pipelines by verifying software origins, automating security processes and providing a secure catalog of verified open-source software packages. [Thursday's updates] are aimed at advancing the ability for customers to embed security into the software development life cycle, thereby increasing software integrity earlier in the supply chain while also adhering to industry regulations and compliance standards.

They start with a new tool called Red Hat Trust Artifact Signer. Based on the open-source Sigstore project [founded at Red Hat and now part of the Open Source Security Foundation], Trust Artifact Signer allows developers to sign and verify software artifacts cryptographically without managing centralized keys, to enhance trust in the software supply chain. The second new release, Red Hat Trusted Profile Analyzer, provides a central source for security documentation such as Software Bill of Materials and Vulnerability Exploitability Exchange. The tool simplifies vulnerability management by enabling proactive identification and minimization of security threats.

The final new release, Red Hat Trusted Application Pipeline, combines the capabilities of the Trusted Profile Analyzer and Trusted Artifact Signer with Red Hat's internal developer platform to provide integrated security-focused development templates. The feature aims to standardize and accelerate the adoption of secure development practices within organizations.
Specifically, Red Hat's announcement says organizations can use their new Trust Application Pipeline feature "to verify pipeline compliance and provide traceability and auditability in the CI/CD process with an automated chain of trust that validates artifact signatures, and offers provenance and attestations."

BrianFagioli shares a report from BetaNews: In a recent security announcement, Red Hat's Information Risk and Security and Product Security teams have identified a critical vulnerability in the latest versions of the 'xz' compression tools and libraries. The affected versions, 5.6.0 and 5.6.1, contain malicious code that could potentially allow unauthorized access to systems. Fedora Linux 40 users and those using Fedora Rawhide, the development distribution for future Fedora builds, are at risk.

The vulnerability, designated CVE-2024-3094, impacts users who have updated to the compromised versions of the xz libraries. Red Hat urges all Fedora Rawhide users to immediately cease using the distribution for both work and personal activities until the issue is resolved. Plans are underway to revert Fedora Rawhide to the safer xz-5.4.x version, after which it will be safe to redeploy Fedora Rawhide instances. Although Fedora Linux 40 builds have not been confirmed to be compromised, Red Hat advises users to downgrade to a 5.4 build as a precautionary measure. An update reverting xz to 5.4.x has been released and is being distributed to Fedora Linux 40 users through the normal update system. Users can expedite the update by following instructions provided by Red Hat. Further reader submissions: xz/liblzma Backdoored, Facilitating ssh Compromise;
Malicious Code Discovered in Popular XZ Utils.

An anonymous reader shares a report: Mutterings of alarm are emerging from the cloisters of Red Hat after the world's largest management consultancy was hired to help the IBM subsidiary focus engineers on their highest-value work. Red Hat confirmed the partnership with McKinsey & Company to The Reg, sharing this extract from an email from CTO Chris Wright to the Global Engineering Team:

"Hey everyone -- as I mentioned during the recent Q1 All Hands, my goal is to have Global Engineering recognized as the world's greatest open-source software engineering organization. This team is already doing amazing work, and we have several initiatives in progress to help us achieve the goal I've set. One of those is a partnership with McKinsey. The objective of this project is to help us understand and incorporate learnings on working models, development practices, and tooling from across the software industry.

"We've heard your feedback in person, during All Hands, and through RHAS [the annual Red Hat Associate Survey]. This project will help us to identify and remove mundane tasks that drain your energy so that you can focus on the most engaging and highest value work â" to make your job better. The work with McKinsey is one piece of the overall plan to help us become the world's greatest open-source software engineering organization"

Linus Torvalds had "some robust exchanges" on the Linux kernel mailing list with a contributor from Google. The subject was inodes, notes the Register, "which as Red Hat puts it are each 'a unique identifier for a specific piece of metadata on a given filesystem.'" Inodes have been the subject of debate on the Linux Kernel Mailing list for the last couple of weeks, with Googler Steven Rostedt and Torvalds engaging in some robust exchanges on the matter. In a thread titled, "Have the inodes all for files and directories all be the same," posters noted that inodes may still have a role when using tar to archive files. Torvalds countered that inodes have had their day. "Yes, inode numbers used to be special, and there's history behind it. But we should basically try very hard to walk away from that broken history," he wrote. "An inode number just isn't a unique descriptor any more. We're not living in the 1970s, and filesystems have changed." But debate on inodes continued. Rostedt eventually suggested that inodes should all have unique numbers...

In response... Torvalds opened: "Stop making things more complicated than they need to be." Then he got a bit shouty. "And dammit, STOP COPYING VFS LAYER FUNCTIONS. It was a bad idea last time, it's a horribly bad idea this time too. I'm not taking this kind of crap." Torvalds's main criticism of Rostedt's approach is that the Google dev didn't fully understand the subject matter — which Rostedt later acknowledged.
"An inode number just isn't a unique descriptor any more," Torvalds wrote at one point.

"We're not living in the 1970s, and filesystems have changed."

"This is a proposed Change for Fedora Linux..." emphasizes its page on the Fedora project Wiki. "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."

But Phoronix reports that "One of the latest change proposals filed for Fedora 40 is to unify their /usr/bin and /usr/sbin locations." The change proposal explains:

"The /usr/sbin directory becomes a symlink to bin, which means paths like /usr/bin/foo and /usr/sbin/foo point to the same place. /bin and /sbin are already symlinks to /usr/bin and /usr/sbin, so effectively /bin/foo and /sbin/foo also point to the same place. /usr/sbin will be removed from the default $PATH."

Fedora years ago merged /bin and /usr/bin and as the last step they want to unify /usr/bin and /usr/sbin.
The change proposal argues that with this change, "Fedora becomes more compatible with other distributions."


- We have /sbin/ip while Debian has /bin/ip

- We have /bin/chmem and /bin/isosize, but Debian has /sbin/chmem and /sbin/isosize

- We also have /sbin/{addpart,delpart,lnstat,nstat,partx,ping,rdma,resizepart,ss,udevadm,update-alternatives}, while Debian has those in under /bin, etc.

- Fedora becomes more compatible with Arch, which did the merge a few years ago.


The proposal on the Fedora project Wiki offers this summary: The split between /bin and /sbin is not useful, and also unused. The original split was to have "important" binaries statically linked in /sbin which could then be used for emergency and rescue operations. Obviously, we don't do static linking anymore. Later, the split was repurposed to isolate "important" binaries that would only be used by the administrator. While this seems attractive in theory, in practice it's very hard to categorize programs like this, and normal users routinely invoke programs from /sbin. Most programs that require root privileges for certain operations are also used when operating without privileges. And even when privileges are required, often those are acquired dynamically, e.g. using polkit. Since many years, the default $PATH set for users includes both directories. With the advent of systemd this has become more systematic: systemd sets $PATH with both directories for all users and services. So in general, all users and programs would find both sets of binaries...

Since generally all user sessions and services have both directories in $PATH, this split actually isn't used for anything. Its main effect is confusion when people need to use the absolute path and guess the directory wrong. Other distributions put some binaries in the other directory, so the absolute path is often not portable. Also, it is very easy for a user to end up with /sbin before /bin in $PATH, and for an administrator to end up with /bin before /sbin in $PATH, causing confusion. If this feature is dropped, the system became a little bit simpler, which is useful especially for new users, who are not aware of the history of the split.

"Red Hat is going to do away with the X.Org server and support Wayland and XWayland for apps that currently (or only) run on X11," writes Slashdot reader motang. Red Hat's Carlos Soriano Sanchez confirmed on the Red Hat blog: "The result of this evaluation is that, while there are still some gaps and applications that need some level of adaptation, we believe the Wayland infrastructure and ecosystem are in good shape, and that we're on a good path for the identified blockers to be resolved by the time RHEL 10 is out, planned to be released on the first half of 2025.

With this, we've decided to remove Xorg server and other X servers (except Xwayland) from RHEL 10 and the following releases. Xwayland should be able to handle most X11 clients that won't immediately be ported to Wayland, and if needed, our customers will be able to stay on RHEL 9 for its full life cycle while resolving the specifics needed for transitioning to a Wayland ecosystem. It's important to note that "Xorg Server" and "X11" are not synonymous, X11 is a protocol that will continue to be supported through Xwayland, while the Xorg Server is one of the implementations of the X11 protocol.
[...]
This decision will allow us to focus our efforts starting from RHEL 10 solely on a modern stack and ecosystem. This means we will be able to tackle problems such as HDR, increased security, setups with mixed low and high density displays or very high density displays, better GPU/Display hot-plugging, better gestures and scrolling, and so on. We are confident that Wayland will provide a solid platform and we're excited to work with the community and all of our partners and customers on building the future for Linux."

In Raleigh, North Carolina — the home of Red Hat — local newspaper the News & Observer takes an in-depth look at the "announcement that split the open source software community." (Alternate URL here.) [M]any saw Red Hat's decision to essentially paywall Red Hat Enterprise Linux, or RHEL, as sacrilegious... Red Hat employees were also conflicted about the new policy, [Red Hat Vice President Mike] McGrath acknowledged. "I think a lot of even internal associates didn't fully understand what we had announced and why," he said...

At issue, he wrote, were emerging competitors who copied Red Hat Enterprise Linux, down to even the code's mistakes, and then offered these Red Hat-replicas to customers for free. These weren't community members adding value, he contended, but undercutting rivals. And in a year when Red Hat laid off 4% of its total workforce, McGrath said, the company could not justify allowing this to continue. "I feel that while this was a difficult decision between community and business, we're still on the right side of it," he told the News & Observer. Not everyone agrees...

McGrath offered little consolation to customers who were relying on one-for-one versions of RHEL. They could stay with the downstream distributions, find another provider, or pay for Red Hat. "I think (people) were just so used to the way things work," he said. "There's a vocal group of people that probably need Red Hat's level of support, but simply don't want to pay for it. And I don't really have... there's not much we can tell them."

Since its RHEL decision, Red Hat has secured several prominent partnerships. In September, the cloud-based software company Salesforce moved 200,000 of its systems from the free CentOS Linux to Red Hat Enterprise Linux. The same month, Red Hat announced RHEL would begin to support Oracle's cloud infrastructure. Oracle was one of the few major companies this summer to publicly criticize Red Hat for essentially paywalling its most popular code. On Oct. 24, Red Hat notched another win when the data security firm Cohesity said it would also ditch CentOS Linux for RHEL.
The article delves into the history of Red Hat — and of Linux — before culminating with this quote from McGrath. "I think long gone are the times of that sort of romantic view of hobbyists working in their spare time to build open source. I think there's still room for that — we still have that — but quite a lot of open source is now built from people that are paid full time."

Red Hat likes to point out that 90% of Fortune 500 companies use its services, according to the article. But it also quotes Jonathan Wright, infrastructure team lead at the nonprofit AlmaLinux, as saying that Red Hat played "fast and loose" with the GPL. The newspaper then adds that "For many open source believers, such a threat to its hallowed text isn't forgivable."

Long-time Slashdot reader williamyf writes: In the ongoing battle between Red Hat and other "Enterprise Linux -- RHEL compatible" distros, today the OpenELA (Open Enterprise Linux Association), a body Consisting of CIQ (stewards of Rocky Linux), Oracle and Suse, released source code for a generic "Enterprise Linux Distro" (Sources available for RHEL 8 and RHEL 9). A Steering committee for the foundation was also formed.

War between Red Hat and what they call "clones" (mostly Oracle; CentOS, Rocky, Alma and others seem to be collateral damage) has been raging on for years. First, in 2011, Red Hat changed the way they distributed kernel patches. Then, in 2014, Red Hat absorbed CentOS. In 2019 Red Hat transformed CentOS to CentOS stream, and shortened support Timetables for CentOS 8, all out of the blue. Then, in 2023, RedHat severely restricted source code access to non-customers.

What will be RedHat's reaction to this development? My bet is that they will stop to release source code of distro modules under BSD, MIT, APACHE and MPL Licenses for RHEL and in certain Windows for CentOS Stream. What is your bet? Let us know in the comments.

An anonymous reader shares a report: When Mike McGrath, Red Hat's Red Hat Core Platforms vice president, announced that Red Hat was putting new restrictions on who could access Red Hat Enterprise Linux (RHEL)'s code, other Linux companies that depended on RHEL's code for their own distro releases were, in a word, unhappy. Three of them, CIQ, Oracle, and SUSE, came together to form the Open Enterprise Linux Association (OpenELA). Their united goal was to foster "the development of distributions compatible with Red Hat Enterprise Linux (RHEL) by providing open and free enterprise Linux source code." Now, the first OpenELA code release is available.

As Thomas Di Giacomo, SUSE's chief technology and product officer, said in a statement, "We're pleased to deliver on our promise of making source code available and to continue our work together to provide choice to our customers while we ensure that Enterprise Linux source code remains freely accessible to the public." Why are they doing this? Gregory Kurtzer, CIQ's CEO, and Rocky Linux's founder, explained: "Organizations worldwide standardized on CentOS because it was freely available, followed the Enterprise Linux standard, and was well supported. After CentOS was discontinued, it left not only a gaping hole in the ecosystem but also clearly showed how the community needs to come together and do better. OpenELA is exactly that -- the community's answer to ensuring a collaborative and stable future for all professional IT departments and enterprise use cases."

AlmaLinux is creating a Red Hat Enterprise Linux (RHEL) without any Red Hat code. Instead, AlmaLinux OS will aim to be Application Binary Interface (ABI) compatible and use the CentOS Stream source code that Red Hat continues to offer. Additional code is pulled from Red Hat Universal Base Images, and upstream Linux code. Benny Vasquez, chairperson of the AlmaLinux OF Foundation, explained how all this works at the open-source community convention All Things Open. ZDNet's Steven Vaughan-Nichols reports: The hardest part is Red Hat's Linux kernel updates because, added Vasquez, "you can't get those kernel updates without violating Red Hat's licensing agreements." Therefore, she continued, "What we do is we pull the security patches from various other sources, and, if nothing else, we can find them when Oracle releases them." Vasquez did note one blessing from this change in production: "AlmaLinux, no longer bound to Red Hat's releases, has been able to release upstream security fixes faster than Red Hat. "For example, the AMD microcode exploits were patched before Red Hat because they took a little bit of extra time to get out the door. We then pulled in, tested, and out the door about a week ahead of them." The overall goal remains to maintain RHEL compatibility. "Any breaking changes between RHEL and AlmaLinux, any application that stops working, is a bug and must be fixed."

That's not to say AlmaLinux will be simply an excellent RHEL clone going forward. It plans to add features of its own. For instance, Red Hat users who want programs not bundled in RHEL often turn to Extra Packages for Enterprise Linux (EPEL). These typically are programs included in Fedora Linux. Besides supporting EPEL software, AlmaLinux has its own extra software package -- called Synergy -- which holds programs that the AlmaLinux community wants but are not available in either EPEL or RHEL. If one such program is subsequently added to EPEL or RHEL, AlmaLinux drops it from Synergy to prevent confusion and duplication of effort.

This has not been an easy road for AlmaLinux. Even a 1% code difference is a lot to write and maintain. For example, when AlmaLinux tried to patch CentOS Stream code to fix a problem, Red Hat was downright grumpy about AlmaLinux's attempt to fix a security hole. Vasquez acknowledged it was tough sledding at first, but noted: "The good news is that they have been improving the process, and things will look a little bit smoother." AlmaLinux, she noted, is also not so much worried as aware that Red Hat may throw a monkey wrench into their efforts. Vasquez added: "Internally, we're working on stopgap things we'd need to do to anticipate Red Hat changing everything terribly." She doesn't think Red Hat will do it, but "we want to be as prepared as possible."

Thursday ZDNet reported... As security holes go, CVE-2023-4911, aka "Looney Tunables," isn't horrid. It has a Common Vulnerability Scoring System score of 7.8, which is ranked as important, not critical.

On the other hand, this GNU C Library's (glibc) dynamic loader vulnerability is a buffer overflow, which is always big trouble, and it's in pretty much all Linux distributions, so it's more than bad enough. After all, its discoverers, the Qualys Threat Research Unit, were able to exploit "this vulnerability (a local privilege escalation that grants full root privileges) on the default installations of Fedora 37 and 38, Ubuntu 22.04 and 23.04, and Debian 12 and 13." Other distributions are almost certainly vulnerable to attack. The one major exception is the highly secure Alpine Linux. Thanks to this vulnerability, it's trivial to take over most Linux systems as a root user. As the researchers noted, this exploitation method "works against almost all of the SUID-root programs that are installed by default on Linux...."

The good news is that Red Hat, Ubuntu, Debian, and Gentoo have all released their own updates. In addition, the upstream glibc code has been patched with the fix. If you can't patch it, Red Hat has a script that should work on most Linux systems to mitigate the problem by setting your system to terminate any setuid program invoked with GLIBC_TUNABLES in the environment.

Yes, Red Hat Enterprise Linux changed its licensing last month — but how will that affect AlmaLinux? The chair of the nonprofit AlmaLinux OS Foundation, benny Vasquez, tells SiliconANGLE that "For typical users, there's very, very little difference. Overall, we're still exactly the same way we were, except for kernel updates." Updates may no longer be available the day a new version of RHEL comes out, but developers still have access to Red Hat's planned enhancements and bug fixes via CentOS Stream, a version of RHEL that Red Hat uses as essentially a test bed for new features that might later be incorporated into its flagship product. From a practical perspective, that's nearly as good as having access to the production source code, Vasquez said. "While there is a generally accepted understanding that not everything in CentOS Stream will end up in RHEL, that's not how it works in practice," she said. "I can't think of anything they have shipped in RHEL that wasn't in Stream first."

That's still no guarantee, but the workarounds AlmaLinux has put in place over the past month should address all but the most outlier cases, Vasquez said. The strategy has shifted from bug-for-bug compatibility to being application binary interface-compatible... ABI compatibility doesn't guarantee that problems will never occur, but glitches should be rare and can usually be resolved by recompiling the source code. "It is sufficient for us to be ABI-compatible with RHEL," Vasquez said. "The most important thing is that this allows our community to feel stability."

In fact, Red Hat's change of direction has been a blessing in disguise for AlmaLinux, she said... "We view this as a release from our bonds of being one-to-one." Patches can be applied without waiting for a cue from Red Hat and "we get to engage with our community in a completely new and exciting way." AlmaLinux has also seen a modest financial windfall from Red Hat's decision. "The outpouring of support has been pretty impressive," Vasquez said. "People have shown up for event staffing and website maintenance and infrastructure management and we've gotten more financial backing from corporations."
Vasquez also told the site that "the number of everyday people throwing in $5 has more than quadrupled."

In a groundbreaking move, CIQ, Oracle, and SUSE have come together to announce the formation of the Open Enterprise Linux Association (OpenELA). From a report: The goal of this new collaborative trade association is to foster "the development of distributions compatible with Red Hat Enterprise Linux (RHEL) by providing open and free enterprise Linux source code."

The inception of OpenELA is a direct response to Red Hat's recent alterations to RHEL source code availability. This new Delaware 501(c)(6) US nonprofit association will provide an open process for organizations to access source code. This will enable it to build RHEL-compatible distributions. The initiative underscores the importance of community-driven source code, which serves as a foundation for creating compatible distributions.

Mike McGrath, Red Hat's vice president of Red Hat Core Platforms, sparked this when he announced Red Hat would be changing how users can access RHEL's source code. For the non-Hatters among you, Core Platforms is the division in charge of RHEL. McGrath wrote, "CentOS Stream will now be the sole repository for public RHEL-related source code releases. For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal."

This made it much more difficult for RHEL clone vendors, such as AlmaLinux, Rocky Linux, and Oracle Linux, to create perfect RHEL variant distributions. AlmaLinux elected to try to work with Red Hat's new source code rules. Oracle restarted its old fighting ways with IBM/Red Hat; SUSE announced an RHEL-compatible distro fork plan; and Rocky Linux found new ways to obtain RHEL code. Now the last two, along with CIQ, which started Rocky Linux, have joined forces.

In February of 1994 Jon "maddog" Hall interviewed a young Linus Torvalds (then just 24). Nearly three decades later — as Hall approaches his 73rd birthday — he's shared a long essay looking back, but also assessing today's controversy about Red Hat's licensing of RHEL. A (slightly- condensed] excerpt: [O]ver time some customers developed a pattern of purchasing a small number of RHEL systems, then using the "bug-for-bug" compatible version of Red Hat from some other distribution. This, of course, saved the customer money, however it also reduced the amount of revenue that Red Hat received for the same amount of work. This forced Red Hat to charge more for each license they sold, or lay off Red Hat employees, or not do projects they might have otherwise funded. So recently Red Hat/IBM made a business decision to limit their customers to those who would buy a license from them for every single system that would run RHEL and only distribute their source-code and the information necessary on how to build that distribution to those customers. Therefore the people who receive those binaries would receive the sources so they could fix bugs and extend the operating system as they wished.....this was, and is, the essence of the GPL.

Most, if not all, of the articles I have read have said something along the lines of "IBM/Red Hat seem to be following the GPL..but...but...but... the community! "

Which community? There are plenty of distributions for people who do not need the same level of engineering and support that IBM and Red Hat offer. Red Hat, and IBM, continue to send their changes for GPLed code "upstream" to flow down to all the other distributions. They continue to share ideas with the larger community. [...]

I now see a lot of people coming out of the woodwork and beating their breasts and saying how they are going to protect the investment of people who want to use RHEL for free [...] So far I have seen four different distributions saying that they will continue the production of "not RHEL", generating even more distributions for the average user to say "which one should I use"? If they really want to do this, why not just work together to produce one good one? Why not make their own distributions a RHEL competitor? How long will they keep beating their breasts when they find out that they can not make any money at doing it? SuSE said that they would invest ten million dollars in developing a competitor to RHEL. Fantastic! COMPETE. Create an enterprise competitor to Red Hat with the same business channels, world-wide support team, etc. etc. You will find it is not inexpensive to do that. Ten million may get you started.

My answer to all this? RHEL customers will have to decide what they want to do. I am sure that IBM and Red Hat hope that their customers will see the value of RHEL and the support that Red Hat/IBM and their channel partners provide for it. The rest of the customers who just want to buy one copy of RHEL and then run a "free" distribution on all their other systems no matter how it is created, well it seems that IBM does not want to do business with them anymore, so they will have to go to other suppliers who have enterprise capable distributions of Linux and who can tolerate that type of customer. [...]

I want to make sure people know that I do not have any hate for people and companies who set business conditions as long as they do not violate the licenses they are under. Business is business.

However I will point out that as "evil" as Red Hat and IBM have been portrayed in this business change there is no mention at all of all the companies that support Open Source "Permissive Licenses", which do not guarantee the sources to their end users, or offer only "Closed Source" Licenses....who do not allow and have never allowed clones to be made....these people and companies do not have any right to throw stones (and you know who you are).

Red Hat and IBM are making their sources available to all those who receive their binaries under contract. That is the GPL.

For all the researchers, students, hobbyists and people with little or no money, there are literally hundreds of distributions that they can choose, and many that run across other interesting architectures that RHEL does not even address.
Hall answered questions from Slashdot users in 2000 and again in 2013.

Further reading: Red Hat CEO Jim Whitehurst answering questions from Slashdot readers in 2017.

After Red Hat's decision to only share RHEL source code with subscribers, AlmaLinux asked their bug report submitters to "attempt to test and replicate the problem in CentOS Stream as well, so we can focus our energy on correcting it in the right place."

Red Hat told Ars Technica they are "eager to collaborate" on their CentOS Stream distro, "even if we ultimately compete in a business sense. Differentiated competition is a sign of a healthy ecosystem."

But Red Hat still managed to ruffled some feathers, reports ZDNet: AlmaLinux Infrastructure Team Leader Jonathan Wright recently posted a CentOS Stream fix for CVE-2023-38403, a memory overflow problem in iperf3. Iperf3 is a popular open-source network performance test. This security hole is an important one, but not a huge problem.

Still, it's better by far to fix it than let it linger and see it eventually used to crash a server. That's what I and others felt anyway. But, then, a senior Red Hat software engineer replied, "Thanks for the contribution. At this time, we don't plan to address this in RHEL, but we will keep it open for evaluation based on customer feedback."

That went over like a lead balloon.

The GitLab conversation proceeded:

AlmaLinux: "Is customer demand really necessary to fix CVEs?"

Red Hat: "We commit to addressing Red Hat defined Critical and Important security issues. Security vulnerabilities with Low or Moderate severity will be addressed on demand when [a] customer or other business requirements exist to do so."

AlmaLinux: "I can even understand that, but why reject the fix when the work is already done and just has to be merged?"

At this point, Mike McGrath, Red Hat's VP of Core Platforms, AKA RHEL, stepped in. He explained, "We should probably create a 'what to expect when you're submitting' doc. Getting the code written is only the first step in what Red Hat does with it. We'd have to make sure there aren't regressions, QA, etc. ... So thank you for the contribution, it looks like the Fedora side of it is going well, so it'll end up in RHEL at some point."

Things went downhill rapidly from there...

On Reddit, McGrath said, "I will admit that we did have a great opportunity for a good-faith gesture towards Alma here and fumbled."

Finally, though the Red Hat Product Security team rated the CVE as "'Important,' the patch was merged.
Coincidentally, last month AlmaLinux announced that its move away from 1:1 compatibility with RHEL meant "we can now accept bug fixes outside of Red Hat's release cycle."

This Thursday AlmaLinux also reiterated that they're "fully committed to delivering the best possible experience for the community, no matter where or what you run." And in an apparent move to beef up compatibility testing, they announced they'd be bringing openQA to the RHEL ecosystem. (They describe openQA as a tool using virtual machines that "simplifies automated testing of the whole installation process of an operating system in a wide combination of software and hardware configurations.")

Last weekend in Portland, Oregon, the Software Freedom Conservancy hosted a new conference called the Free and Open Source Software Yearly.

And long-time free software activist Bradley M. Kuhn (currently a policy fellow/hacker-in-residence for the Software Freedom Conservancy) hosted a lively panel discussion on "the recent change" to public source code releases for Red Hat Enterprise Linux which shed light on what may happen next. The panel also included:

• benny Vasquez, the Chair of the AlmaLinux OS Foundation
• Jeremy Alison, Samba co-founder and software engineer at CIQ (focused on Rocky Linux). Allison is also Jeremy Allison - Sam Slashdot reader #8,157.
• James (Jim) Wright, Oracle's chief architect for Open Source policy/strategy/compliance/alliances

"Red Hat themselves did not reply to our repeated requests to join us on this panel... SUSE was also invited but let us know they were unable to send someone on short notice to Portland for the panel."

One interesting audience question for the panel came from Karsten Wade, a one-time Red Hat senior community architect who left Red Hat in April after 21 years, but said he was "responsible for bringing the CentOS team onboard to Red Hat." Wade argued that CentOS "was always doing a clean rebuild from source RPMS of their own..." So "isn't all of this thunder doing Red Hat's job for them, of trying to get everyone to say, 'This thing is not the equivalent to RHEL.'"

In response Jeremy Alison made a good point. "None of us here are the arbiters of whether it's good enough of a rebuild of Red Hat Linux. The customers are the arbiters." But this led to an audience member asking a very forward-looking question: what are the chances the community could adopt a new (and open) enterprise Linux standard that distributions could follow. AlmaLinux's Vasquez replied, "Chances are real high... I think everyone sees that as the obvious answer. I think that's the obvious next step. I'll leave it at that." And Oracle's Wright added "to the extent that the market asks us to standardize? We're all responsive."

When asked if they'd consider adding features not found in RHEL ("such as high-security gates through reproducible builds") AlmaLinux's Vasquez said "100% -- yeah. One of the things that we're kind of excited about is the opportunities that this opens for us. We had decided we were just going to focus on this north star of 1:1 Red Hat no matter what -- and with that limitation being removed, we have all kinds of options." And CIQ's Alison said "We're working on FIPS certification for an earlier version of Rocky, that Red Hat, I don't believe, FIPS certified. And we're planning to release that."

AlmaLinux's Vasquez emphasized later that "We're just going to build Enterprise Linux. Red Hat has done a great job of establishing a fantastic target for all of us, but they don't own the rights to enterprise Linux. We can make this happen, without forcing an uncomfortable conversation with Red Hat. We can get around this."

And Alison later applied a "Star Wars" quote to Red Hat's predicament. "The more things you try and grab, the more things slip through your fingers." That is, "The more somebody tries to exert control over a codebase, the more the pushback will occur from people who collaborate in that codebase." AlmaLinux's Vasquez also said they're already "in conversations" with independent software vendors about the "flow of support" into non-Red Hat distributions -- though that's always been the case. "Finding ways to reduce the barrier for those independent software vendors to add official support for us is, like, maybe more cumbersome now, but it's the same problem that we've had..."

Early in the discussion Oracle's Jim Wright pointed out that even Red Hat's own web site defines open source code as "designed to be publicly accessible — anyone can see, modify, and distribute the code as they see fit." ("Until now," Wright added pointedly...) There was some mild teasing of Oracle during the 50-minute discussion -- someone asked at one point if they'd re-license their proprietary implementation of ZFS under the GPL. But at the end of the panel, Oracle's Jim Wright still reminded the audience that "If you want to work on open source Linux, we are hiring."

Read Slashdot's transcript of highlights from the discussion.