Re: [PLUG] Red Hat cutting back RHEL source availability

On Mon, Jun 26, 2023, 06:08 Rich Freeman <r-plug@thefreemanclan.net> wrote:

>
> RHEL gets the majority of their RPM specs and patches (the source in question) from the Fedora => CentOS Stream pipeline. Both are F/OSS-licensed and their SRPMs, SPEC files, and patches are freely distributed. For the Red Hat-specific patches, assuming GPL (the majority of what the software itself as packaged in the distributed RPMs), they must release these patches at the LEAST to customers. These customers cannot be legally restricted from redistributing without risking license violation of the initial software, at that..
> Red Hat does not do much actual unique code aside *from* those patches. Every single product offering they have is based on a fully F/OSS project. (RH Storage? Ceph. RHV? oVirt. RH IDm? FreeIPA. And so forth.)

RH is still the one paying for all that, so they're giving back. They
wouldn't be paying for the stuff in the free distro if they weren't
getting paid for doing the work to benefit their paid distro.

What, exactly, are they paying for? The patches that are bound by GPL because the software they apply to are GPL? The ones they can't restrict redistribution of?

They aren't making those patches available out of the goodness of their heart; they're required to make them available as well because they contribute to building GPL-covered binaries. The patches that make the code compat with their platform. (e.g. SELinux - ALSO not owned by Red Hat - policies.)

If you think they're doing any value-add via source/features to those upstream projects, you are incorrect. They are not. I don't know why you seemed to have glossed over the "Red Hat does not do much actual unique code aside *from* those patches" bit. Perhaps it's on me for not stressing enough how little RH does development, so let me make it clear-

Excluding packages dealing with interfacing *specifically with Red Hat systems* (e.g. RHN), which are not present on alternatives because it makes no sense to even include them, *for any given package Red Hat has contributed about 1-3% of the total code. Including upstreamed.*

I mean, by that argument RH isn't restricting anything by making it
hard to get at the RHEL sources, since it is all published elsewhere
anyway, so they could just stop distributing the RHEL source entirely.

As you point out, no they cannot due to the GPL. They can make it by-request-only, sure- but they cannot deny distribution to customers upon request, and they cannot prevent customers from redistributing for the precise reason I linked to.

I don't think that is actually legally valid as the GPL requires you
to distribute the source of the binary you're shipping, and not say
that everything in it is someplace else but good luck figuring out
what random combination of patches it contains.

> Red Hat products, as outlined above, do not have ANY period of exclusivity. Often they drag a major release behind the F/OSS upstream.

RHEL is exclusively available to RHEL customers, and you can't get the
same thing elsewhere, or at least they don't intend for you to be able
to get it elsewhere.

What, specifically, do you think is the difference between a registered copy of RHEL vs. an unregistered copy of RHEL is? What do you think the difference is between a registered copy of RHEL is vs. CentOS Stream?

Yes, they publish all their patches first elsewhere, but they curate
what goes into RHEL. They backport things to provide more
stability/etc. They presumably make sure the patches are bug-free
before they hit the RHEL customers.

CentOS Stream is, quite literally, the curation and QA. RHEL is a minor-release-frozen version of a point in CentOS Stream major with RHN thrown on. There's a reason it's "CentOS Stream 9" and not a pure rolling release.

That kind of curation is certainly a value-add, and clearly their
customers are willing to pay for it. To some extent if you run
Fedora/CentOS you're paying with your willingness to beta test things,
but the RHEL customers are the ones paying for the work for the most
part.

The majority of this curation is via community-submitted bug reports. Hence why IBM-RH moved CentOS (Stream) to upstream of RHEL. You will not find a single non-RHEL-specific (e.g. RHN) package in RHEL that was not, byte-for-byte, in CentOS Stream.

(Okay, with the single exception of branding changes for the packages where branding is applied.)

Now, it might not add value for everybody, and the beauty of this
arrangement is that nobody has to pay a dime to them if they don't
want their services, and you can still get their sources for free one
way or another.

Yeah, so the actual reason people go for RHEL is for the consultation and engineering services (which, again, isn't very good but they SOUND very confident in what they tell you, and they are still better if you don't HAVE a systems engineering team) and the support contracts.

(Maybe about 4, 5 years ago I'd say "and Satellite", but you could run your own via F/OSS Spacewalk. Same thing, different branding. But they've even removed management from their portal now since Spacewalk died, and thus since their upstream died, they discontinued Satellite. If anything, RHEL has been *decreasing* in value-adds.)

Nobody has ever chosen RHEL over a free EL based simply on the merits of RHEL over the others because there's no reason to; the "value-add" you seem to think exists really doesn't - and it's certainly not because their RPM SPEC and patches are available, because again- those mostly come from Fedora and CentOS Stream.

The majority of RH's profit comes from training, support contracts (extended support add-ons, really, because there are still some insane people running EL 6 out there), and their certification programs (precisely BECAUSE that training knowledge and certification is so directly transferrable TO the free alternatives).