Red Hat and the GPL
Red Hat and the GPL
Posted Mar 9, 2011 5:05 UTC (Wed) by branden (guest, #7029)Parent article: Red Hat and the GPL
Mr. Edge omits the case of preprocessed source as a "preferred form for modification", a case Mr. Corbet is well-aware of (having cited it himself), and of which the senior editor should have made him aware when assigning this story.
In the post-preprocessed source scenario, the source is all there. No variable names are obfuscated or rendered into gibberish (macros and preprocessor symbols aren't variables or function names). Nothing is split up in a difficult way; in fact, you tend to get more code at once for a more holistic source code experience.
It's surely far superior to a cuneiform tablet.
Similarly, we can view Red Hat's monolithic kernel source RPMs as an *improvement* over that unwieldy, tedious, split-up pile of rubble called patches to the upstream source.
Ergo, shipping post-preprocessed source as a means of complying with section 3 of the GNU GPL (version 2) is fine and dandy.
Moreover, the fact that the entire community (including those trivial portions not in the employ of Red Hat Software, Inc.) generally hand-waves away strict enforcement of section 2a, usually in favor of exterior changelogs, as acknowledged by GNU GPL version 3, is entirely beside the point. It is within copyright holders' prerogatives to overlook certain strict infringements, either because they were ill-considered in the first place, as I submit is the case with section 2a, or for any other reason.
If the widespread non-enforcement of 2a has any weight at all, then it applies just as well against *all* of the provisions of the GPL, including those contravened in situations Mr. Edge *does* recognize as infringement.
Another point: the facile notion that because "Red Hat has a top-notch legal team with a lot of GPL experience", they are unlikely to "believe it is [in]defensible in the unlikely event of a lawsuit" exposes its own flaw upon close reading.
Companies can and do infringe copyright knowingly and willfully. Why? Because they perform risk and cost-benefit analyses and decide that the business is best served by doing so; the multiplicative product of the likelihood of being challenged with the expected impact on the business if they are falls below a certain threshold of discomfort.
Red Hat's legal team can believe their actions with the kernel SRPM to be a GPL violation and proceed to do it anyway. If they do, no doubt they share Mr. Edge's assessment that facing a lawsuit from any copyright holder in the kernel is "unlikely".
This is particularly true if Red Hat can convince those copyright holders that those whom they are inconveniencing with this move are unsavory and unsympathetic. Hence the emphasis on free-riders, rather than on independent distributors of the Linux kernel who undertake their own development efforts and contributions. Thus, not only does ignoring the Debian Project's efforts fit Red Hat like a comfortable old shoe for distribution and packaging format rivalry reasons, it's tactically important. Red Hat needs to keep the eyes of the community on "parasites", not legitimate Linux distributions (however benighted they may be for not joining the Red Hat monoculture).
That is only one tool in Red Hat's box. If a copyright holder in the Linux kernel does squawk, they can 1) ignore the complaint; 2) settle for cash; or 3) break out patches touching the files in which that person (or other legal entity) has rights in future releases as a means of compliance. The last option does have the consequence of throwing a bone or two to the supposed free-riders, but it has to beat reverting this decision entirely.
In short, it simply does not follow at all that Red Hat has a bunch of smart lawyers who don't feel confident they would prevail in litigation. Perhaps they do; but the proper means for a journalist to determine that is through an interview with a person privy to their deliberations, not conjecture.
Congratulations, Mr. Edge, your analytical acumen has me considering canceling my subscription to LWN for the first time ever. (As it happens, though, there's no interface for doing that...)
Posted Mar 9, 2011 5:37 UTC (Wed)
by frnknstn (guest, #68647)
[Link] (10 responses)
If that is true, then supplying preprocessed source code is supplying partially compiled source code, and thus insufficient for GPL compliance.
Posted Mar 9, 2011 5:48 UTC (Wed)
by branden (guest, #7029)
[Link] (9 responses)
The second question is arguable. Preprocessing certainly is not compilation in the classical computer-science sense.
The output of a macro assembler after it has expanded macros is no more object code ready for execution by the host CPU than the output of the C preprocessor is.
To extend your reasoning, enumerate the other "steps of compilation". Assembly is also compilation. So is optimization. So is linking.
What does that leave?
Well, uh, "compilation".
As is often the case, terms have contextual definitions. In some contexts, everything that happens after you execute gcc is "compilation". In others, gcc does a whole bunch of things, only some of which are "compilation".
I think it was astute of Mr. Edge to leave out the preprocessor-output-as-source-code angle, frankly. A close look at that example makes the case against Red Hat's decision with recent kernel SRPMs stronger, not weaker--and that's not the conclusion he wanted to reach.
Good polemics. Substandard journalism.
Posted Mar 9, 2011 10:39 UTC (Wed)
by AlexHudson (guest, #41828)
[Link] (6 responses)
I suspect the number of people who see separate "per-bug" patches as being less useful and a step backwards from a monolithic patch are going to be relatively small. Just considering bidirectionality (the ease of making a monolithic patch versus the difficulty of splitting a monolithic patch) makes that a very difficult argument to subscribe to.
So maybe tone down your own polemic about the standard of journalism.
Posted Mar 9, 2011 16:28 UTC (Wed)
by MisterIO (guest, #36192)
[Link] (5 responses)
Posted Mar 9, 2011 20:31 UTC (Wed)
by branden (guest, #7029)
[Link] (4 responses)
My sarcasm was too subtle, alas.
My point was that one big blob of post-cpp C source code is less useful than the original separate .c and .h files, as a monolithic kernel is less useful than a pristine upstream kernel plus a pile of patches.
In both cases, atomization and logical separation is valuable, even essential for downstream to developers to be on equal footing with the distributor. It is that equal footing that the GNU GPL seeks to establish and sustain.
I twigged that Mr. Edge understood how the preprocessor analogy weakened, rather than strengthened, the argument he wanted to make, and that that is why he omitted it despite it being one of the first examples on Mr. Corbet's lips (well, fingers) when the subject came up in an earlier LWN comment thread.
Posted Mar 9, 2011 21:17 UTC (Wed)
by jake (editor, #205)
[Link] (3 responses)
No, I'm afraid that's incorrect. I didn't even consider the "preprocessor analogy" when writing the article. I don't think it weakens the case that Red Hat is not violating the GPL either.
Red Hat distributed its kernel the same way that various other projects have distributed theirs (including FSF projects). They are also distributing their kernel the same way that lots of embedded vendors do, and the community seems perfectly happy with those embedded vendors when they finally get around to doing so. Why is Red Hat different than the FSF or HTC?
I don't have to like what Red Hat is doing (I don't) to see that it doesn't rise to the level of a GPL violation, at least in my opinion. You are, of course, welcome to your own opinion on the matter.
jake
Posted Mar 9, 2011 21:43 UTC (Wed)
by branden (guest, #7029)
[Link] (2 responses)
"No, I'm afraid that's incorrect. I didn't even consider the "preprocessor analogy" when writing the article. I don't think it weakens the case that Red Hat is not violating the GPL either."
Ah. I must wistfully admit that I wish you'd had a phone conversation or brief email exchange with Mr. Corbet about this, then. It seemed to be an example that was eminent in his mind when he commented in the past week or so.
"Red Hat distributed its kernel the same way that various other projects have distributed theirs (including FSF projects)."
The FSF has copyright in most of the works they distribute, and I can assure you with near-certainty (as I work professionally in this area) that for their most popular and well-known works (glibc, gcc, gdb, bash, ncurses, binutils, etc.) that what little third-party copyrighted code is present is *not* under the GNU GPL, but under far more permissive licenses, such as BSD-style without the advertising clause, the MIT/X11-style license, or others closely resembling the foregoing, none of which mandate redistribution of source forms at all.
Red Hat, as a licensee of the Linux kernel under the GNU GPL, has a responsibility not only to their downstream users but to the other copyright holders in the kernel as well.
Maybe all of the other copyright holders in Linux are cool with this decision. Or maybe they're not, but don't feel they have sufficient resources to pick a fight with a well-heeled public corporation. Or they're not, but have a personal affinity with Red Hat kernel engineers and feel a sense of gratitude to the firm for offering their friends employment. Or they're not, but feel that Red Hat is still a net positive force in Linux kernel development. LWN could try interviewing some of them to find out what they think.
Copyright law is only one avenue of persuasion. Another is the court of public opinion. I had hoped that LWN, as the news outlet of record in Linux kernel development, would have taken a stronger stance against this move.
What Red Hat is doing is corrosive to the community. The reason people are looking closely at the GNU GPL version 2 for possibilities of a license violation here is that this document, in spite of some members' institutional and/or personal biases against the FSF and RMS, is the pre-eminent social contract under which our community has operated for twenty years.
The GNU GPL has a spirit and a letter; both are important and it is foolish to denigrate either, when both have proven their utility time and again. (I invite anyone who doesn't think the GNU GPL has a spirit to read competing licenses like the CPL, the EPL, the MPL, or the APSL, and then reconsider.)
You just said that you don't agree with this decision. Why, then, write an article which gives Red Hat cover for it? Why offer apparently unsourced speculation as to the views of Red Hat's attorneys when you can speak with perfect authority about your own view?
Make your stand, LWN!
Posted Mar 9, 2011 21:56 UTC (Wed)
by corbet (editor, #1)
[Link] (1 responses)
Well, I did review the article before it was posted... I don't see how the preprocessor discussion changes things here. The GPL requires distributing the source that you modify. Preprocessing it would violate that; shipping your source tree does not.
As a copyright holder in the kernel, I do not agree with or appreciate Red Hat's move in this area. That is a feeling I have communicated on this site and to the people involved in making the decision. It is a step in the wrong direction.
That does not mean that I believe the GPL can be used to force Red Hat to change its mind. As far as I know, nobody has ever challenged tarball distribution of source in all these years. Why would we try to start now?
I am sorry you do not like the stand we have taken. But I still don't believe that this action, obnoxious as it is, can be called a license violation.
Posted Mar 10, 2011 0:43 UTC (Thu)
by branden (guest, #7029)
[Link]
The text of the GPL does not mention the C preprocessor. "Everybody knows" that running source through cpp prior to distribution renders it violative of the GPL. Because this is a comfortable old truth, we haven't troubled ourselves to re-justify it from first principles again.
I think that if you explicitly articulate the reasons why post-preprocessed source code is inadequate to meet the definition of source code under the GNU GPL, the case against Red Hat's monolithification of their kernel SRPMS will become more clear.
I have tried to elucidate the matter myself, but I am clearly not a persuasive enough exponent.
Posted Mar 9, 2011 14:00 UTC (Wed)
by samth (guest, #1290)
[Link] (1 responses)
If you look up the Dragon book, you'll see that they write "a compiler is a program that reads a program written in one language -- the source language -- and translates it into an equivalent program in another language -- the target language". This fits cpp and gas just as it does gcc.
Posted Mar 9, 2011 20:36 UTC (Wed)
by branden (guest, #7029)
[Link]
You might as well just call me names, man--it would save time.
Posted Mar 9, 2011 13:12 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link]
The preprocessor is going to introduce lots of duplication in the output compared to the its input. It is not going to simplify modification in any way, except possibly if the non-preprocessed source code is already obfuscated in some why (e.g. one line per file with lots of #includes). So, the first step in performing a modification is not going to be "build the preprocessed sources".
The first step in performing most modifications from a "tarball+patches" form will be to get the sources with all patches applied. This is enough to show that, even though not distributing the history may indeed remove some interesting information, the two scenarios are completely different.
Posted Mar 9, 2011 14:55 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (17 responses)
Posted Mar 9, 2011 21:05 UTC (Wed)
by branden (guest, #7029)
[Link] (16 responses)
My argument rests solely upon the form the source code takes after the corresponding binary leaves the company. I don't care about VCSes; I care about non-obfuscated source forms.
Red Hat's kernel SRPMs can be as monolithic and obfuscated as they want as long as they don't distribute the binary RPMs that they could generate.
No, that wouldn't be a useful thing to do, but Red Hat's revenue model is their problem. Their compliance with the GNU GPL is everyone's.
Posted Mar 9, 2011 23:11 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (15 responses)
Posted Mar 10, 2011 0:54 UTC (Thu)
by branden (guest, #7029)
[Link] (14 responses)
I make no absolute guarantees. But the distinction between a .tar.gz for "Debian native" packages with no upstream and .orig.tar.gz plus .diff.gz for packages with upstream goes way, way, way back in the Debian Project--farther than either of our memberships.
It was standard practice. It was sound practice. Surely through carelessness or cluenessness, exceptions will arise.
I will not insult Red Hat Software by ascribing idiocy to them. This move was fully deliberate.
I maintained the XFree86 .debs without using a VCS for longer than I care to remember. It's the precise reason my changelogs became exhaustive swiftly after I adopted it. And when I did put them in a VCS, I was scrupulous to copy every changeset commit message into the package changelog (with exceptions for bonehead moves I backed out prior to a package release).
You're pointing at one aspect of common practice, bellowing loudly to call attention to it, while leaving another important aspect of common practice quietly unremarked.
I keep saying it and people keep ignoring it, because they are evidently desperate to rephrase the community's upset into a demand for public git access: restore the patch and changeset information as it existed prior to this move, and all of this will go away.
I won't say that nobody gives a damn what VCS Red Hat uses, but I'm sure the GNU GPL doesn't.
Posted Mar 10, 2011 1:24 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (13 responses)
Posted Mar 10, 2011 1:53 UTC (Thu)
by branden (guest, #7029)
[Link] (12 responses)
I dispute this assertion. For big packages like X and the kernel, Debian developers sure as hell did. That's why so much effort went into dbs and people took up becoming dpkg developers to extend the source package format, even though dpkg's own source code was formidable (as was the threat of Ian Jackson opining in public on one's enhancements) and it had a reputation for being a bourne from which no Debian developer returnethed.
For packages where either 1) the code itself was really small (some consist of only a single program file), or 2) the delta between upstream and Debian was really small (often only the contents of the debian/ directory), a "monolithic" diff was satisfactory and best practice.
But for packages not fitting in these categories, Debian developers started atomizing patches to be of changeset granularity *at least* ten years ago.
Why? Because it was the preferred way to hack.
Because it was the preferred form for modification of the code.
And that's right when the bell should start ringing. I'm disappointed that you have muffled your clapper. But you're not alone.
Posted Mar 10, 2011 2:03 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (11 responses)
Posted Mar 10, 2011 3:05 UTC (Thu)
by branden (guest, #7029)
[Link] (10 responses)
But for those which are, if the copyright holders have a consensus view that one unpatched tarball is all they deign to provide, then there is no GPL issue.
I have already said multiple times that if all the copyright holders in the kernel are cool with this (or disappeared, or disinterested), then there is little practical that can be done on the legal front. Only copyright holders have standing to sue for infringement of their copyrights. In the case at issue, Red Hat subscribers *might* have standing to sue on different grounds, breach of contract, if the subscriber agreement promises, explicitly or implicitly, that packages provided under the agreement will be delivered in compliance with their applicable copyright licenses. I honestly don't know whether this is the case for the RHEL subscriber agreement, as I haven't read it in something like seven years.
Could you make this less hypothetical and name some examples of packages that meet your qualifying criteria?
Posted Mar 10, 2011 3:20 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (9 responses)
Posted Mar 10, 2011 16:34 UTC (Thu)
by branden (guest, #7029)
[Link] (8 responses)
Of what? You said earlier:
"The simple and obvious fact is that some upstream projects only distribute patchless tarballs despite their development being performed in a patch-oriented manner. ... Debian ship these projects anyway, which implies that nobody seriously thinks that they're violating the GPL."
Debian's packaging of the Linux kernel is not an example of this at all, and hasn't been for several years. Have you forgotten how Debian handles its kernels? I'll grant that things might have changed in the past few years, but they don't appear to have done. What you get on a freshly-squeezed (natch) system is, structurally, what you'd have gotten several years ago:
linux-patch-debian-2.6.32 - Debian patches to version 2.6.32 of the Linux kernel
Have a look sometime.
Here's a terminal transcript, edited for space and clarity:
$ apt-get source linux-patch-debian-2.6.32
Not only does Debian make scrupulously clear what patches are applied, they ship 1024 files of them (props to the Debian kernel team on that nice round number), which anyone will tell you is a superior way of tracking 37 megabytes' worth of patches than one file (or zero, with one manually constructible by diffing against kernel.org).
Above and beyond this, Debian *does* do what no one is claiming Red Hat needs to for GPL compliance--it provides a link to the distributor's public VCS for package development is announced to the user upon download of the source package (neat new feature there).
So, uh, what's your claim about the GPL-noncompliance of Debian's kernel, again?
"There's various bits of software I've released where I've never pushed a repository (or even a changelog worth a damn). It's not a question anyone's ever really asked before this issue."
I already spoke to this above, when I said, "For packages where either 1) the code itself was really small (some consist of only a single program file), or 2) the delta between upstream and Debian was really small (often only the contents of the debian/ directory), a "monolithic" diff was satisfactory and best practice."
Furthermore, if those "various bits of software" were ones that either 1) had no copyleft requirement or 2) copyrighted solely by you, they are non-examples.
Moreover, if doing a source dump with no changelog represents standard practice for the software in question, it likely does represent the "preferred form for modification". As I've said repeatedly, the "preferred form" is going to differ based on the software project at issue. C header and source files are an inappropriate form under GPL 3) for a work of software that is developed in Pascal or Java. When the copyright expires on old 8-bit ROMs such as those for the TRS-80 Model I or Apple I, the machine-language ROM dumps will be the preferred form for modification because the assembly sources have long been lost; no one will be in a position to develop from a more traditional form of source because it doesn't exist. (Beyond that, it wouldn't surprise me if Woz coded Integer BASIC with nothing but a hex keypunch in one sitting.)
I remind you once more that no one has claimed that "pushing a repository" is necessary for GPL compliance. You *keep* coming to this well. It's a distraction (but one I am happy to indulge solely for the purpose of pointing out how Debian does it for their Linux kernel package development).
"From a Debian perspective, my recollection is that people have argued that "source" as defined by the DFSG means "preferred form for modification" as defined by the GPL, in which case it's an issue for Debian regardless of whether the code's under the GPL or not - in fact, you seem to argue that point in http://lists.debian.org/debian-devel/2002/11/msg00662.html ."
Yes, I think the GPL's definition of source code is a damn good one generally. Red Hat is not bound by the high standards that the Debian Project sets for itself even with respect to non-GPLed software, however--they are bound by the definition of source code that the GPL specifies for GPLed works.
Like the Linux kernel.
Explain to me again how Debian's kernel packages are insufficient? 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.
Posted Mar 10, 2011 16:37 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (1 responses)
Posted Mar 10, 2011 23:34 UTC (Thu)
by branden (guest, #7029)
[Link]
Are you saying that the Linux kernel isn't upstream for Red Hat, but it is for Debian, or vice-versa? Or both?
Or neither?
Posted Mar 10, 2011 16:38 UTC (Thu)
by gregkh (subscriber, #8)
[Link] (5 responses)
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.
Posted Mar 10, 2011 23:39 UTC (Thu)
by branden (guest, #7029)
[Link] (1 responses)
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.
Posted Mar 13, 2011 2:06 UTC (Sun)
by vonbrand (guest, #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.
Posted Mar 11, 2011 9:25 UTC (Fri)
by PaXTeam (guest, #24616)
[Link] (2 responses)
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?
Posted Mar 11, 2011 16:45 UTC (Fri)
by gregkh (subscriber, #8)
[Link] (1 responses)
That work was hard based on the format that Red Hat is shipping their
>> Red Hat didn't make this very easy due to their "one giant patch"
Um, this makes no sense as that is not how upstream development works.
Posted Mar 11, 2011 22:43 UTC (Fri)
by PaXTeam (guest, #24616)
[Link]
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?
Posted Mar 9, 2011 20:31 UTC (Wed)
by sepreece (guest, #19270)
[Link] (4 responses)
Posted Mar 9, 2011 20:58 UTC (Wed)
by branden (guest, #7029)
[Link] (3 responses)
Needless to say, this pattern is often done in reverse, but I'm sure a lot of upstreams would like to see more instances of the above.
And that's exactly why Red Hat's move here has some kernel hackers (Greg K-H at least) wincing.
On the other hand, as long as there is no information loss either way in a two-way transformation, and the tools to convert from one form to the other are widely available, I don't think the spirit nor the letter of the GNU GPL is infringed.
That Red Hat's conversion from source+patches to monolithic when generating the SRPM is inescapably information-lossy is precisely the competitive advantage they are seeking from it.
Posted Mar 10, 2011 10:28 UTC (Thu)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
If I understand correctly, you want to cherry-pick patches from 2.6.32-el6 to 2.6.32-stable. So you're treating here "2.6.32-stable" as the downstream and "2.6.32-el6" as the upstream. Nobody disputes here that the monolithic kernel SRPM is making things harder. However, note that you are _not_ making modifications to RHEL kernel. You'd like the RHEL kernel to be distributed in your preferred form "for modification of something else", and that's not a right that the GPL grants you.
Posted Mar 10, 2011 23:46 UTC (Thu)
by branden (guest, #7029)
[Link] (1 responses)
Please be more precise. What is being made harder?
"You'd like the RHEL kernel to be distributed in your preferred form "for modification of something else", and that's not a right that the GPL grants you."
RHEL's kernel is not an independent work from the Linux kernel, be it the latest drop of the 2.6.32 kernel or some other variant. If it were, Red Hat Software, Inc. could just slap their copyright notice on the whole thing and tell everyone else to get lost.
Both of the things you are talking about are the Linux kernel, copyright 1991-2011 Linus Torvalds et al.
The Linux kernel is "the Work" under the terms of the GNU GPL.
The Linux kernel is not a "something else" when compared to the Linux kernel.
Posted Mar 11, 2011 8:32 UTC (Fri)
by pbonzini (subscriber, #60935)
[Link]
Identifying RHEL patches that are not in 2.6.32-stable and applying them to 2.6.32-stable. Red Hat engineers do try to Cc [email protected] on their patches, but it's possible that: a) they sometimes forget; b) they cherry-pick patches by authors who didn't Cc [email protected]. Attems is trying to get into stable those RHEL patches which "fell through the cracks", and the monolithic SRPM makes the job harder. But he's not trying to modify the RHEL kernel itself (read on).
> Both of the things you are talking about are the Linux kernel, copyright 1991-2011 Linus Torvalds et al.
The 2.6.32 kernel as released by Linus is a Work. The 2.6.32-stable kernel is another Work that is a derivative of the 2.6.32 kernel as released by Linus. So is the RHEL kernel. Each is distributed separately and modifications to each should be considered separately. Cross-pollination of the RHEL kernel into the Linux-stable tree is modification of _only one_ of these three works---and not the one that Red Hat distributes. In this sense you're modifying "something else".
The GPL does not force whoever distributes modifications to make backports of those modifications easy. For example, renaming variables is an example of a possibly-hostile action that is not prohibited by the GPL.
But we're wondering dangerously into IANAL area, so I'm unlikely to comment further on this topic.
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
> weakened, rather than strengthened, the argument he wanted to make
Red Hat and the GPL
Red Hat and the GPL
Ah. I must wistfully admit that I wish you'd had a phone conversation or brief email exchange with Mr. Corbet about this, then. It seemed to be an example that was eminent in his mind when he commented in the past week or so.
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
linux-source-2.6.32 - Linux kernel source for version 2.6.32 with Debian patches
[...]
NOTICE: 'linux-2.6' packaging is maintained in the 'Svn' version control system at:
svn://svn.debian.org/svn/kernel/dists/sid/linux-2.6/
[...]
$ cd linux-2.6-2.6.32/debian/patches
$ ls
bugfix debian features series
$ find -name "*.patch" | wc -l
1024
$ find -name "*.patch" | xargs du -ch | tail -n 1
37M total
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
>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.
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
patch from Red Hat to figure out what patches should be applied.
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.
>> format[...]
>
> now imagine if *everyone* else followed suit, where would that leave Linux
> development? is that the future you envision?
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
> kernel patch in these days, and the work should be thanked.
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
> distribution but work closely with your upstream, you might work "in" your
> Debian source or SRPM environment, but test for the existence of a
> user-reported bug in the upstream code first, and if it is present there, > patch it there before porting it back down to your own distro.
>
> Needless to say, this pattern is often done in reverse, but I'm sure a lot > of upstreams would like to see more instances of the above.
>
> And that's exactly why Red Hat's move here has some kernel hackers (Greg
> K-H at least) wincing.
Red Hat and the GPL
Red Hat and the GPL
>
> Please be more precise. What is being made harder?
>
> The Linux kernel is "the Work" under the terms of the GNU GPL.
>
> The Linux kernel is not a "something else" when compared to the Linux kernel.