> Red Hat’s user interface agreements indicate that re-publishing sources acquired through the customer portal would be a violation of those agreements.
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."
It's not a violation, because every RHEL user is a customer, which has access to the source code.
They can't sue you for redistribution, but they can ban your account for breaking their T&C.
companies are not one unified thing, though they may project that and internalize that. You don't think that there is internal tension ? differing opinions among staff attorneys?
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.
Random company with a device and inconvenienced by the GPL is one thing, but it beggars belief that Red Hat, which has been working with GPLed code since 1993 that is one of the cornerstones of its business model, struggles to comprehend what GPL was intended to accomplish.
Except we're talking about IBM now, right? Red Hat is not the same entity it once was, although may still have some or many of the same engineers on staff.
The best I think we can hope for is individual engineers that have a major stake in important software deciding to leave the company.
Why haven't they done it in the past 20 years? The supposed restrictions have existed for that long, and the long-term support branches were never in CentOS and have always been accessible to customers only.
Because you still have the rights. You just aren't in a position to get future source code / binaries.
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."
Oh man, the legal battle when Red Hat tries to crack down on "pirated" GPL software is going to be... interesting.
(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)
If I had to guess, simply making these alternate GPL sources unofficial _enough_, will be good enough. If the whole alternate source is stained with the guise of "this is technically allowed but has no warranty and no guarantee it will receive the same patches", many people will jump ship and pay for support. Whereas right now, if it's literally the same thing, there's no reason to.
> 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.
And then you can sue for "imposing further restrictions", though.
(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.)
> Not that fighting a legal battle with IBM is something you can realistically do without losing your business, of course.
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.
If IBM loses, we could find ourselves faced with even heavier restrictions on RHEL, including the inclusion of binaries and non-GPL'd code which would make it much more difficult for Alma/Rocky to build their own version.
I believe Oracle Linux might be the biggest target here.
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.
They did something similar with the Kernel in 2011. They stopped publishing the git tree for the RHEL kernel and only published the tarball with no version control. At the time, Oracle started a project to reverse engineer it back into a set of unique patchsets. Was kindof wild.
Not sure how long it lasted. It doesn't seem live now, though.
they sell you version 5. you redistribute the 5 source code. they refuse to sell you version 6, therefore not making you eligible to receive the version 6 source.
refusing to sell you version 6 isnt a restriction on what you can do with 5. it is terminating the relationship going forward.
This whole thing seems absolutely trivial to get around to be honest. Rocky just needs to have additional gmail addresses to tie licenses to. IBM doesn't need to know that Rocky is a customer, nor do they actually have the ability to know outside of whatever glad-handing Rocky is currently involved in with IBM.
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.
Red Hat isn't imposing further restrictions. You are free to do with the source code whatever you wish, but the GPL nor any court can force Red Hat to give or sell you binaries in the future and thus source code in the future.
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.
But they're not. Let's say you download RHEL 10.0 someday. You download RHEL 10.0 source code. Some of which is GPL'ed. You rebuild and call it Acme Linux 10.0.
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.
> 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.
>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.
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?
"Although without legal teeth, in practice wouldn't this become very challenging to keep enforced?"
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.
One thing I fear is RHEL starting to add in code that is not GPL'd, but starts to become necessary to properly run the system. Then if you have the full source, you will still be required to strip out their proprietary software and patch the GPL source to get it to work properly. They could also add specific files to the source that contains your "customer ID", based on needing to be logged in to download the source. I know that starts to get into aluminum hat territory, but stranger things have been done to maintain a business.
It should be easy to distribute RHEL back to ACME Linux via a detour right? I mean another company could distribute it to to ACME and and hide that with limited repercussions.
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.
Red Hat can't impose restrictions on rights granted by GPL. But they are well within their rights to terminate business relationships with partners who chose to re-publish sources.
I don't know what the current situation is but Grsecurity operated under a similar arrangement back in the day.
> 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!
This response reads like the responses third-party reddit client developers gave when the API changes were announced. "What's going to happen? We don't know but we have a great working relationship with reddit and they said it SHOULD be fine..." and we all know how that turned out.
Except reddit actually controls all of the keys to castle in that example, whereas in this one IBM controls very little.
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.
Exactly right on the lack of notice. What happens to people relying on Alma/Rocky? They're possibly screwed.
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.
I think this entire action is done BECAUSE of Oracle and Alma is just betting that Oracle is invested enough to take on the fight that Alma can't and will use them as a wedge.
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.
> 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. These updates will be carefully curated to ensure they are 1:1 compatible with RHEL, while not violating Red Hat’s licensing, and will be vetted and tested just like all of our other releases.
I think they won't find any other solution than this.
Maybe create an Ubuntu Pro clone? If Ubuntu pro patches are even open?
As a Fedora user, I like this. People who want to use RHEL should pay and there should be no way around that so I can use my Fedora for free. Good job!
I think the intended sentiment is "if you don't want to pay, then you should have to run (and so help test) the new bleeding-edge thing, instead of using the old stable enterprise thing."
I'm an individual freeloader, but I occasionally report bugs. I understand that I might encounter bugs and/or provide some free contributions to Red Hat, but that's in exchange for a well functioning desktop distribution.
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?
So, the people who put their time and effort into the upstream projects which RHEL uses (without paying them), you're saying those people are freeloaders if they want to build things on Alma or Rocky Linux?
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.
You know they won't. Anyone who really needs RHEL is already paying for the real thing. I reckon the main thing this brings is people moving en masse off RHEL-based distributions and a significant reduction in market- and mind-share over the long term.
It also feels like a moment of opportunity for SUSE, but they seem quiet.
Due to the discontinuation of Centos 8 and these manufactured obstacles faced by RHEL derivatives, I am strongly considering migrating our systems to Debian.
Go for it. I hope lots of people switch to Debian and help support its development. If RHEL isn't compelling enough to pay for, then Debian is great and available for free and that community isn't trying to make a profit. So IMO everybody wins in that scenario.
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.
I think those that were using CentOS for stability would do well to switch to Debian Stable. It will give more users and testers to the Debian project, which can only help to grow the Linux community (as scattered as it may be). I know there were a lot of sysadmins that used CentOS because they understood the system enough not to need support from Red Hat and RHEL.
Do it. Even if it's somewhat painful now, seems like it'll be much cheaper long term. This is the second major surprise we're seeing from Red Hat's side over the last couple of years. It's quite likely you'll have to migrate somewhere soon anyway (for the second time in as many years), and it might as well be a community-supported distribution that has never pulled any similar tricks over its multi-decade lifetime (as it is not dominated by any single corporate entity, or really any corporate entities at all).
I have already seen a ton of vendors that once only has RHEL certifications for their software switch to having RHEL and Debian or Ubuntu Certifications for deployment
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
FreeBSD is another solid server OS if you don't need anything that specifically requires Linux.
> 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.
Every update that goes into CentOS Stream is not a "proposed update", it is an update that has gone through the entire QA process and is scheduled to go into the next RHEL minor release. It's the same as Debian, except that Debian has no other "more stable" point release branch, it just has the one that updates flow into after being tested.
I might be misunderstanding what you're saying, but Debian Stable has LTS versions, which will give you your stable system for a longer period of time.
The consensus here appears to be that red hat N is all GPL and released as source, but red hat N.1 is not a derived work of GPL code so it's fine if they keep it secret. That's a pretty thin ledge to stand on - if _red hat linux_ is not a derived work of masses of GPL code, what would be?
Not quite, it is more like the GPL gives you the right to distribute/modify RHEL N, but not to N+1, unless you already have it. The RH subscription gives you RHEL N, and RHEL N+1 but only if you didn't distribute RHEL N.
The GPL covers derived work. Redhat N+1 is definitely a derived work of redhat N which is itself under GPL as it's definitely a derived work of all the GPL software they build it out of.
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.
Sure, but if they don't give you binaries of N+1, they don't have to give you sources of N+1 and nothing in the GPL requires them to give you binaries of N+1.
maybe that's a bit unpopular opinion but I'd rather see this kind of changes if that means there is no more layoffs and they won't suddenly cutoff the spending on some opensource project...
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.
Since I'm a bit lost regarding the current RHEL clones I was looking into AlmaLinux.
I can't help myself feeling suspicious regarding those type of organizations, by that I mean investing time & commuting to a long term migration or contributing to the project.
It's a lot about leadership team with pompous titles like "Chair or the board of directors" who by the way worked for Microsoft at the same time.
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.
> 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.
The real question is: is Alma/Rocky (and the prior CentOS) RHEL compatible, or is RHEL compatible with them? I assume it's the latter because Alma/Rocky are a great proposition for prototyping, and RHEL can be dragged in later for compliance.
Red Hat are eliminating a user vector/funnel here.
When RHEL compatibility is mentioned, I always wonder which kind. ABI for system libs, default packages and patches, kernel symbols and structs, selinux policies ? And if "all of the above" then what room for improvement via forks is there ?
Fedora is excellent for workstations - not for servers. It's just not stable enough, and the update/upgrade cadence is too fast and short-lived.
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.
> 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.
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.
Arch for the most part does things the same way that Fedora does. At least, way more the Fedora way than the Debian way. I would consider Arch as part of the "Red Hat" way of doing things.
Arch is awesome - if you like tinkering with your system. I don't know if you could call it stable enough to run servers reliably. I am aware some masochists do just that, however. It's wonderful to have a lot of choices within the linux community.
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
What are you running these days where you need that kind of stability? For a lot of folks, their apps run on containers or are static binaries, where the underlying host packages don't need stability.
We have a ton of legacy in-house codebases that do all sorts of things, and were designed with RHEL/CentOS in mind (scripting, etc).
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.
This is exactly the reasons I think Red Hat has really messed up here. Fedora has been steadily gaining adoption among desktop linux, and truly is a remarkably great OS. This in turn leads to people choosing EL for server-side because they already know the conventions, packages, etc.
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
Exactly my concerns. Fedora is significantly tied to Red Hat currently, and honestly if Red Hat keeps pulling in moves like that, I fear for the project's health in the long run. As matter of fact, yesterday I wiped one of my machines for Arch to probe it as an alternative for it and honestly I can think of is how there is nothing quite like it anywhere else, so I hope it doesn't come to that. I've learned to enjoy sane defaults and fresh up-to-date packages OOTB!
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.
I've always found the Red Hat way to be less intuitive than the Debian way, and I got my start on Slackware then Red Hat (before it was Fedora, included with a book around 1998). I see a lot of people complain about using apt for package management, but I've never had any issues. I've run game servers, database servers, and web servers, all on Debian without issue. I've done light administration to CentOS and RHEL servers, and I've always been confused because I reach for the Debian way. I realize that is my lack of knowledge, and as a software developer I have to adapt constantly, so I'm not really sure why it never "clicked" with me.
Having been stuck on RHEL when I worked for the DoD I'm shocked there are still people out there who willingly choose to be in that ecosystem, and to a certain extent I've always been surprised that Fedora is widely popular and well maintained. Like I understand that it is a true statement that people like it, but what was their progression that landed them there I just don't get it. OpenSuse is even more mysterious in that way.
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
The last bare metal server that I maintained was a CentOS 7 machine (~2 years ago). Everything now is in the cloud and is currently a CentOS variant/fork/whatever in AWS Linux2. I've been in the Fedora/CentOS pipeline since around the time dirt was invented. The only other server that I've spent any time on is FreeBSD. Of course my daily driver OS X systems were based on BSD as well. I did a debian box once, but I've never used Ubuntu.
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.
I’d agree what that. Linux folks who don’t know Linux use Yast. Linux folks that know Linux disable it.
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.
I'm still currently using CentOS 7 in my homelab, but since EOL is next year I'm now starting to plan the next iteration that I'll use in both hardware and software.
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.
Linus Torvalds uses Fedora for his personal dev environment which alone speaks volumes about it. I tend to bounce around and mix up my personal dev machine distro every few months but have enjoyed Fedora when I've used it. Arch is great for AUR.
I thought that a key value of a RHEL subscription is the support.
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?
IBM MBA says "money left on table, what can we do about that?" Someone suggests that GPL letter of the law only requires source be distributed with binaries, and so they decide to do that.
You forgot the part about "other people take Red Hat's source, rebuild it with different branding, give it away for free, and also offer/sell support, undercutting Red Hat's own offering." Otherwise, I would bet you're correct.
RH (ie IBM) only really makes money off of RHEL via support contracts. They noticed that a lot of ppl would use CENTOS to avoid paying for licenses, so they essentially killed it, they now notice that folks like Oracle are basically just using their source rebranded and selling support contracts that undercut them on their own software - so they are taking this action in a way to counter it.
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.
121 comments
[ 2.4 ms ] story [ 170 ms ] threadA 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…
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 cutting back RHEL source availability - https://news.ycombinator.com/item?id=36420259 - June 2023 (296 comments)
I think they won't find any other solution than this. Maybe create an Ubuntu Pro clone? If Ubuntu pro patches are even open?
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.
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.
https://www.debian.org/intro/help
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.
https://www.freebsd.org/security/
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.
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.
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.
> 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.
Red Hat are eliminating a user vector/funnel here.
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?
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.