This week, IBM Red Hat made a big move. This is one of those moves, that, at the same time, our readers should have been prepared for. Red Hat moved RHEL source code behind its paywall for subscribers. This has huge implications for Alma Linux, Rocky Linux, and others seeming to leave only CentOS Stream, a testing release, as an avenue for IBM Red Hat’s source code. One thing is clear, IBM Red Hat does not want folks running anything in its ecosystem unless they are paying customers.
IBM Red Hat Puts RHEL Source Behind Paywall
In a release this week, IBM Red Hat says it is putting RHEL source code in the Red Hat Customer Portal (accessible via a subscription). The sole public repository for code releases will be CentOS Stream. After the December 2020 announcement that IBM Red Hat was abruptly discontinuing CentOS, the posture was that CentOS Stream would be a development distribution where changes would flow to RHEL downstream. One could get the source code for either distribution until this announcement.
“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.” (Source: IBM Red Hat)
Projects like Alma Linux and Rocky Linux sprung up effectively taking RHEL source code and building distributions to replace CentOS. Now, they have a major challenge since the available source code will be CentOS Stream, not the additional parts developed by the IBM Red Hat team. If they use CentOS Stream as a source codebase, then they are no longer downstream of RHEL and therefore have a different offering since CentOS Stream is not designed to be a stable production codebase.
“Before CentOS Stream, Red Hat pushed public sources for RHEL to git.centos.org. When the CentOS Project shifted to center on CentOS Stream, we maintained these repositories even though CentOS Linux was no longer being built downstream of RHEL.” (Source: IBM Red Hat)
Moving the code its developers worked on to behind a subscription paywall makes sense if the company does not want others to profit from its developers’ work. At the same time, one could argue that its development was furthered by other developers believing that their contributions would go towards the status quo and therefore worked on CentOS/ RHEL components instead of other distributions. It is certainly a sticky and charged situation for those outside of IBM Red Hat.
In the release, IBM Red Hat also mentioned how it is inefficient to have a public RHEL repository. It is too bad that IBM Red Hat did not just say “Hey, if you want something RHEL sourced, we want you to pay for it.” That would have been straightforward and easy to digest for folks.
Final Words
After Red Hat Goes Full IBM and Says Farewell to CentOS in 2020, it was obvious, Red Hat had a new corporate charter to convert open-source users to subscription users.
At STH, we have ~100 systems online at any given time for reviews, back-testing, and so forth. Years ago, for our test lab, we made the decision to adopt Ubuntu/ Debian over RHEL/ CentOS due to faster mainline hardware compatibility for several systems we were testing at the time. That may have been the incorrect reason, but as of 2020, we were glad to see that the choice to use Ubuntu over CentOS years prior was not leading to a major scramble.
If I put myself in IBM’s shoes, the moves make sense. Cut off CentOS the “free” version of RHEL. Make other alternatives less attractive to force anyone in the RHEL ecosystem to get subscriptions. That drives subscription growth for a few quarters. Once that growth cools, to increase revenue, the next step is to increase subscription prices for captive customers. This is a well-known playbook and with a pending Broadcom-VMware deal, RHEL can do this knowing another solution in the market will likely be doing the same thing.
VMware folks are already accustomed to a subscription model, but if the Broadcom deal closes, they should be wary of the same. Broadcom purchases companies like PLX and massively increases PCIe switch prices and pushes bundles. They even do that on simple components like 1GbE NICs. This is a HPE ProLiant DL325 Gen10 where the Broadcom NIC was depopulated after Broadcom massively raised prices on a commodity part that was designed into the servers. HPE depopulated the onboard NIC and moved 1GbE to an Intel i350 FlexLOM because of it.
For VMware customers, this move by IBM Red Hat and the impending Broadcom acquisition should be raising warning flags. Competition will plummet and subscription/ license prices are going to go up.
IANAL, but how is this GPL-compatible?
The GPL requires that you provide source to anyone to whom you provide binaries. Red Hat only supplies their compiled operating system (binaries) to paying customers. Therefore, they only need to provide the source code to those same paying customers.
GPL only says that you you cannot distribute binaries without source code. The binaries are only available to subscribers, so it’s enough that they make the source code only available to these subscribers.
The GPL does allow these subscribers to distribute the source code to others. But if they do so, they will violate the contract they have with RH. It’s not illegal, but RH can simply terminate their support contract. This support contract is independent from the GPL.
GPL requires access to source code for binaries provided. All RHEL customers will have access to source code, which meets the requirements of the GPL.
The GPL does not require source to everyone nor does it require a company allow redistribution of the source. So Redhat is within their rights to terminate any customer that redistributes those sources.
So making things hard for Rocky and Alma Linux is well within their rights.
What’s the point of RHEL compatible systems except to take revenue from IBM?
Instead why not go downstream from Fedora like RHEL and base a stable release on that while also keeping an eye on RHEL? Fedora is more appropriate anyway and RHEL < Fedora.
My Fedora Cockpit is v294 while current Rocky and Alma are at v286. How is that a good idea?
Linux kernel and the vast majority of a linux install is open source. Redhat’s value add is support. This allows organizations to run linux in as many places as they need on bare metal, in containers, and virtual machines. Then the org can decide which ones need support. If you force the community to CentOS stream, then you force customers to switch their OS when they need support, buy CentOS stream support from someone else, or switch to another distro
Can you see that this is against the spirit of open source and counter productive to the long term popularity of RHEL?
I can access the RH source code at: https://gitlab.com/redhat/centos-stream (and I am not paying RH customer). Are you familiar with a concept of basic fact checking? (before slandering someone).
It sucks for Rocky and Alma people. I think they’re screwed.
@noname if you read the quotes from Red Hat in this article, and the content of the article, Red Hat itself is saying it’s no longer pushing part of its code to that exact repo. So are you saying Red Hat needs to fact check itself? Or are you saying Red Hat is slandering STH? You are anonymous so I’m assuming you’re involved with Red Hat and didn’t check what your own company put out.
Interestingly Red Hat has the “Red Hat Developer Subscription for Individuals” which in order to comply with the GPL also has to provide access to the source code, but currently doesn’t. Just a matter of time before some one makes that happen.
this ship is sinking. abandon the ship
In response to “the GPL does not require a company allow redistribution of the source,” in fact the GPL does require derivative works too be distributed with the same license which means any paying customer who receives the source has the legal right to redistribute it.
What’s less clear is to what extent RedHat can retaliate against customers who do redistribute GPL licensed code. For example, is a support contact which says support is cancelled if you redistribute the GPL code under the GPL license compatible with the GPL or would that invalidate RedHat’s license to use GPL code in their operating system.
Probably the only thing that is behind a postal paywall are the automatic build scripts for the RPM packages. As these are not GPL derivatives, there is not a legal reason to make them public.
I am not involved with RH. And it was me, who did not get the facts straight… I misunderstood what I was reading (and I still can’t believe).
If IBM RH does not want to be OSS it should say so, instead of playing shenanigans with the GPL license.
IBM RH is doing this because they think they can. The future will show if indeed that’s true.
The argument of Alma Linux and others = free loaders = bad guys does not hold its water. IBM RH is itself free loading on thousands of packages. Yes, RH is participating to the creation and maintenance of multiple packages, but others do so. The whole RHEL is a derivative of these packages. And this is fine because it is how OSS works.
By putting the RHEL SRPMs behind a paywall, IBM RH does not violate the GPL for their customers, but it does violate the GPL from the packages authors viewpoint and the rest of the world.
Up to this new licensing, RH was selling support, now IBM RH thinks it is selling a product too. But there is a problem with this move: RHEL is not a proprietary software, it’s OSS.
The IBM RH license can say what it wants, but it can’t change the nature of GPL. Or will it?
I would not be surprised if ultimately this corporate gnawing at GPL finally triggers a lawsuit by someone, somewhere, sometime. In Europe?
thieves.
It sounds like a lot of rule-lawyering to me. In literal readings of the GPL, nothing stops companies from selling for profit solutions based on GPL code.
And they aren’t technically selling the software, but the intrinsically-linked support contracts for the software. (Without which, they won’t let you have access to the software.)
I wonder if/how this will affect Oracle Linux. Currently I use free for use download Oracle Linux in my home lab (as long as not using for profit or in a corporate production environment).
I suspect that this is mainly aimed at Oracle. However, I think it will have a chilling effect on the community of RH-like Linux users. I expect to see IBM killing the golden goose…
I actually stopped using RH after Red Hat 8 IIRC. That was the first time they tried forcing people to pay for using Red Hat.
I wonder if Canonical will get similarly greedy?
You can use the free developer license to run up to 16 Systems in production. Nobody is forcing you to pay for you to use RHEL in your homelab, or as a small business.
Whether sixteen systems is enough for a homelab is different than the hassle of dealing with license activation. At any rate, with today’s single-board computers and mini micro systems it’s easy for a home lab to have over 16 separate hardware devices–especially if the lab focuses on redundancy, fault tolerance and clustering.
On the other hand I don’t know how those free licenses work so maybe it isn’t so bad. How does the licensing requirement interact with VMs, Docker, Singularity and other containers? Are there problems with creating hundreds of RedHat-based Docker images and deploying them in a homelab where the hardware is not even running RedHat?
The difficulty as I see it is the same problem IBM has with the Power and Z architectures: There are no entry-level machines attractive to individual developers.
My opinion is in the case of hardware that entry-level for an individual developer means 8-core desktops with price and performance competitive to current AMD Ryzen systems. For cloud it means instances competitive with Oracle’s 4-core ARM-based free tier. For software, entry level means unencumbered by the need to register a license whether free or not when provisioning hardware, VMs and creating containers.
How about discussing what they actually have decided to do – they are limiting the access to their src.rpm’s which is their IP. Redhat have always pushed security and bug fixes upstream, meaning you can get the tar.gz with the source to all the binaries they provide – from upstream.
The src.rpm provide the source and the .spec which makes it easy to generate an .rpm – and that is something else than limiting access to source code. Redhat could actually just extract all the source’s from their src.rpm’s and provide them – there is nothing in GPL which talks about providing the build system – which rpm basically is.
I to some extend understand them, there are people who run CentOS/RockyLinux/ao. commercially, they maybe have a few RHEL licenses and when they run into a problem, they duplicate the problem on their RHEL servers and open a case with RHEL. On the other hand the hobbyist at home will be hit by this as they often do not have the money to by an RHEL license.
But it’s IBM and they have never really been customer friendly.
In the short run RedHat/IBM will make money from this, as customer will scramble to get their servers converted to RHEL to be able to get security fixes, but in the long run many of these servers will get converted to something like Debian or Ubuntu (I fear that ubuntu could pull the same one over time – no updates without money) and then RedHat will loose money.
On the other hand the enterprise needs support, and ofter they are willing to pay a premium to get it.
@casper I think you will find that the FSF consider a .spec file for a GPL package to be a derivative work and covered by the GPL. The issue wider issue is lots of packages in RHEL are not GPL licensed. There is plenty of BSD and Apache licensed code for which RedHat don’t have to redistribute anything.
It’s a short term money making scheme that destroys the value of the RHEL ecosystem to me as a paying RHEL customer. We are likely to go elsewhere for a mix of paid and rebuild systems. SLES/OpenSUSE LEAP is looking very attractive right now.