AlmaLinux project climbs down from being a one-to-one RHEL clone The AlmaLinux distribution's goal is shifting from being one-to-one, bug-for-bug compatible with Red Hat Enterprise Linux (RHEL) to being application binary interface (ABI) compatible. But this represents a larger shift in the enterprise Linux market. Management has published its third statement of direction following Red Hat' …
I'm surprised to hear that "it would be hard to prove in a court of law"; the license under which Linux is distributed is clear and unequivocal: you can freely make and distribute copies of Linux, either identical copies or copies you have made changes to; there is no restriction on what you can charge for them (after all, blank CD-ROMs cost money); but you may not place any restriction on the ability of those who recieve those copies to copy them themselves.
Red Hat's license for RHEL is now no longer compliant with that last condition of the GPL. Not all of IBM's lawyers should be able to obfuscate the fact that the GPL means what it says, and says what it means.
Of course, though, it is understandable that those responsible for Linux are loath to take drastic steps, like withdrawing IBM's license to use and distribute Linux for this violation.
"Are we heading for another SCO Linux type feud ?"
Quite possibly, and I hope that there is a legal challenge at some stage resulting in a court judgement that then clarifies the situation about what is and is not permissible. That might then guide the wording of future opensource licences to prevent the IBM-Red Hat situation from occurring again.
[Author here]
> Red Hat's license for RHEL is now no longer compliant with that last condition of the GPL. Not all of IBM's lawyers should be able to obfuscate the fact that the GPL means what it says, and says what it means.
[1] RH has a lot of lawyers. IBM has more. Do you really think that they did not check? Do you think the company would do something as drastic as this without first being absolutely certain it could defend its actions in court?
[2] The GPL is only one among many licences in a Linux distro. RH knows perfectly well that it has to accord with _all_ of them.
[3] You are missing at least two points here.
* The GPL says you have to provide the source _to the people you supplied binaries to_. You don't need to do it for free -- you are expressly permitted to charge for the service -- and it does not require you to give source code to anyone else whatsoever.
* RH's users _can_ give the source away. However then RH can simply end their contract and they cease to get updates. That too is 100% legal and GPL compliant.
> * RH's users _can_ give the source away. However then RH can simply end their contract and they cease to get updates. That too is 100% legal and GPL compliant.
This is what the courts will need to decide at some point, assuming someone can afford to risk a pop at this.
It could well be the case that a court somewhere in the world deems that the threat of terminating you as a customer counts as an additional restriction. Only providing source to customers is allowed. Terminating customers is allowed, but there are limitations on this for example you can't terminate a customer's contract based on their colour. Here purple hat are publicly stating that they may choose to terminate a customer based on them doing something which they are allowed to do by the terms of the license.
At the moment I think it is a case that purple hat are playing the I've got more lawyers than you can afford game. I think that this approach should be made illegal, but I'm not naïve enough to expect it ever will be.
@Liam Proven "RH's users _can_ give the source away. However then RH can simply end their contract and they cease to get updates. That too is 100% legal and GPL compliant."
But is it compliant with contract law? Can the RH contract penalise a user for exercising their rights under GPL, by ending the RH contract. Is that not an unfair contract by asking the user to sign away their rights.
Is that not an unfair contract by asking the user to sign away their rights.
Eh? In the US, at least, contracts restrict parties' rights all the time. My mortgage, for example, forbids my renting out the house.1 Restricting rights is one of the main things contracts do.
That's what makes certain rights "inalienable" – they can't be forfeited. Other rights can be.
1Presumably to combat the plague that is AirBnB, which I'm fine with. Unfortunately it also prevents using the house as a long-term rental, which we might want to do in the future.
[Author here]
> But is it compliant with contract law?
1. I am not a contract lawyer. IANAL at all, and I do not play one on the internet. However, I do think that a company that makes billions of dollars selling maintenance contracts absolutely 100% does have contract lawyers. Lots of highly skilled ones. I am therefore confident that I can't judge, but IBM/RH very definitely *can* judge and did judge before doing this.
2. Exercise critical thinking! Follow the money! Yes it is legal, *because they did it.*
3. Exercise cynicism! IBM is rich. IBM employs lots of people. Its software runs governments. It has influence. Yes it is legal, because IBM is rich enough to ensure that if it were not legal when it did it, it will become legal if it ever got tested in court.
4. See @Michael Wojcik's post above mine. He hits the nail on the head.
Except it's NOT legal or GPL compliant. It's a "further restriction" on distribution rights guaranteed by the GPL.
If RH does terminate anybody's access and claim this contract allows them to do it, they lose ALL rights to distribute whatever GPL code they've denied access to.
They're not just violating the spirit of free software, they're violating the letter.
Can they get away with it? Maybe, but that doesn't mean it's actually legal, because it absolutely is not.
If RH/IBM say it's okay and most importantly the FSF don't say it isn't okay - then who are we to argue?
BUT I certainly don't subscribe to Liam's "well they're rich and have lots of lawyers and say it's legal so obviously its legal" point either though. The reg is littered with articles of lawyers for huge corporations being wrong, losing fights against other huge corporations and even just outright committing crimes and facing prosecution.
RH are still providing source to customers - people who have recieved their binaries - so they are not in violation of the GPL, legally speaking.
They may be violating the spirit of open source or what people understood the GPL to mean but strictly speaking they are in compliance with the law no matter how much we dislike it.
The GPL says nothing about rights of access to updates to the binaries/source you have previously been supplied with.
It’s going to need a very good argument to show how restricting your rights to an update service restricts your GPL grant rights to do what ever you want with the source code in your possession, covered by that specific GPL agreement. Ie. V1.0 and v1.1 releases are shipped under separate GPL agreements, the lawyer will need to argue they are (along with any future update) supplied under the same GPL agreement.
I have serious doubts that Rocky Linux will reliably be able to continue with an exact clone of RHEL. Red Hat can just keep tweaking their T&Cs to exclude them, leaving Rocky scrambling to try to find another loop hole.
This fragments the "RHEL compatible" market, including for Red Hat itself. I tested my (free/open source) software on Alma. Will it run OK on the current release of RHEL? Who knows? I'm certainly not going to sign a contract with Red Hat in order to find out.
Without the derivatives being exact clones, it raises the question of just what is the raison de'etre for any of the RHEL clones? They can say they are testing applications, but they won't have copies of the proprietary enterprise software which is tying customers to Red Hat, so how will they do that?
As I've mentioned before, I have several minor free/open source projects which I maintain. I've been testing them on Centos, and later on Alma Linux as substitutes for RHEL. If there are no exact RHEL clones, then should I even bother testing on RHEL equivalents or should I just delete that VM and save some time and disk space? I test on various other LInux distros (and BSD), so perhaps I should leave it at that and tell any RHEL users that there's nothing I can do if they have any problems.
I'm sure that Red Hat aren't going to lose any sleep over whatever decision that I make (I doubt they know that I even exist), but it does make me wonder how many other developers are in the same boat and will make the same decision.
Lots of other developers are in the same boat and are making the same decision.
While most people probably won't use your particular obscure project, most people use some obscure projects. Lack of support for these is the reason why for example most of the Android clones don't go anywhere, so I think it would end up being the same on Linux.
If there are no exact RHEL clones, then should I even bother testing on RHEL equivalents or should I just delete that VM and save some time and disk space?
Don't bother with RHEL testing from now on, if a RedHat customer wants to run your application and there are problems they should get on to RedHat support and it will be up to them to fix and submit patches - the customer is paying enough for it.
"so perhaps I should leave it at that and tell any RHEL users that there's nothing I can do if they have any problems."
I've been doing that for all of the commercially licensed Linus distros for over a quarter century. Doesn't seem to have negatively affected my bottom line.
Probably doesn't hurt that I target the BSDs and Slackware ... if it runs on them, it should run anywhere.
Might it not be worth making things incompatible if possible from now on. No need for developers to stop being open source, RH or its users could still fix it if they wish. But they'd have to spend the time / money to do so. If they suddenly found that hundreds of applications were no longer instantly compatible with their OS product, they might realise what a pain in the arse they've been to others in the open source community.
I do feel for them and it is a logical way to proceed given that IBM-Red Hat has now made it as difficult as practically possible to produce an exact one-to-one RHEL clone.
While they won't get an exact replica of RHEL, what AlmaLinux users will get is a very familiar environment which should be relatively easy to transfer to.
GPLv2
6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
I expect that the point is that there is no restriction on a recipients' right to redistribute: they can redistribute to their hearts content. The only restriction is that they can no longer be a customer of RH. I'm sure lawers could argue either way (see icon - they're here to take your dabloons), but it seems relatively coherent to me.
Oh and in the GPL it looks like you don't charge for supplying the source code. You can charge for suppling the binaries whatever you like, but then the recipient automatically get a right to the source code with the binaries. This stops organisations saying the code is $N and the source is $1000,000,000,000 x N
It's also worth noting that while RedHat moans about other people using it's output without payment it gets much of it's input without payment too. As an Enterprise I was paying for the support more than the code. Of course now I won't be paying for either because I no longer trust RedHat (and certainly not IBM).
Linux has over its lifetime been faced with the claim that it has too many distros. And no standardization. While Red Hat ltd has claimed that it was the standard, since it was the Enterprise distro.
It now looks as though that will change. The free/community projects like CentOS and Scientific Linux etc, were part of that. Now they're not.
Red Hat/IBM have just removed a part of what made Red Hat the standard Enterprise distro, and now they are going to find themselves competing. IBM showed during the 90s it wasn't competitive, didn't know how to compete, and gave up a lot of territory it had formerly thought it owned.
I for one would love to see SUSE become the more favorable choice. Why? In all honesty, they think "enterprise" a whole lot better than Red Hat did/does.
IBM as one of the bigger exploiters of Linux without giving back too much, just really wants something "internally" that they can leverage for their closed source solutions. Having Red Hat (or whatever IBM may call it in the future) gives them what they want. IBM just wants people to buy IBM (closed) stuff. And now they have the platform to aid with that.
Sure, I'd love to hang on to the Red Hat of old, but the last vestiges of that went away shortly after the acquisition by IBM. The "promise" of not touching Red Hat, well.. it's just too hard to keep alive a truly independent culture inside IBM. As for old Red Hat, I still miss you. And again, just for old Red Hat, you did good.
I'm somewhat surprised it isn't. actually. Because SUSE does a lot of things right, their enterprise offerings and the support they provide are great, they are a huge contributor to Linux and FOSS in general, they even went the opposite way of RH and aligned the community version (openSUSE Leap) with their enterprise Linux by not just giving them the actual sources but even allow openSUSE to use the the actual SEL repositories. And aside from Linux, SUSE has a ton of other interesting products such as Rancher, Harvester or RKE/RKE2. All which can be used for free if one is inclined.
Yet, following the RH debacle, there seems to be more interest in Ubuntu than SUSE. Despite Ubuntu's propensity for bugs (it's known as "Windows amongst Linuxes" for a reason) and Canonical's propensity to give back little to the community (less so than even Microsoft). But perhaps it's that spiritual closeness to Windows that makes Ubuntu so attractive, who knows.
A cleanly-separated base OS, a single, central package repository which is actually kept up-to-date with upstream versions, and a much more sane approach to development. It supports the base system being made immutable without undue complexity and solves most of the problems Linux is currently trying and failing to tackle with Flatpaks/Snaps. With enough of a push from technology companies, it would make for some solid competition.
FreeBSD replacing Linux is little more than a pipe dream. It's hardware support is woefully out of date, the number of contributors is minuscule compared to Linux, and most businesses that are active in the Linux ecosystem are unlikely to have an interest into migrating to an operating system which, assuming it still has a future, has yet to see the many improvements and functionality that are in the Linux kernel today.
There's certainly a place for the *BSDs, but in terms of becoming the mainstream UNIXy operating system their train has long left the station. Even for embedded devices, Linux has been replacing *BSD for some time now.
I also fail to understand why you believe the fact that a single Linux vendor (Red Hat) going anal regarding access to their enterprise Linux source code makes a good case to completely abandon the Linux ecosystem in favor of FreeBSD. Because that's quite a stretch.
> central package repository which is actually kept up-to-date with upstream versions
My downvote (sorry) mirrors the other comment. But to add - it doesn't suit enterprise exactly because it mirrors the upstream so closely. In my opinion. Then your compatibility and updates are affected by people all pulling in different directions for features Vs stability.
What I hear when you say that might be wrong, but I hear "rolling distro". And as someone who uses a rolling distro - it's the bane of my life. If that's the model even if BSD is stable now as rolling, once development ramps up and people migrate over it wouldn't and couldn't avoid the same issues.
>> Debian is here to save the exiles from the falling RHEL derivatives world.
Right, because a community distro created by an often activist group of volunteers (many which can't even write a proper bug report) with a track record of making severe errors along the way (including the world renowned OpenSSL debacle) and a very strange understanding of what a 'mature' package is, is definitely a great replacement for an enterprise grade Linux distro maintained by a large vendor with tons of experienced professional developers.
Just looking at Debian's interpretation of "LTS" gives me shivers.
Suggesting Debian as an alternative for RHEL and clones only shows that you don't understand why these clones exist in the first place.
Debian LTS project gives a commonly used subset of packages (equivalent to RHEL) security-only support until the 5 year mark with the caveat that fundamental design flaws which involve replacing a major version of a package cannot be serviced. After that, the ELTS project guarantees a further 5 years fixing major (I.e. high and critical) rated vulnerabilities to those who pay Freexian developers to service packages. Those who don’t pay can still benefit from their work for free, provided they’re using packages others have already paid for.
Last I checked, Greenbone pays Freexian for ELTS to keep their security appliance OS patched. Why would they pay if a free RHEL clone would suffice?
>> Debian LTS project gives a commonly used subset of packages (equivalent to RHEL) security-only support until the 5 year mark with the caveat that fundamental design flaws which involve replacing a major version of a package cannot be serviced.
That's far from equivalent to what RH does, which does not just offer security updates but general fixes as well (and they often backport new functionality as well).
Which is one of the reasons why RH's packages, while not being the latest, are usually much newer than the often antique versions that Debian stick with.
>> After that, the ELTS project guarantees a further 5 years fixing major (I.e. high and critical) rated vulnerabilities to those who pay Freexian developers to service packages. Those who don’t pay can still benefit from their work for free, provided they’re using packages others have already paid for.
Great, but that's still a far cry from what you get with enterprise Linux like RHEL and SEL and clones.
https://lts-team.pages.debian.net/wiki/FAQ.html
"How much resources does the LTS team have?
The work is handled by volunteers and by paid contributors. The latter rely mainly on sponsorship collected through Freexian. Freexian’s reports show how much hours are sponsored and what has been done during those hours."
My point stands: a community distro maintained by different groups of volunteers and a small business (according to LinkedIn, Freexian has less than 2-10 employees) is hardly a replacement for a Linux distro maintained by a large vendor with a professional development and QA operation.
>> Last I checked, Greenbone pays Freexian for ELTS to keep their security appliance patched. Why would they pay if a free RHEL clone would suffice?
I don't know, ask them, but I suspect they do because they probably sell OpenVAS to businesses which use Debian (like some web hosters do). Like they do to businesses which use RH (and clones), SUSE and others.
I'm not sure how you draw a connection from the fact that a SMB pays a small business for security updates for a community Linux distro to the idea that what Freexian and Debian offer would be in any way comparable to what one gets from enterprise Linux (or clones). Following the same argument, surely Windows must be a great replacement for the RH clones because, clearly, people pay for Microsoft support (which is crap). .
I've been disappointed by a lot of the reactions and reporting following Red Hat's changes to the channels through which they publish RHEL source code, and this article is emblematic of the problems.
"This is a fairly substantial climb down for the project"
No, it isn't. Alma's decision to build a distribution that isn't merely a rebuild means that they can provide more than helpdesk services to their customers.
They can offer real engineering support and actually solve bugs that affect the clients that pay them for support. That's value that they couldn't deliver as a mere rebuild.
If I'm trying to choose a vendor, one of whom will offer to accept my bug reports and fix problems that affect my production systems, while the other one strictly does no engineering and only ships bug fixes if they happen to be reported and fixed upstream, that's an easy choice.
I think this is rooted in a fundamental misunderstanding of what "support" means in the context of an enterprise environment. "Support" is not "tech support" or "helpdesk." It's a partnership with engineers who ensure that your operations are build on a reliable foundation.
"The German enterprise Linux giant says it's doing something significantly different: a free fork of RHEL."
I've asked what SUSE means by "hard fork", but I haven't got any answers yet.
That's not a well defined term, and there are a few things they might mean by that, but all of the things that are actually likely are *not* significantly different from what AlmaLinux announced.
SUSE is probably going to maintain a fork that branches from Stream in sync with RHEL in order to create compatible minor releases, and providing extended support for them, fixing bug and security problems without using RHEL's minor releases directly.
The Register is probably incorrect in claiming that SUSE's plan is "significantly different" from AlmaLinux's. They are most likely the same plan.
One thing I didn't see after reading the article, was any indication that the author tried to contact anyone at AlmaLinux OS Foundation, or any AlmaLinux customers, or any representative of Red Hat or the CentOS Stream project for comments or clarification.
If you're going to write something that looks like journalism, maybe it would be a good idea to ask the people that you're writing about if your conclusions are correct?
"and you have a low-cost way to reduce a competitor's profit margin"
Of everything in this article, this is the thing that disappoints me the most. It's not just a misunderstanding of how things work, but of fundamentally who we (the Free Software development community) are.
Namely, that we are a community. We do not win by causing someone to lose.
I don't know how many times I've seen Red Hat clarify this point. They are not trying to rule the world. They are not trying to eliminate their competitors.
This is actually one of the things that I respect most about Red Hat, and about the Free Software projects that they sponsor.
In short, the article demonstrates a fundamental misunderstanding of what enterprise support is, a lack of interest in being informed, and a desire to see some of the community's best and most productive developers fail.
Those things have been common among the many disappointing reactions over the last few weeks.
I don't know how to fix this, except to vocally reject every part of it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
