Linux - What about Red Hat and Open Source?
With the latest changes at Red Hat another wave pushed through the world of Open Source. Finally, the dust has settled a bit. In this article, I want to take a look at these changes, discuss if Red Hat is evil and how we might continue from here.
With the latest changes at Red Hat another wave pushed through the world of Open Source. Finally, the dust has settled a bit. In this article, I want to take a look at these changes, discuss if Red Hat is evil and how we might continue from here.
Red Hat's value channel
Before going any further, we need to understand how Red Hat works and how they contribute. If you don't care too much about this, you might think of "Red Hat takes source code, bundles it and makes a Linux distribution out of it." Well, this is true for most distributions, including the Red Hat Enterprise Linux (RHEL). But, there is also way more to it.
Red Hat itself (and IBM, too) are one of the biggest contributors to Open Source. For the Linux Kernel this looks like the below table.
| kernel | contribution | rank | link |
|---|---|---|---|
| 4.20 | 8.4% | 2 | https://lwn.net/Articles/775440/ |
| 5.12 | 6.7% | 3 | https://lwn.net/Articles/853039/ |
| 5.13 | 5.9% | 4 | https://lwn.net/Articles/860989/ |
| 5.15 | 5.1% | 5 | https://lwn.net/Articles/874283/ |
| 5.19 | 5.2% | 5 | https://lwn.net/Articles/902854/ |
| 6.1 | 4.8% | 7 | https://lwn.net/Articles/915435/ |
| 6.2 | 6.6% | 5 | https://lwn.net/Articles/923410/ |
| 6.3 | 7.0% | 3 | https://lwn.net/Articles/929582/ |
| 6.4 | 5.9% | 5 | https://lwn.net/Articles/936113/ |
But, there is way more. Contributing to the kernel does not help you to have a nice UI or container tooling at hand. Red Hat is also contributing a lot here.
Red Hat is somewhat responsible for tools like Podman and Ansible, but also Cockpit Project, OpenSCAP or SELinux. Sure, these projects are seeing other contributors, too. Anyway, a statement that "Red Hat moves away from Red Hat Enterprise Virtualization" has a massive impact on the upstream project oVirt.
Red Hat even takes the risk to buy closed source companies and make the software fully open. This happened for example for Ansible and Stackrox.
And how does this work? Well, normally Red Hat will take one or more Open Source tools, bundle these in something more sophisticated and finally package them for enterprise customers. You can see this in the following projects.
- Ansible -> AWX -> Red Hat Ansible Automation Platform
- Kubernetes -> OKD -> Red Hat OpenShift
- KVM -> oVirt -> Red Hat Enterprise Virtualization
- 389ds -> FreeIPA -> Red Hat Identity Management
- GNU/Linux -> Fedora -> CentOS -> Red Hat Enterprise Linux
Well, as you can see. A lot is happening here. But, let's see about the latest announcements.
Red Hat's announcement
On June 21st, Red Hat announced that the company will change how sources of Red Hat Enterprise Linux (RHEL) are published. The article "Furthering the evolution of CentOS Stream" is somewhat short, but conclusive. The overall message is:
CentOS Stream will now be the sole repository for public RHEL-related source code releases
Effectively, this will make the CentOS Stream sources the only free available source for Red Hat Enterprise Linux. At least this is true for community members, that are not having a valid subscription with Red Hat.
For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal.
You might imagine, that this needed a bit more explanation. Therefore, Mike McGrath added another article, "Red Hat’s commitment to open source: A response to the git.centos.org changes". This article explains, that the legacy sources are effectively "exploded" SRPMs.
There was a time, not too long ago, that Red Hat found value in the work done by rebuilders like CentOS. We pushed our SRPMs out to git.centos.org in a neat package that made them easy to rebuild; we even de-branded it for them. More recently, we have determined that there isn’t value in having a downstream rebuilder.
The most controversial statement might be about the situation if rebuilding and re-branding an existing project is adding value to Open Source software.
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.
The reactions
As you can imagine, such a post will trigger reactions from many people, but also projects. The first one came from Rocky Linux founder Gregory Kurtzer.
I believe that open source should always be freely available and completely stable. It should never be hidden behind a paywall, nor should it be controlled by a single company, ...
AlmaLinux was always pretty surprised by the announcement, but showed a more "find a solution" attitude.
Late last week one of our build SIG members noticed that some updates for Red Hat 8 hadn’t been published on git.centos.org like they were supposed to be. They assumed it was a bug and opened a report appropriately, but as the days went on with no resolution, we knew something was up. This morning we got our answer:
benny VasquezChair, AlmaLinux OS Foundation Board of Directors
Even Oracle (yes, Oracle!) thought it is a good time to talk about the value of Open Source.
And perhaps that is the real answer to the question of why: eliminate competitors. Fewer competitors means more revenue opportunity for IBM.
One might say: "There is/was some heat".
The future looks bright
Well, how do we go from here? Each of the communities came up with an idea how they want to continue. Let's take a look.
RockyLinux wants to find ways to get access to the SRPMs anyway. It seems like Gregory Kurtzer is super eager to provide a bug-per-bug compatible RHEL clone. I am not sure why, since he seems to hate Red Hat from the bottom of his heart.
These methods are possible because of the power of GPL. No one can prevent redistribution of GPL software. To reiterate, both of these methods enable us to legitimately obtain RHEL binaries and SRPMs without compromising our commitment to open source software or agreeing to TOS or EULA limitations that impede our rights.
AlmaLinux has chosen to migrate to CentOS Stream as upstream and provide an ABI-compatible downstream variation. This makes them effectively their own distribution and allows people to fix bugs or get features not existing in RHEL.
For a typical user, this will mean very little change in your use of AlmaLinux. Red Hat-compatible applications will still be able to run on AlmaLinux OS, and your installs of AlmaLinux will continue to receive timely security updates. The most remarkable potential impact of the change is that we will no longer be held to the line of “bug-for-bug compatibility” with Red Hat, and that means that we can now accept bug fixes outside of Red Hat’s release cycle.
benny VasquezChair of the Board, AlmaLinux OS FoundationLastly, SUSE has something to say, too. In 2021 the company already forked RHEL under the name "Liberty Linux". This approach seems to be pulled out again and SUSE wants to start providing their own RHEL derivate.
Embracing a mixed platform strategy helps prevent vendor lock-in, allowing businesses to remain agile and adaptable. The flexibility to switch platforms when necessary, ensures organizations retain control over their IT destiny, unbound by the limitations or restrictions of a single vendor.
My opinion
Okay, okay. You want to hear my words about this whole thing? Here you go. Be aware, there will be my personal opinions. These might not be to your taste or even surprise you.
The change itself is harsh, yet understandable. After all, Red Hat is a company that is providing more upstream Open Source work than any other. Our Linux and FOSS landscape would look vastly different without the massive effort from Red Hat and other companies. In the end I am writing this article with the power of Open Source on a Fedora Linux machine, in a Firefox browser, using the Ghost blogging engine. Do I like that Red Hat closes the access to some sources, Firefox pushes Google and other services down my throat, or Ghost makes money with paid features? Surely not, but do I hate them? Of course not! I love Open Source and I know, that we only can become a truly open community by acknowledging the work and effort, different goals and drives.
This also brings me to Rocky Linux. Looking at CIQ (the support company by Gregory Kurtzer), RSFE (lead by Gregory Kurtzer) and the Rocky Linux project (led by Gregory Kurtzer). He seems very fast with blaming others and even have some deep down anchored hatred against Red Hat. I am not sure why he is so eager to rant about his own upstream and make his own life harder. But, he surely needs to come down from his toxicity throne of judgement.
And SUSE? Well, as a German, I am happy that SUSE is getting more attention. After all it is company from here. Anyway, I can only see one reason why SUSE is eager to support Red Hat-family systems. Their biggest customer (SAP) is no longer exclusively supporting SUSE Linux, but also has a huge partnership with Red Hat. It's not about Open Source or liberty in the "Linuxverse", it's about business.
Which brings us to the core of my opinion. We need to acknowledge that Linux can be a fully open, totally free hobby project, OR we have to admit that somebody makes money with it and helps it to grow for customers. No company will ever, ever invest in Open Source, if they cannot see value for their own growth.
Docs & Links
In addition to this article, you might want to take a look at other sources and bloggers out there.
benny VasquezChair of the Board, AlmaLinux OS Foundation
Jens Kühnel
Ben Cotton
Conclusion
For me, Red Hat is valuable as an Open Source company, not only for RHEL but for a massive impact on how Open Source works. One might say, I am able to write this article, since Red Hat paved the way for me and created tools for my work.
But, is it OK to limit the access to source code? Let me know how you think about it, which parts I might have skipped and how you will continue.
