Impact of RHEL Changes to AlmaLinux
almalinux.org
almalinux.org
A bunch of the software in the customer portal is GPL, which says:
"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."
Do you honestly believe that Red Hat and IBM's army of lawyers don't understand GPL?
second however, it seems that there is a growing conceit among the cloud-native management, that they can ignore GPL, throw it into code-regrinding services, and generally act with impunity.
In this case? Absolutely not. I'm yet to hear someone with legal training say this might be a problem.
> second however, it seems that there is a growing conceit among the cloud-native management, that they can ignore GPL
Red Hat isn't ignoring the GPL. I'd don't see the relevance of this digression.
And this is Red Hat we're talking about, one of the few companies that managed to build a sustainable business around mostly GPL-ed software.
The best I think we can hope for is individual engineers that have a major stake in important software deciding to leave the company.
Think of it this way: The GPL doesn't obligate Red Hat to accept all customers in the first place, right? If you stop paying for your RHEL subscription, the GPL doesn't oblige Red Hat to continue it and continue distributing future releases of RHEL to you.
But even if you stop paying, you still have your GPL rights for the versions you received.
The only difference here is Red Hat saying "yeah, we're not taking your money anymore. Enjoy the source code and binaries you've received so far, but you're not getting new ones from us."
(that's where this is surely going, right? Or else they're just not going to bother actually trying to enforce this policy change, and let all these 3rd parties use alternative methods of obtaining the source)
How is saying "you haven't distributed my source code, I'll sell you the next version too, if you want" imposing a further restriction on anyone?
> 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.
I'd say that refusing to do further business counts as a retaliatory restriction against the recipients' exercise of their rights. In general the law finds against retaliatory business practices.
(Not that fighting a legal battle with IBM is something you can realistically do without losing your business, of course. But legally, I think one would have grounds to.)
Doesn't this change affect Oracle Linux too? Suing people and even big companies is Oracle's favorite thing to do, and for once they'd be the good guys for doing so.
Paying enterprises that decide to go with Oracle Linux are the real threat to RHEL not the free alternatives.
Very few people that are on the free alternatives will start paying for RHEL if the alternatives go away, it is more likely that they move to another distribution.
This is not even the first time Red Hat try to make Oracle life difficult.
"In the immediate term, our plan is to pull from CentOS Stream updates and Oracle Linux updates to ensure security patches continue to be released."
Not sure how long it lasted. It doesn't seem live now, though.
https://www.theregister.com/2011/03/04/red_hat_twarts_oracle...
https://www.theregister.com/2012/11/12/oracle_launches_redpa...
refusing to sell you version 6 isnt a restriction on what you can do with 5. it is terminating the relationship going forward.
It seems to me like Rocky wants to stay in bed with RHEL for unknown reasons, so they're playing nice. If there wasn't some benefit to doing so, they could simply anonymize their sources and RHEL et al couldn't prevent them from doing so.
An example of an illegal restriction would be if Red Hat gave their binaries to everyone publicly but only their source to people who agreed to not redistribute it, and then if you did redistribute the source they cut you off or brought some type of legal action.
Red Hat says "bye, enjoy distributing that, no more RHEL for you." You still get to distribute what you already have. That's what the GPL entitles you to - it does not entitle you to a business relationship with Red Hat, ever. But your ability to distribute that source is preserved.
Red Hat releases 10.1. They do not have to distribute that to you, nor give you source code, you're no longer a customer.
Whether this is in line with the spirit of the GPL or not is another story. But at least as I understand it, it does not violate the GPL.
I'm fairly zealous about Free Software and I don't think this is even against the spirit of the GPL.
Many of the writings and talks from RMS on gnu.org talk about how it is perfectly fine for a company to modify GPL'd software for internal use only and not be required to redistribute those changes because you're not redistributing the binaries. If it is fine for companies to do that and not be considered a bad actor violating the spirit of the GPL this seems to me to be in the same moral sentiment. At the end of the day if you have the binary you have source and all 4 freedoms associated with it and you truly control your computing.
Although without legal teeth, in practice wouldn't this become very challenging to keep enforced? The Acme Linux person would be free to conspire with someone who was still a customer of Red Hat, get the 10.1 source code from them (they too could be banned but that's it), and then go ahead and distribute that. RH would have no way to compel the Acme Linux group to reveal who they got it from, they aren't committing any infringement and neither is whoever gave it to them. RH could try to fingerprint the code they gave each customer, but this would be trivially revealed by getting 2+ sources and doing a diff. If RH was tiny with a tiny customer base of small businesses then that could work, but they're so gigantic and with lots of gigantic business customers with 4/5/6 figure employee counts that preventing anyone so much as employed at any of these businesses from making copies of the code and uploading it wherever seems like quite a lift? Obviously said employees could be fired if caught, RH can try to incentivize customers. But still, with proprietary software at the end of the day there is copyright to fall back on as the big stick at the bottom. Copyright affects incentives not just on possible distributors but also consumers, yes someone purely interested as an end user for free might be happy with pirated software but nobody can build new businesses on it and devs even vaguely in the same field are not going to want to even look at it.
But with OSS someone just anonymously uploading each new version of RHEL isn't committing a copyright violation. Neither is anyone downloading/using/redistributing further. So this seems like it'd be hard to do a foundation of. It sort of has the feel of IBM going through the familiar motions it would with proprietary software, but the underlying foundation makes it all different. Another argument is people just wouldn't want to bother going through the trouble, but that too seems somewhat self-balancing? As-in, the more important RHEL's position is and thus the more valuable it is to RH/IBM, the more incentive people have to keep steadily sharing each new version. Conversely if the rest of the world mostly moved on and RHEL became more like IBM's mainframe stuff (still high profit margin but rarely thought of in day to day work beyond a small sphere these days) then the incentive to leak would shrink, but it wouldn't matter anyway.
It's been awhile but I feel like this sort of debate was had in the early 00s back when copyleft was all fresher, just starting to really break out into big business, and more subject to serious legal challenges. And the conclusion was that (assuming GPL held, which it has) while there are a number of theoretical legal ways to sort-of-if-you-squint do a more traditional (non-service) proprietary model with it, the practical realities of trying to do that without the law on your side would be hard. Guess we'll see how that plays out though with a very powerful player trying it?
Well, enforcement is entirely another matter. It might turn into a nightmare of whack-a-mole for Red Hat, I have no idea. I'm only saying that AIUI, Red Hat can do what they're doing and still be GPL compliant.
It may impact the clones' ability to claim "bug-for-bug" compatibility with RHEL, though. At least without making them a focal point for lawyers. But I have no idea how things will spin out from here.
"Conversely if the rest of the world mostly moved on"
This is looking like a possibility. Things are pretty fragmented now as it is with RHEL leading paid Linux, Ubuntu leading unpaid Linux, and each major cloud provider have their own Linux offerings + Ubuntu & RHEL. (Also Debian in there..)
I don't know that this is the smart move by Red Hat. It feels like a gamble to me, but it's theirs to make.
I guess that Legally this would have to be revealed once ACME gets sued. That sounds like an endless game of whack-a-mole to me though.
I don't know what the current situation is but Grsecurity operated under a similar arrangement back in the day.
Weren't they violating the GPL too? https://perens.com/2017/06/28/warning-grsecurity-potential-c...
BTW, how could Red Hat identify the person who "leak" the source in the internet?
> We cannot speak to Red Hat’s intentions, and can only point to the things they have said publicly. We have had an incredible working relationship with Red Hat through the life of AlmaLinux OS and we hope to see that continue.
Reading between the lines, it sounds like they have a similar relationship to Red Hat that I do: tons of great folks who still work there and weren't burned by the IBM acquisition... but officially it doesn't seem like community downstreams that filled in the role CentOS used to play have a good relationship with Red Hat.
Otherwise this change (which some people are saying is fine, just poorly communicated) would've been announced with time for the community to adapt to it, rather than being announced in a blog post a week or two after the technical/process change was made!
They also lack the ability to whack-a-mole people legally sharing source code with distro maintainers. Their only way out is to close-source all of RHEL, which, good luck re-writing all that GPL code... not gonna happen. Not to mention, even if they did, they'd end up in a compatibility nightmare, where they're constantly fixing packages when GNU diverges from what they've done internally, or package maintainers intentionally making it difficult to run their packages on RHEL-OS, which will absolutely happen given the amount of bad blood they'd create from all that.
This move is clearly to make it more difficult for Oracle, and I'd imagine they'll keep playing nice with everyone else because it's in their best interests to do so.
Of course, RHEL (or others) could say that if you're depending on a free product, you're to blame. That's where I would disagree a bit. Many of these really large customers could just have easily chosen Debian, or something else. They simply don't need and don't want to pay for support. With Alma/Rocky, they had a perfect option, a no-support, free EL distro. RHEL did not lose these customers to Alma/Rocky. Those customers would have just chosen a different free distro.
This is downhill for RHEL
It has been since IBM's acquisition ans we can't even say we're suprised. Capitalism greed destroying something that was perfectly profitable already…
If you are paying for RHEL and are willing to switch on principle, then tell your sales rep that, too. If enough RHEL customers drop RHEL for this reason, that'll have an impact.
But if your business is using a RHEL clone because you want what RHEL provides, but for free, then consider paying for RHEL. Or go ahead and switch to Debian and see if the costs associated with switching and staying on top of a community driven distro outweigh what you save not paying for RHEL.
Clearly the enterprise market is moving, as once in the US every vendor would mainly only support RHEL, now I am seeing most support both RHEL and Debian\Ubuntu
> Under the current support model, each major version’s stable branch is explicitly supported for 5 years, while each individual point release is only supported for three months after the next point release.
It's also easier to upgrade between FreeBSD major releases than RHEL and clones.
For the first time in my life, I'm considering Debian (and derivatives) for my systems.
Rocky and Alma might be able to survive the changes, this time. What happens when IBM doesn't squeeze enough revenue out of RH? More changes?
I've used Fedora on my personal workstations forever it seems. But, spend enough time in linux-land and you'll find out there's two very different ways of doing things. There's the Debian Way, and the Red Hat Way. You tend to want to know one really well, even if you can "get by" on the other. (yes, other ways do exist - but they are much more niche)
So, if my servers go Debian (and/or derivatives), so will my personal workstations.
For enterprise Linux at least.
On my home systems I usually use Alpine or Arch, both of which are distinctly unlike both Debian and RHEL.
I suppose that's really a matter of taste though,
Yum/DNF are _extremely_ featureful package managers.
They have many nice capabilities, a higher degree of logging, etc.
However, they're complex and slow. From the UX side of things, RHEL-like distro's seem to put the most focus on ease of use/vring a complete system out of the box.
Arch/Alpine focus on a being much lighter, in the UI, default packages, and distro config. I would probably classify Arch/Alpine as their own minimalist family of distro's
Our k8s containers are generally either the build-tool's default (usually ubuntu or debian) or we specify the alpine version. You are right though, for containers, caring about the distribution is generally not a concern.
That is going to stop. I've been on Fedora non-stop since Fedora 17 (and a few times distro hopping before that) and 3 days ago I would have said there's no way I'd consider switching. But I'm putting serious thought into it. I'm going to wait and see how this shakes out, but if the end result of this is that there isn't a workable free RHEL clone, I might just switch. I don't like the Debian way of doing things, but I don't see any other viable options for running the same thing on both local and server. It's really too bad there isn't an Arch server version :-D
I also had the unfortunate experience of just moving one of my servers from Debian to Alma Linux to match my desktop, but I'll likely rollback now.
And I say this as someone whose first distro was CentOS. That died long ago. Were there actually people who didn't migrate to Ubuntu/Debian who went from CentOS to [other stuff]? It just blows my mind
Though now I'm on arch sooo... there are many paths I suppose
Just because it makes no sense to you does not mean it does not for lots of other people. The reasons for that are probably as varied as the users themselves.
Outside of the desktop, yast is the first thing many sysadmins disable.
Source: I once professionally managed a cluster of SLES and OES servers for delta.
One of the first things we did was “chmod -x $(which yast2)” and disabled some of the other tooling so people didn’t run it and mess up configs we did with config management.
Plenty of businesses and individual were looking for exactly what CentOS (and to some degree, RH) offered - namely stability over the long term. Lots of ecosystems and infrastructure out there still based on RHEL/CentOS, and I'm predicting it will take a decade before we see a major downtrend.
I will say though that anyone who isn't watching this whole thing unfold and planning to move to other systems as a result is probably in for a rude awakening at some point.
It’s not quite the same as the snapshotted version, but it’s still really good.
E.g. that if you hit a bug with the kernel, GNOME, Ceph, OpenShift, libvirt, or any such software, you get priority (and phone) support from the company that employs many developers of said software, and they are paid to fix your bugs more quickly.
Since I have not had a RHEL subscription myself: Is this accurate in practice?
Red Hat cutting back RHEL source availability - https://news.ycombinator.com/item?id=36420259 - June 2023 (296 comments)
Does this mean that Oracle has an arrangement with RedHat/IBM that won't be disrupted by this change?
While IBM/RH is unlikely to outright name Oracle as the reason I think it's clear they are the basically the only big player selling support contracts for what is essentially RHEL and undercutting them.
Red Hat are eliminating a user vector/funnel here.
So yes, what Redhat did sucks, but there have always been a much larger battle between the Microsoft, IBM & co running in the background. And it is an ugly one in which free software & open source are caught in the middle.
I think they won't find any other solution than this. Maybe create an Ubuntu Pro clone? If Ubuntu pro patches are even open?
If the line of reasoning you and others are proposing was sound, I could sell GCC with source code, then change a line of code and thereafter sell it as MyBestCompiler without ever distributing source code again.
> Can you just use CentOS Stream sources?
> No, we are committed to remaining a downstream RHEL clone, and using CentOS Stream sources would make us upstream of RHEL. CentOS Stream sources, while being upstream of RHEL, do not always include all patches and updates that are included in RHEL packages.
I don't rely on Redhat anymore (except for OpenShift) and fully switched to SuSe contracts now but i am happy with Redhat contributed technology to the Linux world.
Unfortunately, Alma and Rocky are going to get caught in the crossfire on this one, people are acting like this was some targeted thing at Alma or Rocky - honestly, they are likely barely on IBMs radar, this is aimed at Oracle.
Now, if the commercial product is the stability itself(!), why 'd you expect that stability for free?
Why should Red Hat customers pay for other, non-paying enterprise users?
What about the CentOS users who report bugs, or help out with (say) writing RHEL docs without getting paid? You're saying they're freeloaders too?
That sounds like a pretty crappy viewpoint to me, as I used to do all of the above.
I did personally read the writing on the wall correctly though, with the previous major "CentOS 8 Stream" change (after the IBM acquisition). So, switched all of my stuff away from Red Hat based software at that point.
It also feels like a moment of opportunity for SUSE, but they seem quiet.