Quoting Russ Herold from the article: Nothing in Red Hat's new approach prevents a person from running a local version-control system, containing the pristine kernel at point A, and the Red Hat variant which we might call point B. Then one runs a 'diff' in that version-control system between A and B, and starts reading the diffs to see what is happening. Over time, both the pristine kernel, and the patched Red Hat versions will vary, and one will get a sense for which 'diff' parts matter, and which are cosmetic cleanups.
This actually sounds labour intensive.
From the Centos mailing list, Johnny Hughes writes: That is not to say I like the changes, as it will have impacts ... but as long as they only do it to the kernel, it is not a big problem.
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.
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.
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.
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.
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.
12 comments
[ 0.15 ms ] story [ 1183 ms ] threadThis actually sounds labour intensive.
From the Centos mailing list, Johnny Hughes writes: That is not to say I like the changes, as it will have impacts ... but as long as they only do it to the kernel, it is not a big problem.
http://www.linux-archive.org/centos/497467-will-centos-becom...
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.
Complaints about non-profit groups "free-loading" on GPL projects are ... "impressive"... What part of "free" don't they understand?
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.
This is a complete non-issue to CentOS.
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.
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.
http://www.gnu.org/licenses/gpl-faq.html#DistributingSourceI...