Red Hat and the GPL

Even though I'm unhappy with Mr. Edge's article for several reasons, I am glad LWN published squarely on this subject, because I am learning something important: Red Hat kernel engineers are not as upset about this development as I had assumed based on second-hand reports in previous LWN discussions. I appreciate having my misconceptions punctured.

At any rate, you are baffled because you are arguing against a straw man.

"The full set of data contained within a revision control system" is not what is being asked for.

What is being asked for is the delta between the upstream source code as Red Hat retrieved it, and each patch made to it at the level of atomicity the engineers working with it find most appropriate.

Because that was Red Hat's standard operating procedure in the kernel SRPMS domain for, literally, years.

(I'd say that a one-liner description of each patch would be de rigueur as well, but I get the impression that most kernel hackers would be content with one of git's inscrutable hexadecimal identifiers. If that really is good enough for the community, then it's good enough for me.)

To tie this in to the other discussion we're having (and for the edification of those eating popcorn while we argue), the .spec approach of specifying a base tarball (possibly more than one, it's been a while since I've built an RPM) and an arbitrary number of patches was one of the RPM package format's few advantages over DEB (particularly in the domain of source management).

Debian developers recognized that as a deficiency many years ago, and took steps to ameliorate. Doogie's Build System (dbs) was one such effort, such that the .diff.gz didn't really patch any of the original directories anymore, but just created a debian/ directory as it always does, and then included a debian/patches directory which contained the itemized patches which had to be applied to the source as part of the package build process.

There were other initiatives along these lines. Ultimately, the problem was solved at the right level, by extending the Debian source package format to allow for multiple .diff.gz files. These may still be kept few in number, but as long as the engineering equivalent of a debian/patches directory exists (many source packages use quilt) identifying the discrete patches applied, Debian packages are meeting the same standard as the Red Hat Linux kernel SRPMS of the recent past.

Sadly, my knowledge of the history of innovations in Debian source package management trails off at about five years ago. I'd much appreciate an active member of the project chiming in to bring the discussion up to date and correct any misstatements I've made.

The fact that our knowledge of developer-friendly ways to package and distribute source code has increased, and those improvements have spread and become common practice, tells you something important: our community evolves. Our expectations evolve. We learn how to do things better. The GNU GPL is vague on this for precisely the right reason: preferences among developers change with time. What was the preferred form for modification 20 years ago might not be good enough today.

When a major figure in the FLOSS community like Red Hat Software takes a deliberate step backward in engineering quality like this, and thumbs its nose at its fellows (even if they only "mean" to inconvenience less sympathetic firms), people notice, and recognize it for what it is--a conscious refusal to abide by current best practices for delivering source code in the preferred form for modification.

That Red Hat Software played a significant role in advancing those very best practices to the high level they are today makes it poignantly sad and ironic that they are betraying their legacy.