The most concise and pithy way to describe RHEL’s business model is: “if you exercise your rights under the GPL, your money is no good here”.
" In essence, Red Hat requires their customers to choose between (a) their software freedom and rights, and (b) remaining a Red Hat customer. In some versions of these contracts that we have reviewed, Red Hat even reserves the right to “Review” a customer (effectively a BSA-style audit) to examine how many copies of RHEL are actually installed (see §10) — presumably for the purpose of Red Hat getting the information they need to decide whether to “fire” the customer."
And I develop Ansible roles that I know have been used by thousands (more?) of RHEL enterprise automations—and are cited in official Red Hat training materials (with my cheerful photo alongside).
How did I build those roles and test them? CentOS. And then Rocky Linux when CentOS was stripped away.
I hate how there’s this feeling that all CentOS (and now by extension, Rocky/Alma) users were leeches, and there was no value in having a downstream distribution. Offering the ‘carrot’ of a Developer Subscription with 16 free sockets is insulting.
Almost as insulting as how many times I see these weird comments slandering Rocky Linux in particular, and tracing them back to a source, it seems to always be someone affiliated with RH. I don’t ever assume ill intent, but it seems like someone in sales, marketing, or management threw together some sort of gameplan for ‘how do we sell against Rocky/Alma/Oracle’, and there’s a slide in there with this weird false history.
It is better to for you and other RHEL downstream Clones to fork the RHEL and make compatible by clones such a way that the RHEL should follow your model of Open Source licensing rather than maintain binary comparability with RHEL
Lets look at RHEL 7. It has kernel forked from upstream 3.10.0. It has Python forked from upstream 2.7.
Both upstreams have been long “dead”. Each fork has plenty of changes, “backports”.
How much Red Hat does use resources to develop and maintain one RHEL major version (for 10+ years)?
(I don’t know the answer, but I bet it to be substantially more than what the clones use in their rebuild procedures.)
RH has hundreds of people working on the kernel, on drivers and all sorts of stuff that ends up in literally every distro (including Debian). Anyone who says they’re going to stop using RHEL because RH is not honoring the GPL or the spirit of opensource, simply does not understand the dynamics of the Linux ecosystem. I for one hope that RH is successful and continues to be successful. I want there to be an organized, for-profit company who can afford to pay people to work full-time on Linux and opersource. Don’t you? If I don’t get to use an exact faxcimile clone of their end-product for $0, that’s ok. There’s always going to be a big group who need a highly stable, long-EOL Linux distro that is affordable. That fact will drive some kind of solution one way or the other. Watch the cloud providers like Amazon, Google and yes … Microsoft.
Fun fact: I just finished writing the documentation about open source business models for the Linux Professional Institute (I’m one of their authors). So let me state this bluntly. You can be a highly profitable multi-billion dollar company like Red Hat and publish all your sources on Git, because the added value lies elsewhere. Plus, today’s students (like mine here at the École des Mines d’Alès for example) are tomorrow’s engineers. More users means more bug reports etc. which is also profitable in the long run. On the other hand, hiding your sources behind a paywall is just a short-sighted dick move probably thought up by some turbo-capitalist eager to milk the user base.
Redhat is calling everyone that works on RHEL clones and that use RHEL clones leeches, and only sees contributing back to opensource as writing code while their are plenty of other ways to contribute back to opensource already mentioned in this topic. Why was Redhat okay with CentOS up until 2-3 years ago shortly after IBM bought them, if it was actually a problem they should have said it from the start not 15 years later?
Doesn’t that effectively mean that you start to download the same selection of upstream sources as Red Hat downloads for their RHEL, and then you do similar development for your distro as Mike claims* “thousands” paid developers to do at Red Hat?
OpenSUSE is 5 years cycle, and to get 10 years you need SUSE Enterprise. Ubuntu LTS is the same, the “free tier” is 5 years, and then to get the other 5 years you need to pay. Debian is only 5 years cycle. In all those “free tier” 5 years cycle, the source code is available for contributions. RedHat is kind of doing the same, giving you the 5 years “free tier” via CentOS Stream, and if 10 years is desired, you need to pay. CentOS stream is sighly ahead, which is different than the other options. RedHat was unique in that sense that allowed the free 10 years cycle ride.
Are non-EL distros practical alternatives? Am I missing something when comparing with other supported distros?
As I posted in reddit thread regarding openSUSE… Leap is having it’s own existential crisis brought on by maintainer drought and SUSE in general tightening up access to SLES binaries. The current group of developers working on that ALP… thing are very anti-workstation and anti-feedback from the community. It’s left a sour enough taste in my mouth that I’ll slowly be migrating out of the openSUSE community. I had looked at Rocky, but it seems Rocky might be living up to it’s namesake depending on the way the winds blow.
One difference with the time frames is that Debian/Ubuntu/SUSE all offer in place major version upgrades. *EL has historically not provided that. I would have been less turned off by the Stream fiasco of they had JUST moved CentOS to a 5 year lifetime.
Fedora has had major version upgrades for a while. I’m surprised it’s still not in *EL to be honest.
RHEL does have officially supported in-place updates. I have done it myself, specifically from 8 to 9.
CentOS stream does not, but people has been successful doing it (Commands to live-upgrade CentOS Streams 8 -> 9 · GitHub).
I hope they do provider a much easier way of doing it going forward, especially with the reduced support cycle of 5 years.
