That's not accurate. Everything Red Hat does is OSS. Their kernel patches are developed in the open, and available to anyone. The only thing they restrict is binary distribution.
To belabor the point, it is my understanding that CentOS is literally identical to RHEL minus a couple identifiers (/etc/issue and the like) and a license with a support contract. You can even convert it into RHEL by buying a license and installing a couple packages.
CentOS can ship a system that's effectively identical to RHEL because Red Had publish their patched kernel source. What they don't distribute publicly and is only available to customers, under penalty of contract termination if they release it, is the patches that make up their kernel. So non-customers can't easily tell what they've changed, back out patches that break stuff, or cherry-pick patches for non-RHEL use. This is obviously nicer than the gresecuriy approach but there's no obvious reason why it's any more legal.
What is the difference between "patched kernel source" and the "patches that make up their kernel"? It sounds like maybe you are saying that they just provide the source from release to release, not the Git (or similar) history with each commit they make. But since they release the source of each release, it sounds like that satisfies the GPL, and giving customers Git history or equivalent is an additional perk.
"but there's no obvious reason why it's any more legal."
I don't follow this logic. Red Hat distributes the entire source of the kernels they ship, in a form that anyone can use, change, and redistribute. That satisfies the legal definition and the spirit of the GPL. They do not prohibit their paying customers from enjoying any of the rights guaranteed by the GPL.
grsecurity allegedly prohibits people from doing that.
If what you say is true, and I have no doubts you are correct, then how is Red Hat's kernel policy different from Grsecurity? They both alter the kernel and contractually bind the recipient not to distribute the source on pain of contract termination. I'm not asserting bad / good. I'm would like to know the difference.
"They both alter the kernel and contractually bind the recipient not to distribute the source on pain of contract termination."
Red Hat does not contractually bind anyone to not distribute source. They just don't. They distribute the source themselves, without contract or cost.
And, Red Hat employs several of the largest contributors to the mainline Linux kernel. Most of the time, if something is in the RHEL kernel, there are people working on pushing it into the mainline kernel either before or after it goes into the RHEL kernel. Red Hat has consistently and for decades worked with the Linux community to build a better kernel.
I'm not trying to be a Red Hat fanatic or anything, but they've been trotted out multiple times in this thread as being "just like grsecurity", and it's just flabbergastingly wrong to compare the two.
The only thing I'm aware of that Red Hat sort of locks away is their documentation and knowledge base, as well as the binary builds. It contains specific information about patches that backport CVE fixes, bugfixes, etc. The kernel sources are maintained in an internal revision control system and pushed out as a tarball (which is then integrated into CentOS and other RHEL derived distros).
There is a wealth of knowledge in there if you're looking to solve specific enterprisey problems, but it's not necessary to have access to any of it to track what changes Red Hat makes to their kernels and to reproduce them from freely obtainable sources. I don't think you're even prohibited from sharing what you learn from their customer portal resources; though copy-pasting the whole thing into the wild is certainly a copyright and/or license violation and might get you some sort of trouble.
But, the premise of the comparison that Red Hat will somehow penalize someone for distributing RH sources (which has also been alleged in this thread) is just wrong. You can get and copy and modify and redistribute the kernel sources from RH; whether you get it as a paying customer in the form of RHEL or from CentOS for free. Red Hat will not penalize you for doing so, nor will they end any contracts you have with them.
The change to a mashed together tarball rather than a mainline kernel with patches applied was a direct response to Oracle rebuilding RHEL from sources and calling it Oracle Linux. It's unfortunate (I used to maintain a bunch of kernel RPMs, and it was nice having all the independent patches), but it's not a violation of the license, and it's still entirely possible to distribute custom RHEL-based kernels; you just have to actually know what you're doing to do so. There's no more copypasta-custom kernel building, in the general case. If you follow their kernels, maybe keeping your own revision control of them, you can see what changes between each revision, and it would be possible to parse out the specific patches in a lot of cases with relative ease. But, none of that is necessary to be compliant with the GPL.
The GPL requires you make the source code available to anyone you distribute to, and under the same terms as the kernel itself. Red Hat does exactly that (and then some, by maintaining CentOS).
Thanks for the answer. Is the removal of the context of the changes generally considered acceptable? We have a Red Hat license, but frankly, I am more a BSD person and our use of Red Hat is a requirement for specific programs.
Yes, it is well-understood to be acceptable. In the past, most commercial Linux distributions were developed behind closed doors in private revision control and pushed out as "complete" source packages. We had these conversations back then (~20 years ago), and the community and the companies involved came to mostly agree about what is and isn't OK. That's opened up a lot in recent years, such that these days "open source" usually means, "we have a public git repository", but it does not have to.
The GPL provides you some basic rights: you can request the source in a usable form, you can change it, you can redistribute it under the same terms.
It does not require access to the process that produced the software.
These days, Red Hat develops almost everything way out in the open. Contrary to all of the talk in this thread where folks (mostly just one guy, actually) keeps implying RH are violating the license or making it hard to get and distribute source, you can see discussions and the actual code being worked on months in advance of what will be in RHEL by following Fedora development. Fedora is developed entirely in public repositories and mailing lists, and it is where much of RHEL development takes place (RHEL trails Fedora by about 12 to 18 months, in terms of versions, and things that will be in RHEL next year are in Fedora today). Red Hat is an excellent OSS company who do damned near everything right, IMHO. Any complaints I might have about some of their practices (like I said elsewhere, I liked having a kernel SRPM that was the mainline kernel plus listed patches, and I miss it being that way) pale in comparison to the good they do for the OSS community.
Just because they make a lot of money doesn't mean they're cheating the community out of anything.
If I understand it correctly, you can distribute Red Hat's source all you want, but it's up to you to figure out which bits of the kernel that is. That extra information is not part of the code.
