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

On Mon, Jun 26, 2023 at 8:43 AM Rich Freeman <r-plug@thefreemanclan.net> wrote:

>
> 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.

They aren't required to create the patches in the first place. If
they distribute binaries they have to distribute the sources, but they
don't have to create anything.

That's what they're paying for. The code doesn't write itself.

Sure, they aren't obligated to write patches. And, again, the actual patches written in-house, by Red Hat development teams, is very little.

>
> Perhaps it's on me for not stressing enough how little RH does development, so let me make it clear-

According to the most recent Linux Foundation release that I could
find, RH has authored about 9% of all Kernel commits, which makes it
the #3 source of contributions. The #1 source as unaffiliated
authors, making up 12%. So Redhat alone contributed 75% of what all
unpaid contributors wrote combined.

Now, that document was historical and covered 2007-2020.

I ran the following:
git log --since=2022-01-01 --pretty=oneline | wc -l
14720
git log --since=2022-01-01 --pretty=oneline --author='.*@redhat.com' | wc -l
756

That's 5% of recent commits, though it should be noted that this
includes merge commits and so on. I wouldn't exclude those since that
merge activity represents a lot of integration/QA that is real
contribution. This also just looks at the author field alone, and it
is possible that redhat is doing contributions reflected elsewhere in
the record - really anybody mentioned anywhere in a kernel commit has
done something to add value. My guess is that even if they just
report a bug, they're probably not just throwing a vague report over
the fence but are probably contributing real analysis and data.

The linux kernel is probably the most complex and active FOSS projects
in existence, and a company paying for 5% of it shouldn't be
downplayed.

As I said, it's about 1-3% for any given package. Some software will have more, that's what "about" means. 5% is not a significant amount more. The kernel would still run without their contributions.

The kernel may be many LOC, but percentages are percentages.

Red Hat requires their employees to submit patches to upstream with their Red Hat emails for Red Hat contributions. but don't prevent (I'd argue even encourage, because it's free advertising) employees from submitting using their RH emails for non-RH contributions. If anything, that number's inflated.

I didn't say RH never contributed, I said exactly what I said - that the total amount of contributions/RH-developed code is very little relative to community involvement.

>
> 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.

I'm not sure I'm following you. So, you're saying that somebody
running CentOS Stream 9 has the exact same code (minus RHN packages)
as somebody running RHEL 9.0 (not 9.2) today? Ie same patches to
kernel, glibc, other system packages, etc? If a new kernel release is
issued, the patches it contains are backported to neither or both, but
never just one or the other?

Therein lies the rub, and why the alternatives are complaining. "Yes and no".

Will EL 9.0 be comparable to day-1 release of CentOS Stream 9? No, because that's not quite how they freeze.

Will EL 9.0 be comparable to day-n release of CentOS Stream 9? Yes. (I believe RHEL/EL has minor version releases approximately 2x/year now.)

The real pain in the butt for these alternatives would be noting which version of packages map to which point release. Certainly not impossible (which is why the AlmaLinux blog post on the matter is fairly hopeful about the situation), but presents a significant effort.
You will also notice that Alma directly refers to fetching package sources (SPECs and patches, specifically) from git.centos.org - I wonder why, possibly, that might be. :) (It's because CentOS Stream is the direct upstream for RHEL releases.)

The bigger deal is it seems that they aren't able to "paywall" this data without also applying it to CentOS Stream.

I thought CentOS Stream was supposed to be closer to a rolling
release, while RHEL releases were supposed to get backports. As we
agree, though, I'm not really an expert on the RHEL ecosystem and if I
have that wrong I invite correction.

CentOS Stream is still versioned to a major release, it just doesn't have minor version releases. It's kind of a "soft rolling release" rather than a true rolling release (Arch, Gentoo, OpenSUSE Tumbleweed, etc.).

EL (including RHEL) releases are then based on certain fixed points within that major version channel. Probably more similar to how Debian bases releases off of a frozen Sid, only there's a bit more concrete SLA for releases.

If they really were identical, I don't see why people are making a big
deal out of the RHEL patches not being publicized since they'd be
public via CentOS already.

And now you understand the crux of my umbrage in the "value-add" argument, yes.

My suspicion is that they aren't actually
the same. If they aren't the same, then there is your curation and
QA.

Nah. This curation and QA is all delegated to the CentOS Stream cycle.

>
> The majority of this curation is via community-submitted bug reports.

Well, sure, but reading and dealing with all those reports takes
effort. Then the RHEL users benefit from getting the fixes before
they get the bugs.

If anyone, CentOS Stream users get the bug fixes before RHEL customers. You can't even run a "bleeding-edge" RHEL. Now, the process you think/thought RHEL was following was true BEFORE CentOS Stream became a thing. But that isn't how it's done now.

> 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

Well, keep in mind that until recently my understanding is that CentOS
had bug-compatibility with RHEL, so there wasn't a value-add there.
My understanding is that RedHat killed that with Stream, but I could
be misunderstanding things.

CentOS did ("mostly". Assuming it wasn't a bug with branding assets or such.)

It's more accurate NOW, with Stream, to say "RHEL X.Y has binary/bug-compatibility with CentOS Stream on this particular calendar day".

You might be describing a transitory state that only existed after
CentOS was created, and before the non-Stream version has been
completely phased out (which hasn't actually happened as I understand
it, at least for CentOS 7). RHEL hasn't gone through any of that,
which is also the sort of thing companies are willing to pay for.

Nope, CentOS was always downstream from RHEL. CentOS Stream was always upstream for RHEL. (The latter was created explicitly for this purpose.)

CentOS 7 is still before the EOL, because they kind of wanted to honor the published EOL. For a very, very brief amount of time, they did release and maintain both a CentOS 8 and a CentOS 8 Stream, but they had an incredibly aggressive EOL for CentOS 8 that ended even before 7 (it was intended more as an opportunity to migrate to CentOS 8 Stream).

I'm unclear on what the "that" you're referring to in "RHEL hasn't gone through any of that" is.

It isn't entirely clear to me exactly what we are and aren't in
disagreement about. Some of this could just be choice of words. My
basic point is that RedHat actually contributes quite a bit to the
FOSS community, and their business model, like most FOSS business
models, is a bit clunky because the GPL eliminates many of the
traditional methods of monetization. You can't really say they aren't
adding value when they're writing huge volumes of code and it is just
that the method of charging for it is awkward because they have to
release the code itself for free.

A significant amount of disagreement here is because you expect there to be much more value-add from RHEL than there actually is. Because sure, what you're saying would make sense. But that isn't reality, that isn't how the RHEL lifecycle operates

But Red Hat doesn't, and has no reason to, care about RHEL being a primary profit source because the majority of their income/profit is not and has not been from in-house development nor from RHEL subscriptions/registration - it's been from consulting, support, etc. All the other things I keep mentioning. Red Hat isn't a Linux distro, they're a Linux "company" - RHEL is more of a standardized platform on which they can deliver SLA rather than a product they sell, if that framing makes more sense to you. They just aren't going to turn down the opportunity to charge for that platform as a basic fee.