CentOS - Jul 2023 - Current RHEL fragmentation landscape

On 2023-07-25 04:25, Phil Perry wrote:
> Nonsense. For years Red Hat freely published the complete RHEL SRPMs 
> to their public ftp server.

No, they didn't.? Take a look at the planning guide diagrams, here: 
https://access.redhat.com/support/policy/updates/errata

A RHEL major release isn't a single lifecycle.? It's a sequence of minor
releases, many of which have 4 year lifecycles of their own.? Red Hat 
never published the updates for those lifecycles after the first 6 
months, which is why CentOS had long gaps with no updates every 6 
months, while they built a new release.

If Red Hat had published *all* of their source, then CentOS could have 
continued publishing security errata right up until they were ready with 
a new minor release.? But that's not the way that it worked.

Few people, if any, were ever really concerned about the fact that Red 
Hat didn't publicly publish the source for their extended support life 
cycles.? But, that's what minor releases fundamentally *are*, so it's 
weird to see users unhappy with arrangement today, in which the current 
sources for RHEL are published to the CentOS Stream git repositories, 
and the minor releases are treated the same way that extended support 
life cycles always have been.

>>> 3. Per Red Hat EULA, customers can not freely distribute the source
>>> code. (ref: Red Hat EULA)
>>
>> It's a little more complex than that, but probably close enough for
now.
>
> It's not complex at all. The GPL absolutely allows recipients to 
> freely redistribute the RHEL sources.

That's not what I'm saying.? The GPL does allow RHEL customers to 
redistribute source code for GPL-licensed software.? The complexity is 
that the license doesn't require Red Hat to continue business 
relationships and support users who choose to do that. And that most of 
RHEL isn't GPL-licensed.

>> This is the point at which I think we start to wade out into the 
>> territory of myth.? It has never been possible to create a clone of 
>> RHEL from the code that Red Hat published. 
>
> Of course it has.

No, it wasn't.? CentOS's maintainers were pretty clear about this when 
they were asked: https://www.spinics.net/lists/centos-devel/msg19564.html

"CentOS was NEVER bug-for-bug compatible. ... Sometimes CentOS shipped 
packages which did not have a particular bug because we could not 
exactly duplicate the build environment and other times we added new 
bugs because our build environment is not exactly the same... At best, 
CentOS has been "good-enough" compatible for a set of years "

And that's only for the packages that they actually shipped. CentOS 
never reproduced the extended life cycles that RHEL provided, which are 
what make minor releases actually valuable. Without the overlapping life 
cycles, there's just not a really good reason to have minor releases.

> The GPL *requires* Red Hat to publish the full sources including "the 
> scripts used to control compilation and installation of the
executable."

To customers, yes.

Red Hat goes above and beyond that requirement, by publishing the 
current state of the source code to the public, for both GPL and non-GPL 
software.

>> First, because Red Hat doesn't publish the information that would
be
>> required to create reproducible builds. 
>
> Yes they do - it's all in the SRPMs.

See https://reproducible-builds.org/ for more information.? It isn't all 
in the SRPMs.? As above, CentOS's maintainers were always clear that it 
was never possible to reproducibly build RHEL.

>>> 5. Red Hat's policy change contradicts the GPL's spirit.
>>
>> As you acknowledge, that's a subjective question.? I would say
"no."
>
> Seriously? You are the only person here who thinks that. 

I don't think I am, but it doesn't really matter.? Most of RHEL
isn't
GPL anyway.? Even if the subscription agreement only covered content 
that wasn't GPL, you still can't build RHEL from the GPL sources alone.

The GPL isn't anti-commerce.? It doesn't prevent the sale of software.? 
The spirit of the license is that users should be able to modify the 
code and build new systems, which they certainly can do with RHEL source 
code.? There's no secret sauce in RHEL that isn't publicly available to 
users who want to build something new.

On 2023-07-25 09:19, Gordon Messmer wrote:
>>> 5. Red Hat's policy change contradicts the GPL's spirit.
>>
>> As you acknowledge, that's a subjective question.? I would say
"no."
>
> Seriously? You are the only person here who thinks that. 

After reading an unrelated thread, I want to make an additional comment:

There are several reasons that I think that Red Hat's subscriber 
agreement is in the spirit of the GPL.? One of them is that nothing is 
developed in RHEL minor releases that isn't available to the public.? A 
RHEL minor release is just a snapshot of the major release branch (which 
is now used to build Stream), that Red Hat engineers continue to 
support.? Updates to the RHEL minor release are either a direct merge of 
changes from Stream, or backporting a fix if Stream has rebased a 
package which needs that fix.

If Red Hat were doing development in RHEL minor releases that wasn't 
published elsewhere, I would probably have a different view of thing, 
but they aren't.? There's nothing there that isn't published
elsewhere.

The *software* is freely available to everyone, through Stream.

RHEL is a *support* program that provides extended support to snapshots 
of the software (among other things), by applying patches that are 
generally available.

Providing support is not a violation of the spirit of the GPL.

Development all happens upstream, in publicly accessible repositories.? 
That's a core part of my outlook on the subject.