Yes, you can. This is something everyone gets mixed up.
RHEL is built from CentOS Stream sources. The changes Red Hat made to RHEL source distribution mostly just make it more challenging to reconstruct an entire build of RHEL from CentOS Stream - because you would have to map backwards from all of the different versions of sources available in CentOS Stream to the exact versions that a particular version of RHEL happens to use. But at the scale of any individual project, it's trivial for any upstream community to just look at the latest CentOS Stream sources for one particular package, if they want to look at which patches Red Hat is applying. There are no legal or contractual restrictions on this whatsoever.
This is setting aside the fact that most patches are backports from one upstream version to another, and bugfixes that get submitted "upstream first" to begin with, which makes the whole discussion kind of moot. The typical scenario for a net-new bugfix would be that a Red Hat employee submits the fix upstream and gets it reviewed and merged by said upstream months before it ever sees the light of day in RHEL, so upstream maintainers would never need to look at the RHEL sources in the first place.
> Does this give Red Hat the right to effectively "close source" the code for RHEL despite contributions from the rest of the community?
Legally, yes. Not sure what the point is you're trying to make.
I'm not sure why anyone would want to use a downstream distribution of Red Hat if they don't like Red Hat's trajectory. If you don't like Red Hat's current objectives with RHEL, it should be as simple as: stop using something downstream of RHEL.
> Legally, yes. Not sure what the point is you're trying to make.
Legally, no; unless RH is the only copyright holder, they get to follow the same rules as everybody else, and for GPL packages that means not imposing additional restrictions on redistribution of source code.
> If you don't like Red Hat's current objectives with RHEL, it should be as simple as: stop using something downstream of RHEL.
People are fine with being a downstream of RHEL. It's being upstream of RHEL that's the problem; Stream is RHEL Beta by another name.
>Legally, no; unless RH is the only copyright holder, they get to follow the same rules as everybody else, and for GPL packages that means not imposing additional restrictions on redistribution of source code.
And there aren't any. "RHEL Linux" isn't GPL licensed, the kernel is, and glibc is, and systemd is, etc. Individually.
The sources for all of those packages (and ones that aren't GPL licensed, for which there is not actually a legal requirement to distribute sources), individually, are available via CentOS Stream just as they ever were.
What Red Hat has stopped doing is providing a git repo containing the exact combination of package sources which collectively make up one particular version of RHEL. Instead, all of the sources are still available, but if you want to rebuild the entire distro you need to figure out which particular versions to use. And that's exactly what Alma Linux does.
> "RHEL Linux" isn't GPL licensed, the kernel is, and glibc is, and systemd is, etc. Individually.
That is why I said "GPL packages", yes.
Okay, so if I buy RHEL, and I download the SRPM for the kernel, and I publish it - which I'm legally entitled to do, what with the kernel package being GPLv2 - is RH not going to terminate my RHEL license?
If you share RHEL sources with the original project communities, what happens?
>> Is there a single large FOSS project who’s git history isn’t filled with @redhat.com ?
Does this give Red Hat the right to effectively "close source" the code for RHEL despite contributions from the rest of the community?