Oracle, SUSE and others caught up in RHEL drama hit back with OpenELA A non-profit called the Open Enterprise Linux Association (OpenELA) has been formed by Oracle, SUSE, CIQ, and other organizations that make Red Hat Enterprise Linux (RHEL) and CentOS rebuilds. The OpenELA homepage opens with some strong, even confrontational words: "No subscriptions. No passwords. No barriers. Freeloaders …
This post has been deleted by its author
[Author here]
> if everyone played this scummy game
Oh come on. Get real.
RH is not depriving anyone anywhere of source code.
All it is doing is keeping the _oldest_ maintained versions for customers only. Newer versions of every single module, template and header are available from CentOS Stream, and newer versions than *that* from Fedora.
Remember that there are about 10-20x more packages in Fedora that are not included in RHEL. RHEL is _tiny_.
Don't try to make out that this is some big IP theft or anything. It's not. NEWER versions of everything are available, to the world, free of charge.
I'd never heard of CIQ, but their Open Source Ethos says:
"We believe that open source is a development and community model around software and sharing for the greater benefit. It is NOT a marketing switch to be enabled or disabled based on corporate and business needs behind closed doors."
Just so.
They didn't quite dare go with the slogan "Taking the Red Hat out of Red Hat Enterprise Linux" did they, but it's close enough to almost be that. It's unsurprising that this has happened in response to IBM's attempt at control, but what happens next is sure to be interesting.
Will IBM attempt to try and stop this by restricting source access to Oracle, SUSE, etc? Or even try and sue them? Maybe they'll just give in to the pressure this will apply, and just say "OK, everyone can just have the source for free again".Or maybe all 3 options in that order.
Whatever happens, I imagine the scenes in IBM / Red Hat boardrooms were quite entertaining when they got this news.
Red Hat have already restricted RHEL source access to Oracle, Suse, etc. This is why the latter have formed this organization.
At this point it's still not clear what it was that Red Hat were hoping to accomplish. Was this a reaction to loss of market share to Alma, Rocky, Oracle, and the like? Or do they have plans for big price increases and want to make it a bit more difficult for existing customers to jump ship (or threaten to jump ship) to the alternatives?
Somehow this has to be connected to money, but I'm still not sure just how.
Overall though this Red Hat plan has to be related to distros which are exact clones of specific RHEL releases and not ones which are Fedora or Centos derivatives, because the latter haven't changed policies.
I wonder if just a directive from their corporate Daddy to increase profits after they splurged on buying Red Hat. This will likely come back to bite them, but those C levels will have had their bonuses by then and moved on. RH themselves used to say if we make money from bits we aren't doing it properly....
"I wonder if just a directive from their corporate Daddy to increase profits after they splurged on buying Red Hat"
I agree with you as this current move, along with the sacking of many technical staff, is uncharacteristic of old, independent Red Hat but it is wholly in line with IBM's modus operandi. I wish that Sun had never been taken over by Oracle and I wish that Red Hat had never been bought by IBM.
While I understand and support the goals of open source, I can also understand why a big distribution gets ticked off by all the rebuilds and remixes downstream of their hard work.
Sure it is a community effort, but if you take a look at the statistics, the majority of code contributions are by the employees and contractors for the "big players", not "the little guys."
In the Linux kernel, the big players pretty much employed the "little guys" to facilitate those stats.
But if you look at the actual packages that Red Hat is withholding SPEC files for, things like libpng, bash, vim, dia, brasero, gedit, etc are all very much little guys. You wouldn't get a company like IBM developing this stuff. There is no money in it individually.
All in, I imagine that RHEL as a complete product only contains < 5% code developed by Red Hat and IBM.
https://git.centos.org/rpms/bash/tree/c9
https://git.centos.org/rpms/libpng/tree/c9
https://git.centos.org/rpms/vim/tree/c9
https://git.centos.org/rpms/brasero/tree/c9
https://git.centos.org/rpms/gedit/tree/c9
dia isn't in EL 9.
You want to know what RH is doing with those things? There you go. (Also, https://src.fedoraproject.org/rpms/bash , etc).
We would not do anything remotely interesting with any of those things downstream of CentOS Stream. That's not how RHEL development works. If RH is doing anything substantial to an upstream project, it is ideally sent directly to the upstream project. If it's not upstreamable for some reason, or upstream won't merge it, it goes to Fedora. If it can't go to Fedora for some reason - for instance, it's being changed in a RHEL release after it already branched off Fedora, or it's somehow RHEL-specific - it goes to CentOS Stream.
We don't initiate interesting engineering work in RHEL. We just don't. The only things that happen in RHEL that don't happen somewhere upstream first are very, very old backports and embargoed security fixes (we'd *like* to do embargoed security fixes upstream, but it's kinda impossible with how embargoing works).
You won't find special Red Hat secret engineering sauce in the RHEL specs that isn't in the Fedora or CentOS Stream specs. If RH is doing anything interesting to any project you're interested in, you will find that work all the way upstream, or in Fedora, or in CentOS Stream. Anything happening downstream of that is only going to be of interest to people trying to make an exact clone of RHEL, unless for some reason backports of upstream changes to six year old versions float your boat.
RHEL provides value to RHEL customers, and the work that goes into it is expensive, but it's not work that's *interesting* to upstreams.
This is observable in reality, of course. What projects are downstream of RHEL? Nothing but RHEL clones.
I am sure what you say is true. However, it is the principle that matters. If you are distributing software including GPL-licensed code then you should be freely providing the source code to anyone who wants it, for whatever reason they might want it. And not just "what changes you have made" but "exactly which lines of code went into exactly this binary".
That is the basis on which I have GPL-licensed my code, and made it available to you to use if you wish. Just as the GPL does not allow me to state that "everyone except RedHat" can use my code, you cannot say "trust us - we haven't changed your code".
The right of everyone to see what you have done to my code is the price for you being able to use my code.
...before you punish me with down votes, let me explain. All this is doing is legitimising RHEL as some sort of perfect, un-corruptable standard. This actually helps Blue Hat, both by enhancing the reputation of RHEL as some sort of perfect product AND training people to use RHEL. All this effort should, in my view, go into development of an equivalent product, outside the control of predatory corporations. Right, that's it, feel free to put the boot in.
"training people to use RHEL"
This is what the RHEL downstreams did and you see what thanks they got from it. As I understand it this effort is just the opposite: a statement that RHEL isn't needed as there'll be a non-RHEL enterprise standard with wide support with RHEL becoming an outlier.
I agree with you.
Genuine question:
Why do people choose Red Hat these days over say Debian?
When I first got involved in Linux about 25 years ago, Red Hat was easy(ish) to install, Debian was really difficult. Debian had a much better package management system, Red Hat's was a dependency hell nightmare.
These days, Debian seems easy enough to install, I would imagine about the same level of difficulty as Red Hat. And Red Hat now has a package management system that from what I can gather works much the same way as Apt, and any other package management system that isn't called winget, or snap.
I mostly use FreeBSD. Debian is my go-to when FreeBSD isn't able to run my workload. I haven't used Red Hat since about 1999. My knowledge of it is massively out of date, so that is why I'm asking.
Red Hat has always been perceived as providing superior long term security support compared with any other distribution, with many developers being subject matter experts intimately involved with key upstream projects, allowing for more reliable backports. By comparison, Debian has historically been much more “best effort” in that regard.
For example: Security vulnerabilities in desktop software which is not remotely exploitable and which requires an end user to manually load in a carefully-crafted file to trigger it would often end up without a DSA (marked unimportant, to wait for next point release) but those same vulns would end up with an RHSA in RHEL (to be fixed as soon as feasible). Web browsers at one point (e.g. Iceweasel and/or chromium) would fall so far behind on backported patches that the system would become a liability to use. RHEL also had initiatives to make Mandatory Access Controls and hardening of key daemons the norm with SELinux.
As of 2023 (thanks to Red Hat upstreaming all their work in a very neutral way) a lot of the advantages RHEL once had are now just standard features across every distribution, and it can be argued that their pace of innovation in terms of features unique to Fedora/RHEL has slowed a lot. The irony is that the more Red Hat does the right thing, the less valuable their paid distro will appear to be to average customers, and for that reason I think they’ve made a mistake by trying to kill the clones. The customers who receive the most value from Red Hat are the ones which need access to their paid support, not just their (S)RPMS.
Why do people choose Red Hat these days over say Debian?
I initially preferred Red Hat as system admin was closer to System V release 4, Debian was closer to BSD Unix.
Later (and now) there is more RedHat support from hardware vendors and ISVs than there is for Debian. Also: RedHat supports SE Linux better than does Debian. These 2 are important for the corporates, especially the first.
Having said that I have switched my desktop to Debian in the last 2 years.
Red Hat are a company whom you can pay money to in order to have them provide support to you.
Debian are a community free software distribution. There is no Debian company selling support services. There are however companies distributing derivatives of Debian and providing support for those, such as Canonical (Ubuntu).
The key difference between RHEL and Debian is that RHEL's "upstream" (Fedora and Centos) is controlled by Red Hat who can dictate policy to them while there is no commercial company controlling Debian.
Debian are known for stability and being cautious about releasing new features in the stable release series. The majority of Linux distros are Debian derivatives (revenue is another story).
If OpenELA want to really make a mark in the Linux distro world, they could look at releasing an OpenELA distro with binaries, rather than just being a set of git repositories. They could then be line Centos was. Commercial support would still come from OpenELA members, based on their own binaries. OpenELA could then be a "Debian" equivalent.
Perhaps they have this in mind as their eventual goal. We'll have to wait and see.
Having used both RedHat-derived Scientific Linux and Ubuntu, and built binary packages for both of these, I would say that the modern versions are more or less equivalent. Ubuntu's subiquity mess is far more annoying than kickstart, but is also moving faster than kickstart as a new product. RPM and DEB are pretty much equivalent in packaging terms, and both are now converging on more or less that same rough internal structure (lump of compressed data, config file to say what to do with it, scripts to do stuff pre-install and post-install and so on).
This post has been deleted by its author
…chasing users who don’t want to pay for Linux software. Wondering how well that is going to play out. Only Oracle does not need to make money on Linux but I feel there is only a small % of the world that would trust Oracle enough to use their free Linux.
I can see the discussion now for Suse and CIQ “glad you downloaded our fully free freedom EL Linux version. Are you interested in paying us some money?” User possible responses “1. Haha, please go away, 2. I thought it was all free and in the open source spirit - come on guys, 3. Sure, will give you a $1 a server”…
Anyway. Godspeed to this crew in their quest !
Current decompilers are so good that it's likely that the source code can be extracted from the binaries. With 99+% compatible source already available I'd expect to be able to do an amazing job.
With commercial software that's generally frowned on, here ?. Can't see any barrier to doing that.
It'd be a nice feature to add to GCC/CLANG, it'd certainly discourage freeloading WRT the Open Source compilers.
It seems to me that if your software is *SO* dependent on a specific bug being in a specific place in a specific file in the host OS, there is something *severely* wrong in your software design and engineering. That sort of sloppy coding went away in the mid-latter days of MS-DOS.
I'd argue we don't have enough!
As a former ClearOS user I can confidently state that it is in fact dead, despite the semi-regular announcements to the contrary.
It's a shame too, because it was pretty easy to set up and run and worked pretty well. I think the people who were behind it got overly ambitious though and spread themselves too thin with all sorts of weird new projects, none of which amounted to anything.
They had a really good community at one point but everyone lost heart and left and the forums are ghost towns now.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
