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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
