How the new Kernel SRPM distribution impacts CentOS

How the new Kernel SRPM distribution impacts CentOS

There seem to be many different articles concerning how Red Hat has chosen to distribute its Kernel Source Code (SRPM) in Red Hat Enterprise Linux. Here are a just a few of them:

Red Hat Fights Back

Why RHEL 6 Keeps Its Patches Under Its Hat

Is Red Hat violating the GPL?

Red Hat’s “obfuscated” kernel source

Red Hat has also responded in a couple of places, here are a few of those:

Commitment to Open

Red Hat: ‘Yes, we undercut Oracle with hidden Linux patches

The first thing I want to make perfectly clear is that this blog post is MY OPINION and it is not an official statement of or by the CentOS Project.

Now that we have that out of the way, the first issue I want to address is the suggestion by ITWire that Red Hat is somehow violating the GPL by distributing their source package with the patches already rolled in. They are not, most companies distribute their source packages as tarballs with all the patches already rolled in. Some companies (but not all) also provide all the Software Change Management (SCM) commits in a public place (like a SVN, GIT or CVS repository). This is not required. What is required is what Red Hat is doing, providing the source code to their customers.

The other thing the ITWire article does is that they have a link to a Red Hat “Terms of Service” for their websites and portals along with the claim that the this is a restriction on the Red Hat customers ability to distribute software. The only problem is, the link ITWire pointed to says that software is controlled by a different agreement altogether. The above link is for Use of Content, while Red Hat Enterprise Linux software is actually governed by the EULA link here. If you look at that EULA, you can distribute the software per the license of each package as long as you meet the trademark and logo requirements. Nothing new to see here, software distributing same as before, no GPL violations, no problems.

The other question that people seem to have is will the new method of the kernel delivery somehow impact CentOS and its ability to get the releases out. It should have no impact on the main CentOS distribution at all. We have built the EL6 kernels for testing and there is no impact. Where there will be a slight impact is the CentOS Plus kernel (which is something CentOS provides as added functionality). The CentOS plus kernel sometimes adds patches to fix problems that are delayed in upstream engineering or things they choose not to fix in architectures that they do not support. These kind of changes will be harder to make because some of these patches normally need to be done in a specific order to get them to apply in the most efficient manner. Or we might want to back out a specific patch and replace it with a different one. These kind of things will now be much harder. Instead of backing out the patch, we will need to modify the patch to fit OVER the already rolled in source code from Red Hat. It will take longer, or we may not even offer this service for CentOS-6.

I certainly understand why Red Hat is taking the action they are taking, it is fully GPL compatible, and it should have minimal impact on the main CentOS distribution. The CentOS Project wants (and needs) Red Hat to continue to be the premiere paid Enterprise Linux distribution for the United States and the rest of the world. I personally would rather Red Hat did not deliver their kernel this way, but it does not seem to be a major issue to me. Which is why it seemed to take 4 months before many people even noticed.

* This article was originally published here

Leave a Reply

Your email address will not be published. Required fields are marked *