Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
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.
Red Hat and the GPL
Posted Mar 9, 2011 23:11 UTC (Wed) by mjg59 (subscriber, #23239)
Posted Mar 10, 2011 0:54 UTC (Thu) by branden (subscriber, #7029)
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)
Posted Mar 10, 2011 1:53 UTC (Thu) by branden (subscriber, #7029)
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)
Posted Mar 10, 2011 3:05 UTC (Thu) by branden (subscriber, #7029)
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)
Posted Mar 10, 2011 16:34 UTC (Thu) by branden (subscriber, #7029)
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:
$ cd linux-2.6-2.6.32/debian/patches
bugfix debian features series
$ find -name "*.patch" | wc -l
$ find -name "*.patch" | xargs du -ch | tail -n 1
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)
Posted Mar 10, 2011 23:34 UTC (Thu) by branden (subscriber, #7029)
Are you saying that the Linux kernel isn't upstream for Red Hat, but it is for Debian, or vice-versa? Or both?
Posted Mar 10, 2011 16:38 UTC (Thu) by gregkh (subscriber, #8)
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 (subscriber, #7029)
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 (subscriber, #4458)
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 (subscriber, #24616)
then why did you see the need to explicitly call them out in the 126.96.36.199 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)
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"
> 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.
Posted Mar 11, 2011 22:43 UTC (Fri) by PaXTeam (subscriber, #24616)
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 © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds