Red Hat and the GPL [LWN.net]

Red Hat and the GPL

Posted Mar 10, 2011 16:38 UTC (Thu) by gregkh (subscriber, #8)
In reply to: Red Hat and the GPL by branden
Parent article: Red Hat and the GPL

>That Greg K-H singles out a Debian kernel maintainer, Maximilian
>Attems, for praise specifically regarding the matter of unscrambling
>the RHEL kernel egg suggests very strongly to me that Debian's got a
>better handle on the preferred form of distributing a patched Linux
>kernel than Red Hat currently does.

Please do not read ANYTHING into my comments about this other than explicitly what I stated.

I thank Max for doing this work as it is great stuff and benifits all of the distros when he does so. It has nothing to do with how Red Hat distributes their kernel and my viewpoint of that being a "better" way or not at all.

My personal opinion is that Red Hat is fine in doing this if they want to. It's their kernel, their process, and they are abiding by the GPL just fine.

(Log in to post comments)

Red Hat and the GPL

Posted Mar 10, 2011 23:39 UTC (Thu) by branden (subscriber, #7029) [Link]

"Please do not read ANYTHING into my comments about this other than explicitly what I stated."

I was not trying to do, nor imply as much.

It is challenging for me to understand how a roster of RHEL's patches to its 2.6.32 kernel has value when Mr. Attems excavates it, but not when Red Hat provides it.

Because if it has value both ways, then clearly Red Hat has removed value from their kernel SRPM offering.

The pregnant question is whether such removed value brings the RHEL kernel SRPM below the threshold of being a "preferred form for modifying the work".

I acknowledge that, in your assessment, it doesn't.

Red Hat and the GPL

Posted Mar 13, 2011 2:06 UTC (Sun) by vonbrand (subscriber, #4458) [Link]

Yes, a single tarball is less valuable than a upstream tarball + individual patches + running commentary. But that is wide off the point: GPL does not mandate distributing the later, only the former. Sure, I'm miffed that I don't have access to a valuable resource anymore, but that doesn't make Red Hat's actions against GPL.

Red Hat and the GPL

Posted Mar 11, 2011 9:25 UTC (Fri) by PaXTeam (subscriber, #24616) [Link]

> My personal opinion is that Red Hat is fine in doing this if they want to.

then why did you see the need to explicitly call them out in the 2.6.32.30 announcement?

> Red Hat didn't make this very easy due to their "one giant patch" format[...]

now imagine if *everyone* else followed suit, where would that leave Linux development? is that the future you envision?

Red Hat and the GPL

Posted Mar 11, 2011 16:45 UTC (Fri) by gregkh (subscriber, #8) [Link]

I only "called out" a thanks to Max for digging through the large
patch from Red Hat to figure out what patches should be applied.

That work was hard based on the format that Red Hat is shipping their
kernel patch in these days, and the work should be thanked. It has
no relevance on my opinion of what Red Hat is doing here.

>> Red Hat didn't make this very easy due to their "one giant patch"
>> format[...]
>
> now imagine if *everyone* else followed suit, where would that leave Linux
> development? is that the future you envision?

Um, this makes no sense as that is not how upstream development works.
If the upstream development procedure changed to be this way, then that
would be a different conversation and topic. But as it is, it has no
relevance at all here.

Red Hat and the GPL

Posted Mar 11, 2011 22:43 UTC (Fri) by PaXTeam (subscriber, #24616) [Link]

> That work was hard based on the format that Red Hat is shipping their
> kernel patch in these days, and the work should be thanked.

actually, i forgot to point it out previously, that 'kernel patch' does not exist. what does exist is a big monolithic tree with all changes applied on top of whatever base they had at the time.

> It has no relevance on my opinion of what Red Hat is doing here.

you just called this 'digging through their giant patch' hard the second time now. in my little world that's an opinion, and not exactly a flattering one (note how you thanked someone else, not RH).

> Um, this makes no sense as that is not how upstream development works.

we're not talking about upstream development. we're talking about RHEL development. they're two different 'products' with different development methods. what i was pointing out is that if all similar products (to RHEL, not upstream) began to distribute their derived works the RHEL6 way, what would you think of that? still be ok with it?