| |||||||||||||
Red Hat and the GPLRed Hat and the GPLPosted Mar 9, 2011 14:16 UTC (Wed) by ewan (subscriber, #5533)In reply to: Red Hat and the GPL by Los__D Parent article: Red Hat and the GPL completely irrelevant, just like common patterns for modifying RPMs We're talking about the source code for a binary RPM. The preferred form of the source for the RPM is all that matters. Again, the preferred form for making modifications is the raw source That's a non-sequitur. Clearly what is required is 'the source'. The entire intent of the 'preferred form for modification' wording is to address the question of what counts as 'the source'. I think everyone agrees that a tarball of machine generated pre-processor output is not 'the source', even though it can be compiled to a binary. If you have a build system that starts with a single tarball and works from there then that single tarball may indeed be 'the source'. If you have a build system that starts from a pristine upstream tarball and a pile of patches, then it's reasonable to say that the pristine upstream tarball and the pile of patches together form 'the source'. It appears Red Hat's build process does still involve a pristine upstream and a pile of patches since they're making the patches available to customers. If that's the case, then the collapsed single tarball is just as much a machine-generated intermediate stage as pre-processor output would be.
(Log in to post comments)
Red Hat and the GPL Posted Mar 9, 2011 14:50 UTC (Wed) by Los__D (guest, #15263) [Link]
The engineers checks out the source, makes modifications (!!!!) to the checked out source, and checks in their changes.
How they store their changes it does not matter.
This seems to be another case of "I don't like, I better try to twist reality to my preferences".
Red Hat and the GPL Posted Mar 9, 2011 15:18 UTC (Wed) by ewan (subscriber, #5533) [Link] The engineers checks out the source, makes modifications (!!!!) to the checked out source, and checks in their changes.Apparently not in the case of the RHEL kernel they don't. If what you're suggesting was actually true there would be no list of separate patches to supply to customers. And there is.
Red Hat and the GPL Posted Mar 9, 2011 15:52 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
No, it's a git tree. There's infrastructure to generate SRPMs by turning each code-changing commit into a separate patch, but the canonical source that we develop against is git and not the SRPM.
Red Hat and the GPL Posted Mar 9, 2011 16:00 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Incidentally, you can check this by grabbing the beta RPM from ftp://ftp.redhat.com/redhat/rhel/beta/6/source/SRPMS/kern... - the presence of patches like "redhat-tagging-2-6-31-50-el6.patch" that have
diff --git a/redhat/Makefile.common b/redhat/Makefile.common
as their sole contents should be a give away that the patch generation is automated!
Red Hat and the GPL Posted Mar 9, 2011 22:56 UTC (Wed) by jone (guest, #62596) [Link]
great! .. where's the git tree location that we can checkout?
Red Hat and the GPL Posted Mar 9, 2011 16:12 UTC (Wed) by avik (guest, #704) [Link]
We do not in fact develop against canonical source.
Red Hat and the GPL Posted Mar 9, 2011 17:09 UTC (Wed) by ewan (subscriber, #5533) [Link]
OK, now that's interesting. When paulj says <i>"RedHat maintainers literally did check in *patches* to CVS, as the source of their kernel src.rpm"</i>, is that something that used to be the case, but isn't any more, or has it never been the case?
<p> Fundamentally it seems to me that the purpose of the 'preferred form' language is to stop distributors of GPLed code from distributing in a form designed to make life harder than it need be for downstream consumers. In this specific instance people from Red Hat management have been making statements that this change was specifically intended to do just that, as a means of competing with Oracle, Novell etc. <p> If the reason for the change is that the canonical source used to be a pristine Linus kernel and a bunch of patches, and now it isn't because you've moved to git, then there wouldn't be any GPL concerns. But if that's all that's happened then it might have helped if someone had just said so, rather than bringing competition into it.
Red Hat and the GPL Posted Mar 9, 2011 17:11 UTC (Wed) by ewan (subscriber, #5533) [Link]
Oops. Formatting fail - sorry.
Red Hat and the GPL Posted Mar 9, 2011 17:20 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
The majority of packages in RHEL are managed in CVS (like Fedora until very recently), but the kernel is developed against git now. Patches are sent to mailing lists and applied to the git tree, and the SRPM is then generated from that. In the process of generating that SRPM it's possible to turn each git commit into a separate patch (as was done in the beta release, and as is done in 5) but the development base is the git tree and not the SRPM.
Red Hat and the GPL Posted Mar 9, 2011 17:26 UTC (Wed) by ewan (subscriber, #5533) [Link]
OK, so to be absolutely clear, is it fair to say that the change is a technical result of the move to git, which meant that the 'split out patches' version no longer happened 'naturally' (as it were), and is not a management inspired artificial change intended to make things more difficult for competitors like Oracle?
Red Hat and the GPL Posted Mar 10, 2011 10:31 UTC (Thu) by pbonzini (subscriber, #60935) [Link]
The combined reading of the parent comment, and the CTO's press release, will give you the answer.
Red Hat and the GPL Posted Mar 9, 2011 17:30 UTC (Wed) by paulj (subscriber, #341) [Link]
So, previously the source of the kernel RPMs was a src.rpm of pristine+patches. Now the source is a git tree, with an intermediate step of a src.rpm with a collapsed history.
So then we're back to dmw2's point, at what point does a change in the build processes that happens to result in the released sources throwing away a lot of useful information go from being benign to one that is deliberately trying to obfuscate the source input to that build process so as to evade the GPL? Particularly when the system apparently still has the capability to generate the uncollapsed src.rpm, but it's not done with the express purpose to frustrate rebuilders?
Red Hat and the GPL Posted Mar 9, 2011 17:34 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Back when people sent patches directly to Linus and he just released tarballs, was he violating the GPL?
Red Hat and the GPL Posted Mar 9, 2011 17:44 UTC (Wed) by paulj (subscriber, #341) [Link]
See my reply to vonbrand about engineers' often incorrect tendency to reason about legalities in purely technical terms. In your case, I'd say "no" for a number of reasons (intent, that being the normal and preferred practice, implied consent of the patch submitter, etc). But IANAL...
Red Hat and the GPL Posted Mar 9, 2011 21:14 UTC (Wed) by branden (subscriber, #7029) [Link]
As the (predominant) copyright holder in the Linux kernel, no.
You cannot violate the copyright license in your own work.
Red Hat and the GPL Posted Mar 9, 2011 22:47 UTC (Wed) by Los__D (guest, #15263) [Link]
Errrrr, he incorporated other peoples work. That his own part of the combined work was larger is not really relevant.
Red Hat and the GPL Posted Mar 9, 2011 21:46 UTC (Wed) by branden (subscriber, #7029) [Link]
And how was this in *any* way responsive to paulj's questions?
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 (subscriber, #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.
Red Hat and the GPL Posted Mar 10, 2011 11:24 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] "Back when people sent patches directly to Linus and he just released tarballs, was he violating the GPL?"It's important to remember that there is a clear distinction between upstream, and a modified version or fork. Tarballs are a perfectly sane way for upstream releases to happen. But I think that every competent open source developer, when they're not trying to twist things to make a point, will agree: When releasing a modified code base which is based on some upstream project, it is definitely preferable to release that in the form of original + patches, rather than as a monolithic tarball of the whole damn mess.
Red Hat and the GPL Posted Mar 10, 2011 12:47 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
It's also preferable for an upstream maintainer to provide new releases in a manner that allows people to bisect patch history. I don't understand the distinction you're drawing.
Red Hat and the GPL Posted Mar 10, 2011 14:43 UTC (Thu) by paulj (subscriber, #341) [Link]
The distinction he was drawing is pretty widely understood really, embodied fairly concretely as it is by the difference between the sources distributed by Linus for the Linux kernel (upstream) and those distributed by RedHat as the sources for the kernel RPM previously (to choose one example amongst many). It's not hard to grasp really. ;)
Red Hat and the GPL Posted Mar 10, 2011 18:48 UTC (Thu) by martinfick (subscriber, #4455) [Link]
To make this argument you'd have to be able to define upstream, which I suspect that you cannot actually do in a satisfactory way. Red Hat in many ways is acting as an upstream for their long term kernels.
Red Hat and the GPL Posted Mar 9, 2011 23:03 UTC (Wed) by rahvin (subscriber, #16953) [Link]
One of the most dishonest parts of this entire debate is to ignore the history of the GPL and why that clause exists and then turn around and redefine it using whatever method you prefer. This is no different than people in the US redefining what the US constitution means with Today's usage while completely ignoring the debate and use when the measures were enacted.
This clause exists in the GPL to prevent some company from sending you a printed book of source code. I find it extremely dishonest to start arguing about an individual persons interpretation of this clause without consideration of that history or the reason it exists. You simply can't be willy nilly redefining intent however you like and examining this in a vacuum.
Any court of law that finds the GPL language ambiguous is going to go back and read the history of the clause and what it was intended to mean. That simple review can be conducted with a Google search that points out RMS defined this clause as trying to prevent the paper copy exploit. Any other description of this clause is disingenuous at best and this debate should have never made it past that cursory review.
Red Hat and the GPL Posted Mar 10, 2011 1:23 UTC (Thu) by branden (subscriber, #7029) [Link]
Originalism is bad exegetics in constitutional law, and it's bad exegetics here.
Red Hat and the GPL Posted Mar 10, 2011 3:03 UTC (Thu) by ewan (subscriber, #5533) [Link] This clause exists in the GPL to prevent some company from sending you a printed book of source code.No, it doesn't. The GPL deals with that using the "on a medium customarily used for software interchange" language. The specification that the source be the 'preferred form for modification" is a separate requirement, and is about what does and does not count as 'source', not about the media via which it is delivered.
Red Hat and the GPL Posted Mar 18, 2011 18:48 UTC (Fri) by mishad (guest, #69757) [Link]
Agreed.
To know for sure we'd have to ask the GPL's original authors, but my reading of it was that the term was added to ensure that the right to produce modified works could be meaningfully exercised. In particular, it was to preclude distribution of "source" that was obfuscated (e.g. variable names changed, no whitespace, no comments, replace control structures with equivalent gotos) or which was already compiled (e.g. as "binary blobs" which form part of the resulting program/work).
I don't think anyone was thinking about VCSen back then.
Red Hat and the GPL Posted Mar 9, 2011 16:04 UTC (Wed) by Los__D (guest, #15263) [Link]
That's funny, I can export a whole list of patches to the program I'm working on, even though I have never used patches to create and modify that program; I made the changes required directly to the source, and committed those changes as they were done.
And again, it doesn't really matter how Red Hat package those changes. The modifications originally (in all probability) was done to the checked out source.
- In simple cases, someone might have opted to do the change directly to an existing patch, but that is hardly the norm.
|
|||||||||||||