I wish I could say that I don't think this is compatible with the GPL, simply because I don't like it, but I can't. This seems like a good move for their bottom line. It'll suck for CentOS users though.
back
4 comments
CentOS users are basically free-loading, though, so if this bothers them they'd probably be better switching to a pure-community effort like Debian. If they're using CentOS because their company uses it, their boss can also pony up for some Red Hat licenses if they encounter problems.
Once you release your work under an open source license, you've pretty much declared that "free-riding" is ok, to a certain extent.
I mean, if you look at it, Red hat itself gets a lot of free input. Although they also do contribute a lot themselves, I'm sure they receive more open source software than they create.
Open source != support. CentOS is using GPLed code, which is perfectly fine, but they have not reason to expect Red Hat to help them support it or otherwise do anything other than release changes.
In this case, the value added by CentOS is relatively small - mostly hosting - and so it's not particularly persuasive when people complain about Red Hat, which currently provides considerably more to the community even without detailed change logs.
Yes,
Complaints about non-profit groups "free-loading" on GPL projects are ... "impressive"... What part of "free" don't they understand?
Or not at all. CentOS rebuilds the kernel SRPM as it sits; they're bugwise-compatible with RHEL.
This is a complete non-issue to CentOS.
Maybe not for CentOS as a project, but it can be disadvantageous for CentOS as a community. If you are running CentOS, and run into some new bug, you cannot easily back out or cherry-pick patches.
A more interesting question is how this affects Oracle. In Unbreakable Linux 5 they replaced Red Hat Enterprise Linux' 2.6.18 kernel by their own custom 2.6.32 build.
Since Red Hat is pretty agressive at getting changes merged in mainline, Oracle can profit from their work anyway.
IANAL, but the GPL version 2 is incredibly vague about this:
The source code for a work means the preferred form of the work for making modifications to it.
One could argue that having a patch set or git repository is the preferred form of the work for making modifications to it, especially considering how upstream provides their sources.
But as is often the case with the GPL, it is nearly impossible to understand its implications.
The FSF actually says that, to comply with the GPL, you must distribute full source, not diffs.
http://www.gnu.org/licenses/gpl-faq.html#DistributingSourceI...
Why do people seem to think this is so bad for CentOS users? It seems to me that if the CentOS devs quoted don't find it to be a big deal, it probably isn't. They know better than you or I.
I said "users" for a reason. It's just about choosing the patches that you want to apply, or if something you're running breaks, backing out of the particular patch that screwed it up. It really increases the value of a Red Hat license in my eyes.