CentOS - Jul 2023 - Current RHEL fragmentation landscape

I was trying to stay out of this thread, but the reply was complete and 
utter nonsense...

On 25/07/2023 01:24, Gordon Messmer wrote:
> On 2023-07-24 13:47, frank saporito wrote:
>> Let me know if you disagree with any of these statements:
>>
>> 1. Red Hat is no longer posting source code to git.centos.org.
> 
> 
> Correct.? Red Hat used to publish a de-branded subset of RHEL source 
> code there, and they've discontinued that process.? The current code
for
> RHEL is now published to the CentOS Stream repos.
> 
> 
>> 2. Red Hat will release source code to partners and customers via the 
>> Red Hat Customer Portal. (ref: Red Hat announcement)
> 
> 
> Also correct.? This is the only channel through which Red Hat ever 
> posted complete code for RHEL.? It hasn't been changed.
> 
Nonsense. For years Red Hat freely published the complete RHEL SRPMs to 
their public ftp server. It *has* changed, a number of times over the 
years as Red Hat increasingly seek to make it harder for others to 
exercise their GPL rights.
> 
>> 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. Red Hat seek to prevent their customers 
from exercising their rights under the GPL by imposing agreements that 
allow them to terminate their contract and/or take legal action if their 
customers choose to exercise their GPL rights.

Lets be very clear what Red Hat are doing (and to the best of my 
knowledge have always done).
> 
>> 4. Red Hat's policy decision has made it difficult (maybe
impossible)
>> for "clone" distributions to continue existing. (ref: Google
"red hat
>> source code")
> 
> 
> 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. CentOS did it for years, and so did Scientific Linux 
and others. The GPL *requires* Red Hat to publish the full sources 
including "the scripts used to control compilation and installation of 
the executable."

If it is not possible to create a clone, then Red Hat are not in 
compliance with the GPL.
> 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. I will concede that these need to 
be built in the correct order and thus within the correct buildroot (the 
skill that CentOS and others brought), but the information required "to 
control compilation and installation of the executable" is all there.
> But more importantly, because RHEL has one life cycle per minor 
> release, and distributions built from the old git.centos.org 
> repositories had *at best* one life cycle per major release.
> 
> CentOS Stream also has one life cycle per major release, and conforms to 
> the interface compatibility guide for the matching RHEL major release.
> 
> Distributions derived from CentOS Stream can have either lifecycles per 
> minor release *or* one lifecycle per major release.? Unlike the old 
> source publication process, they can have continuous or overlapping life 
> cycles.
> 
> Yes, this involves more steps than the old process.? The next natural 
> question is whether the additional work is justified by the improvement 
> in the outcome.? And from my point of view, that is a very easy
"yes".
> 
> I understand that it's confusing, but CentOS was never a substitute for
> RHEL, and never provided the benefits of RHEL's model.? It is not the 
> "free RHEL" that many users tend to think it was:
> 
> https://fosstodon.org/@gordonmessmer/110648143030974242
> 
> https://www.youtube.com/watch?v=tf_EkU3x2G0
> 
> ... and conversely, CentOS Stream is a much better stable LTS for 
> self-supported systems than you might believe:
> 
> https://medium.com/@gordon.messmer/in-favor-of-centos-stream-e5a8a43bdcf8
> 
> 
>> 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.

The GPL grants the rights to redistribute sources. It goes further, it 
specifically states:

"  To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.

   For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have.  You must make sure that they, too, receive or can get the
source code.  And you must show them these terms so they know their
rights."

Red Hat's terms specifically contradict that and specifically prohibit:

"using Subscription Services in connection with any redistribution of 
Software"

in section 1.2 (g) (d) of their terms (below), considering it a 
"material breach of the Agreement" (IANAL, but that sounds like legal 
speak):

https://www.redhat.com/licenses/Appendix-1-Global-English-20230620.pdf

Now you may consider the above subjective, but in doing so you lose all 
credibility on this list.

I understand the above has yet to be tested in a court of law, but there 
is no doubt it does not comply with any reasonable interpretation of the 
intent of the GPL.

Further, there can be no doubt that Red Hat fully understands this too. 
Red Hat's own definition of Open Source can be found on their website:

https://www.redhat.com/en/topics/open-source/what-is-open-source

"Open source is a term that originally referred to open source software 
(OSS). Open source software is code that is designed to be publicly 
accessible?anyone can see, modify, and distribute the code as they see
fit."

yet Red Hat's own terms explicitly seek to prevent this. And you. Gordon 
Messmer, think this is not contradictory?

> I think the entire history of the free-as-in-speech vs free-as-in-beer 
> clarification is proof that we wanted to ensure the right to improve 
> software if you didn't like its limitations, not the right to give away
> software if you didn't like its price.
> 
> But I also think it's important to acknowledge that the thing that 
> rebuilders are asking for (the RPM source repositories) aren't GPL 
> licensed, they're MIT licensed, which makes the question something of a
> non-sequitur.
>

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.