User: Password:
|
|
Subscribe / Log in / New account

Red Hat and the GPL

Red Hat and the GPL

Posted Mar 10, 2011 16:34 UTC (Thu) by branden (guest, #7029)
In reply to: Red Hat and the GPL by mjg59
Parent article: Red Hat and the GPL

"The kernel's the higest profile example."

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
linux-source-2.6.32 - Linux kernel source for version 2.6.32 with Debian patches

Have a look sometime.

Here's a terminal transcript, edited for space and clarity:

$ apt-get source linux-patch-debian-2.6.32
[...]
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

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.


(Log in to post comments)

Red Hat and the GPL

Posted Mar 10, 2011 16:37 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

"Upstream projects".

Red Hat and the GPL

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

Gonna have to be less terse.

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?

Red Hat and the GPL

Posted Mar 10, 2011 16:38 UTC (Thu) by gregkh (subscriber, #8) [Link]

>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.

Red Hat and the GPL

Posted Mar 10, 2011 23:39 UTC (Thu) by branden (guest, #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 (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.

Red Hat and the GPL

Posted Mar 11, 2011 9:25 UTC (Fri) by PaXTeam (guest, #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 (guest, #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?


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds