[BozemanGLUG] Redhat violating GPL?

[Scott Dowdle]

Greetings,

----- Original Message -----
> To the extent that this means that all the GPL code in RHEL is on a
> CentOS git repository, I consider this a reasonable defense against
> GPL violations.

Yes, the code is released that way... via CentOS Stream's GIT, which isn't as consumable by a rebuilder/rebrander as SRPMS would be.  There is no requirement as to what form the code has to be released as long as it is actually the code that is being used and not some decoy of some sort... which is often referred to as "throwing the code over a wall".

> I do still think that if this statement from Alma Linux is correct,
> Red Hat is violating the spirit, and possibly the letter of the GPL:
> 
> "the way we understand it today, Red Hat’s user interface agreements
> indicate that re-publishing sources acquired through the customer
> portal would be a violation of those agreements."
> 
> Alma's and Red Hat's statements seem to be in conflict.

Red Hat releases SRPMS for their packages through their customer portal... so both paying and free accounts can get access to the code in an easy to consume way.  They have always released them there.  The difference is that users who download it there, aren't allowed by their service agreement to re-publish the SRPMS... which would primarily be useful to rebrander/repackagers.  Red Hat is basically trying to negate an account holder from sharing their membership benefits with non-members.  Non-members aka the general public, has a different way to get the source code... and that would be via CentOS Stream's GIT.

The GPL says if you distribute a binary, the source must be available.  Since Red Hat only releases the binary packages to registered users (paying and free), they are only obligated to release the source to that group.  If they were releasing their binaries publicly, they'd be obligated to release the sources to the public.  They still do that though, just in a different format (that is less convenient to consume for rebrander/rebuilders) as you mentioned (CentOS Stream GIT).

There are also some ways that Red Hat releases a subset of their binaries publicly, like with their container images.  So, for those packages, they WILL continue to release the SRPMS publicly.  Where those would be published, I'm not sure as I'm not that familiar with their container images.

> Also, I am curious to see how Alma and Rocky Linux continue forward.

As I mentioned in a previous post, and I'm sure this is also similar for Rocky Linux, AlmaLinux already has an additional repository (devel) that they maintain that is made up of > 2,000 packages (for EL9 in this example) that they've had to cobble together themselves.  This is a bit complicated to explain, but during the building of all of their official packages, Red Hat ends up using a significant amount of additional software that they do not package at all (no binary package nor source package)... for a number of reasons.  Sometimes it is licensing issues... but more often than not... it is software that they do not want to support.  Those packages aren't needed to install any of the the binary packages, but are needed to build the official packages from source.  I wish I had a good example that would clarify, but I don't know any off the top of my head. That is how it has been since the very beginning of RHEL and the main reason CentOS, when it was 100% volunteer, had trouble keeping up... and would often significantly lag behind a new major release.  Please note, there isn't anything secret about these extra needed-but-not-distributed sources, they are gotten from their upstream providers... but figuring out which release of the source was used is the main mystery as that info hasn't ever been published.  In fact, building a new major release over time, there might be multiple versions of some software packages that are used.

The reason I bring up the previous paragraph is to show that the rebranders/rebuilders have already been filling in a significant gap.  Their main challenge now is that, while they have access to the sources from CentOS Stream GIT (and CentOS Stream SRPMS), there will likely be some package versions (relatively small) that are newer than what is packaged in RHEL.  That's what the "might not be on HEAD" reference was about.  In theory, since GIT is for checking in every version/step in the software's development, trying to match RHEL's source from CentOS' source may take going through some of the later pull requests to remove what was added to Stream but not added to RHEL (yet).  Given the experience that rebuilders already have with the category of packages I mentioned in the previous paragraph, I don't think figuring out the small number of different packages between CentOS Stream and RHEL will be all that difficult... just more work.

Given the guessing that has already been going on, there will always be a certain amount of variance between RHEL and a rebuild... and that claim of "100% binary compatibility" is a best effort.  It has never been as simple as, pull SRPMS, build SRPMS.  Getting that build environment to match as closely to that of RHEL has always been the time-consuming challenge.

TYL,
-- 
Scott Dowdle
704 Church Street
Belgrade, MT 59714
(406)388-0827 [home]
(406)994-3931 [work]