Thoughts on the Red Hat Source Issues
By EricMesa
- 6 minutes read - 1083 wordsNow that we’ve had a few months to consider Red Hat’s new course code policy, I wanted to share my thoughts since I’ve been a user of Red Hat’s Fedora since it started back in 2003. I’ve also made heavy use of CentOS and am currently running a server using one of the free RHEL licences that came about from the CentOS Stream controversy. I want to start off with my thoughts and then how I think we may end up in a better place anyway.
First of all, I’m shocked that this is the third time that Red Hat finds themselves in this situation. That said, Joe Brockmeier makes a great point in the sixth entry of his series Red Hat and the Clone Wars. In this entry he’s talking about when Red Hat stopped releasing kernel patches in a way that made it very easy to clone RHEL:
Then again, here’s the conundrum for Red Hat trying to span the gulf between open source communities and the cut-throat tech business. Red Hat saying “hey, we’re going to stop doing this” gives its competitors time to adjust strategy. In an industry where you’re only as good as last quarter’s numbers, those days and weeks matter.
Joe Brockmeier - Red Hat and the Clone Wars VI: Obfuscating Kernel Code for Fun and Profit
See, the problem is that Red Hat has a free rider issue. A lot of people on the web have become very incensed at this terminology from Red Hat, but it’s incredibly true. Just like recent issues with Elastic Search and other open source projects, there are too many large companies who are suffocating the goose laying the golden eggs. In the past, I don’t think it was ever really costing Red Hat any real money that some businesses were using CentOS instead of RHEL. Each user of the RHEL ecosystem (including CentOS, Scientific Linux, and others) increased the value of RHEL. It made it more valuable for vendors to target RHEL as a supported OS. It trained folks on the Red Hat platform. And it created a set of companies who MIGHT go to RHEL for support (their money maker) if they grew larger than they could support on their own. But this model falls down if Oracle is there to potentially scoop up those customers. Red Hat contributes a ridiculous amount to Linux and the kernel, but those engineers cost money. And, as we all know, Oracle is hypocritical. Again from Brockmeier’s post:
Oracle’s announcements at the time said that the Ksplice git repo would be moved to oss.oracle.com, but I’ve been unable to find a git repo for KSplice. There is a tarball but it doesn’t seem to be current. If you’re following along, Oracle complained (and complains) about Red Hat’s not breaking out patches or publishing source in a way that is most open. Then Oracle acquired Ksplice and … stopped publishing patches. For a while, Jiri Slaby provided a repo on GitHub with more recent patches but that seems to have lost interest.
Joe Brockmeier - Red Hat and the Clone Wars VI: Obfuscating Kernel Code for Fun and Profit
So while it would be awesome if Red Hat could break out the kernel patches, support CentOS along with CentOS Stream, and leave access to the sources out there, we don’t live in that world. That world seems to me to be the same kind of sunshine and rainbows world in which communism would work correctly rather than as a leftist totalitarian regime.
On to the potential silver linings!
Let’s start off with Rocky Linux. It started off as one of the protest distros when CentOS went to CentOS Stream. I’ve been fine with CentOS Stream for some of my VMs, but I’m not running business-critical servers. So, for folks who have business critical servers, but can’t afford RHEL, there’s Rocky. According to their blog, Rocky thinks they have found a legal workaround or two:
One option is through the usage of UBI container images which are based on RHEL and available from multiple online sources (including Docker Hub). Using the UBI image, it is easily possible to obtain Red Hat sources reliably and unencumbered. We have validated this through OCI (Open Container Initiative) containers and it works exactly as expected.
Another method that we will leverage is pay-per-use public cloud instances. With this, anyone can spin up RHEL images in the cloud and thus obtain the source code for all packages and errata. This is the easiest for us to scale as we can do all of this through CI pipelines, spinning up cloud images to obtain the sources via DNF, and post to our Git repositories automatically.
Maybe that will work and maybe it won’t. In the end, I don’t think Red Hat will care as long as it’s just Rocky. If Oracle, SuSe, and others go down this path, then I think the lawyers will get involved.
I think a better silver lining is what Alma Linux is doing. This ars technica article mentions that Alma Linux has decided that they will no longer go for 1:1 bug compatibility with Red Hat and will instead go for ABI compatibility. What this gives them is the ability to actually become more creative than RHEL. They can be more of a fork and try to go off and improve in ways that work best for their users and customers. As long as they don’t change in certain key ways, any program that runs on RHEL should also run on Alma. I think this leave us with a much better ecosystem. I find that when we have compatible down streams we allow everyone to benefit. Because if they’re remaining ABI compatible with RHEL, then if Red Hat sees Alma doing something really great that Red Hat’s customers would like, they should be able to “easy” bring that feature up into RHEL (for a certain value of “easy”).
So I don’t think there’s as much of a need for panic or antagonism as many folks have expressed given Red Hat’s change. Red Hat remains a business that needs to make money and it cannot do so if there are parasitic relationships taking advantage of its stewardship of open source. Is it the world I want? No. But it’s the world we have.
the featured image was created by AI using the prompt: a man in a red fedora wearing a karate uniform