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