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).

While Red Hats individual kernel patches are not available, they distribute the "squashed" sources under the terms of the GPL.

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.