(There has been some discussion on the BozemanLUG mailing list and I decided to post my initial response here also)
Greetings,
----- Original Message -----
> Also relevant, Alma and Rocky Linux posts:
> AlmaLinux: https://almalinux.org/blog/impact-of-rhel-changes/
> Rocky Linux: https://rockylinux.org/news/2023-06-22-press-release/
Generally speaking, I've been a big Red Hat fan since the mid-90s. I certainly don't claim to love every decision they have made over the years. I definitely didn't like that they killed CentOS Linux in favor of CentOS Stream... and transitioned CentOS, starting with version 8 forward, from downstream to upstream. I also definitely don't like this most recent change of them no longer publicly releasing their complete, corresponding source (CCS). Does the current change violate the GPL? I don't think so but I have no legal training and don't have enough knowledge to make an assessment. I'm guessing that they consulted their legal folks long before making this change and they wouldn't have made it if they thought it was a losing position.
To the best of my knowledge, the GPL has not been challenged in court and maybe this is the time for it to be... and if Red Hat is in violation, they should be held accountable.
One thing I do want to credit Red Hat with is their support of a large number of FLOSS development communities and producing a lot of free software. That is something I assume they will continue to do for some time to come. The good news is, that if any Red Hat customers aren't happy, there are plenty of alternatives to pick from.
After the dust settled from the CentOS Stream change, that just lead to an even better situation where there were/are multiple, good clones to pick from. After the dust settles from this no-more-public-CCS-release change, will that inadvertently lead to some currently unanticipated better situation? I don't know but my guess is probably. I haven't read Rocky Linux's response (yet) but I did read Alma's (yes, I prefer Alma)... and given the expertise of the company that founded Alma Linux, while I'm sure there are and will continue to be various challenges that will have to be met, I'm fairly confident that in the long run, there will be little to no user facing negative consequences. That's just a guess though.
The rebel part of me thinks that a cabal of Red Hat customers should ban together to share one source package each... so that the whole can be freed while making it really hard for Red Hat to do much about it. I guess they could try but I don't imagine they'll be too successful biting the hands that feed them. Alma already has to produce sources for packages that are required to build EL but that aren't actually released/packaged by Red Hat as they don't want to have to support those packages. Who-da-thunk that was a thing? ...but it has been a thing for a long time. Given the fact that Alma has been doing that for two major EL releases now is what gives me some confidence in their ability to overcome this situation. It will take some effort for sure.
My guess is that Red Hat's change on this was mainly to combat Oracle and that Alma and Rocky are just adjacent semi-bystanders but I have no real evidence to go by and could be completely wrong. If I was an IBM/Red Hat stock holder, I might be happy about this change. Ah, nuance.
I have to wonder just how many customers Red Hat has booted for real or perceived reasons. Not-very-many is my guess... and if correct, I'm also guessing it'll probably stay that way... but only time will tell.
Please note though that a license isn't a law... and regardless, I don't think they are doing anything illegal. Perhaps that is splitting hairs but I just wanted to differentiate between criminal and civil... but again, I'm fairly ignorant about legal matters so don't hold it against me if I'm mistaken.
I do appreciate the discussion on this topic that has taken place thus far and look forward to it continuing.
= = = = =
- Log in to post comments
Comments
A follow-up
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