User: Password:
Subscribe / Log in / New account

Red Hat and the GPL

Red Hat and the GPL

Posted Mar 9, 2011 21:46 UTC (Wed) by branden (guest, #7029)
In reply to: Red Hat and the GPL by mjg59
Parent article: Red Hat and the GPL

And how was this in *any* way responsive to paulj's questions?

(Log in to post comments)

Red Hat and the GPL

Posted Mar 9, 2011 23:21 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

I don't think historical precedent shows that the preferred form for modifying GPLed works is the full set of data contained within a revision control system - during the bitkeeper era you were unable to obtain most of the kernel metadata without agreeing to onerous license conditions, but nobody at the time seemed to argue that this was a GPL violation and I note that Debian didn't stop distributing the kernel during that period. Is there an argument to be made that the preferred form for modification includes individual patches if that's the way the maintainers work? I honestly don't know. Have we held anyone to that standard in the past? Absolutely not, and so I don't think it's terribly useful to start talking about "evading the GPL" when the result is equivalent to things that we've accepted as GPL-compliant in the past.

Red Hat and the GPL

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

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.

Red Hat and the GPL

Posted Mar 10, 2011 10:38 UTC (Thu) by pbonzini (subscriber, #60935) [Link]

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

Of course some of them are, apparently enough to be willing to leak internal (and occasionally false) information about the change. Others are not, others consider it a sad but justified move. You'll find the whole panorama, as expected in a relatively large population.

Red Hat and the GPL

Posted Mar 10, 2011 10:00 UTC (Thu) by paulj (subscriber, #341) [Link]

First off, you're not exactly comparing like with like. You're trying to create an equivalence between kernel development processes and vendor kernel package maintenance processes. It's pretty clear these two processes are not entirely the same, because they've been significantly different in the past at RedHat and - despite any move to git at RedHat - they likely still are not the same. The preferences of developers in one mode may differ from those working in the other. The GPL does not specify exactly what "preferred form" is, no doubt quite deliberately, as it may vary from situation to situation.

The developers of one project can quite legitimately prefer to work on tarballs without history, while those of another may prefer to have the history. The *same* developers may follow two different processes, even working on nominally the same codebase, according to whether they're developing features for upstream or whether they're working on maintaining their employers supported package. That's certainly been my experience at another vendor, and you may have had the same experience too at your employer.

To be clear, there is a difference between "the sources for the Linux kernel" and "the sources for a vendor kernel package". It's an undeniable fact that, say, a RedHat kernel RPM was built using files that are not and (almost certainly) never will have equivalents in the stock Linux sources.

Further, I'm not sure there is much direct historical precedent. In the past, distributors built their packages from pristine+packages because SCMs weren't good enough. So, for package sources, for want of an SCM that could keep changes distinguished, the preferred form became pristine sources + patches. That this way of collating sources for packages became established at multiple distributors - including non-Linux ones - strongly suggests it was industry wide best-practice. I'd be amazed at anyone who tried to argue that wasn't the case. For me, such wide practise is somewhat equivalent to a preference, though you'd presumably disagree. However, in recent times SCMs have become much better. Git and mercurial (git especially) have changed how we can work and made it viable to move information that was previously kept in explicitly separate files in the sources of the package off into the history data of the SCM.

I have a lot of sympathy for RedHat. They've done and continue to do great things for free software. I do think it's legitimate to ask though, when a vendor deliberately tries to withhold information that was previously part of the sources they released for a package, at what point they cross a line. Maybe RedHat have not, but the discussion is still worthwhile.

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