Weekly Edition
Return to the Front page
| |||||||||||||
Red Hat and the GPLThe changes that Red Hat has made in the way it releases kernel source for RHEL 6 have stirred up some controversy. There is a certain tension between the needs of an enterprise distribution and the interests of the free software projects on which it is based. While the changes that Red Hat has made do not seem very popular, there has also been a fair amount of speculation that the move somehow violates the GPL, which is a rather serious charge. But there is good reason to believe that Red Hat is not crossing into GPL-violation territory, though it may well be sitting close to that line. First, the obvious: Red Hat has a top-notch legal team, with a lot of GPL experience, so it's a little hard to believe that those lawyers, at least, haven't examined Red Hat's position and believe it is defensible in the unlikely event of a lawsuit. While Red Hat has a legal team, LWN seems to be lacking in the legal budget department, so nothing in this article should be considered legal advice of any sort (I am not a lawyer, nor do I play one anywhere). The arguments being made about GPL compliance seem to fall into two categories. The first is that distributing what is effectively a tarball of the kernel source does not qualify as the "preferred form of the work for making modifications to it" (as is specified in the GPL). While the second is that making the individual patches to the kernel source available to customers, but not allowing those customers to redistribute the patches to others, puts a "further restriction" on GPL-covered code (which the patches clearly are). While neither complaint is completely without merit, both would seem to fall short of GPL violations. Preferred formWhile there can certainly be arguments about what "preferred form" means for source code distributions, Red Hat's actions here don't seem very close to the line. The basic idea is that the code be released in digital form, along with any build scripts, so that downstream developers can reproduce the GPL-covered binary that is being shipped. It is partly meant to prevent recalcitrant vendors from releasing the source on paper—or stamped into clay tablets in cuneiform. One could argue that those methods do provide the source code, but it certainly isn't in a form preferred by anyone—nor does it adhere to the "medium customarily used for software interchange" requirement. Obfuscated source code, where all the variables and function names get turned into unintelligible gibberish, or the source is deliberately split up in ways that are harder to work with, are a bit more of a gray area—but not much. Those kinds of actions should be seen as clear attempts to circumvent the GPL requirements. But that's not at all what Red Hat is doing. The tarball that Red Hat is releasing may not be the preferred form for the Red Hat kernel developers to use, but that is not part of the requirement. Tarball releases of GPL code are a longstanding tradition in the free software world. Many projects still do it that way and the FSF itself has made releases that way in the past. While it is nice to get some visibility into the version control system of a project, it certainly isn't required for GPL compliance. No one complained that Red Hat didn't provide access to its Git repositories back when it was still providing the broken-out patches, for example. A Git repository is definitely the preferred form for Red Hat developers to use, but there are lots of reasons that the company might want to keep its repositories to itself—something that is obviously within its rights. There is an oft-ignored GPL clause about modifications to consider here as well: "You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change." Red Hat may well be technically violating that clause, but it is hardly alone in that as it is pretty much completely ignored by everyone, without any real consequences. But this GPL requirement is of little interest to most. What everyone really wants is the reason that the change was made (along with which changes to other files go along with it), and the GPL is silent on any requirement to provide that level of detail. For the RHEL kernel source, what Red Hat is providing is well within the GPL boundaries. It is also well within community norms. The community gets kernel tarballs from lots of companies (often those in the embedded Linux world), sometimes after a bit of a struggle, and is happy to get them. Red Hat shouldn't be treated any differently than those companies are with respect to the distribution of source code. Tarballs may be something of a barrier to easier collaboration, debugging, and so on, but distributing them doesn't rise to anything near a GPL violation. The other major complaint, on the other hand, is a bit less clear cut. Trading GPL rights for supportWhile it isn't anything particularly new, some aspects of the RHEL support model are raising eyebrows in light of the changes to the kernel source distribution. In particular, the broken-out patches that used to come with the kernel source RPMs are evidently being made available to Red Hat customers, but only if they don't distribute them further on pain of losing support going forward. This sounds like a restriction on the GPL rights of the recipients of the patches—and it is—but that restriction is enforced via an agreement between Red Hat and its customers. This is part of Red Hat's business model that Bradley Kuhn calls the "'if you like copyleft, your money is no good here' business model" (scroll down a ways to get to that part of his post). It is, he says, GPL-compliant "merely because the GPL is silent on whether or not you must keep someone as your customer". He also says that Red Hat was the first to make use of that particular business model, but he may be forgetting about Sveasoft. The history is fading into link rot a bit at this point, so it is possible that Red Hat was the first to get there. But Sveasoft's subscription model, which essentially required subscribers to give up their distribution right on GPL-covered code provided by Sveasoft, was roundly criticized in the early 2000s. In 2004, though, Sveasoft announced that the FSF had reviewed and, somewhat surprisingly, at least at the time, approved that arrangement. Essentially, the support (or subscription) agreement is a contract between two entities and those parties can agree to pretty much anything they want. The GPL cannot protect one from agreeing to refrain from certain behavior. In the distant past, there were also complaints that Red Hat will terminate its support contract for users that run their own kernel, rather than what is supplied with RHEL. While that is another restriction on exercising GPL rights, it is one that is rather easier to understand. Trying to support any random kernel that a customer wants to run is likely to be a quick way to drive Red Hat's kernel engineers mad. Complete termination of support may be an excessive reaction—and is probably rarely if ever used—but certainly not supporting those systems running other kernels is not an unreasonable position. The inability to redistribute the kernel patches is clearly seen by some as the most egregious "violation" of the GPL rights of its customers. In some, possibly many, cases those patches are not even owned by Red Hat, but were instead submitted by others to the upstream kernel and then integrated or backported into the RHEL 6 kernel. But the results of that effort are being distributed in source form. If Red Hat's customers are willing to trade their GPL rights for support, there is little anyone else can do but complain. On the other hand, a sufficiently motivated group could probably reverse-engineer the patches from the RHEL 6 kernel source. It would be a tedious and error-prone process, but Red Hat has said that all of the RHEL 6 features have been submitted upstream, so it should be doable. Anyone with a RHEL support contract would want to think long and hard before participating in such a project, however. Whether there is sufficient value in doing so remains to be seen. (Log in to post comments)
Red Hat and the GPL Posted Mar 9, 2011 0:33 UTC (Wed) by pranith (subscriber, #53092) [Link]
Ok, I am a bit confused here. What happens in the following case:
I buy a redhat subscription which implictly means that I agree to their service terms not to distribute the patches.
Now if I violate that service agreement by distributing the patches, all redhat can do is stop my service
What if I buy a new subscription? Will I get the new patches?
I can't see how they can keep a determined competitor from getting what they want.
Red Hat and the GPL Posted Mar 9, 2011 0:49 UTC (Wed) by mbanck (subscriber, #9035) [Link]
Assuming that Red Hat would not want you to sign up again after your violation of their service terms, you'd have to fake your identity. While this is probably not a big deal for individuals, it might be practically impossible for companies, at least those sorts of companies which do not get re-founded under a different name every couple of weeks.
If a competitor does this, they might even consider suing for trade secret espionage, cf. Oracle vs. SAP for something apparently slightly similar.
Red Hat and the GPL Posted Mar 9, 2011 14:26 UTC (Wed) by vonbrand (subscriber, #4458) [Link] OK, let's take a look at this whole mess from the "intent of GPL" angle (I'm no lawyer, and won't play one here either). Directly from the free software definition by the FSF, which presumably is authoritative on what GPL means:
What Red Hat is doing is giving you those four freedoms with respect to the kernel they ship, and then some. The whole flamefest is around if freedom 1 includes the right to be told why some part of the program is written (or was modified) the way it is. But the four freedoms are completely silent about this matter, the "learning" part is a job of whoever gets the program. Note that the "availability of source code" is considered a precondition for being able to study and modify the current version, nothing else.
Red Hat and the GPL Posted Mar 9, 2011 22:13 UTC (Wed) by jrn (subscriber, #64214) [Link]
That's true. I have never heard of anyone claiming that providing a proprietary manual along with code licensed under the GPL violated the GPL. So what you say makes sense.
On the other hand, I have heard people claim that distributing (modified) code licensed under the GPL with comments stripped out is a violation. So we are in murky waters.
Red Hat and the GPL Posted Mar 9, 2011 4:17 UTC (Wed) by gmaxwell (subscriber, #30048) [Link]
Not to put too sharp a point on it, but
As the whole the kernel developers don't seem to care to enforce the license in the case of fairly overt violations, like extensions to the kernel with proprietary binary blobs, or weaselly cryptographic signing that makes the ability to modify the code mostly moot.
Even if Red Hat's actions were technically a (fringe-)violation it would be pretty outrageous for aggressive kernel license enforcement to begin there.
I think that it's unfortunate that so much energy is being spent nitpicking Redhat's activity when more harmful (and in many cases, far more clear cut) violations are occurring continually.
Red Hat and the GPL Posted Mar 9, 2011 5:13 UTC (Wed) by butlerm (subscriber, #13312) [Link] like extensions to the kernel with proprietary binary blobsUnless the distributors of said binary blobs are jointly distributing them with the kernel itself, the chances of enforcement on the grounds of creating a derived work are slim to none. The idea that most such modules are derived works is wishful thinking. I keep waiting to hear a theory that would pass muster under US copyright law. All the ones I know of have strong precedents against them, in addition to being about the most counterproductive public policy imaginable.
Red Hat and the GPL Posted Mar 9, 2011 5:27 UTC (Wed) by gmaxwell (subscriber, #30048) [Link]
I keep waiting to see you point out where I claimed desktop vendor shipped proprietary video drivers distributed by video card manufacturers were the only or the most interesting issue. :) You can have you strawman back, I've got plenty of my own, thanks.
Red Hat and the GPL Posted Mar 9, 2011 6:36 UTC (Wed) by butlerm (subscriber, #13312) [Link] As the whole the kernel developers don't seem to care to enforce the license in the case of fairly overt violations, like extensions to the kernel with proprietary binary blobsI am afraid I don't understand why pointing out that GPL-style licenses are generally unenforceable (i.e. gratuitous) in this regard is a strawman. Suppose a vendor took things one step further and distributed a device with dynamically loaded proprietary drivers. GPLv2 and GPLv3 are both vague enough that a legal action against that would probably fail as well, and there doesn't appear to be anything that could be done to fix the problem without destroying the utility of the license in the first place. If, for example, the FSF really wanted to fix the problem in GPLv4, they could add language like: "conveyance of this code on the same media or on the same physical device with code licensed under any license incompatible with this one is not allowed under the terms of this license". The needle the the FSF is trying to thread with both licenses involves much too general (and thus easily circumvented) descriptions of what they are trying to prohibit. "Intent" is not a stable property of a piece of software. Nor is "purpose", nor "extension". "Compatible" might be, but then the license starts to look useless again.
You mean routers? Posted Mar 9, 2011 9:00 UTC (Wed) by khim (subscriber, #9252) [Link] Suppose a vendor took things one step further and distributed a device with dynamically loaded proprietary drivers. You mean routers? Yes, they are distributed in such form. And most (if not all) are pushing limits if not outright violationg GPL. GPLv2 and GPLv3 are both vague enough that a legal action against that would probably fail as well, and there doesn't appear to be anything that could be done to fix the problem without destroying the utility of the license in the first place. Where are exactly they are "vague enough"? GPLv2, in particular, quite explicitly claims that you can only distribute non-GPLed programs on the same medium if it's "mere aggregation". Router has three parts: GPLed kernel, binary blob of a WiFi driver and the rest. Remove any single one - and you don't have a router anymore, you have a brick (or semi-brick if wired Ethernet is handled by open-source driver). To claim that WiFi driver and GPLed kernel are "mere aggregation" in this case you must do a lot of squinting.
You mean routers? Posted Mar 9, 2011 20:22 UTC (Wed) by sepreece (subscriber, #19270) [Link]
"Mere aggregation" isn't about whether the separate pieces are all needed to make the product work, it's about whether the pieces are all piece of one program. At least in some situations there's an argument that the binary blob is not part of the program, it's just a piece of data that the program installs in another device. [IANAL and I haven't read any cases that get close to this question.]
You mean routers? Posted Mar 10, 2011 1:14 UTC (Thu) by butlerm (subscriber, #13312) [Link] To claim that WiFi driver and GPLed kernel are "mere aggregation" in this case you must do a lot of squinting.The problem is that the "one program" here isn't actually constructed (at best) until the router boots up, and then only in ram. So you have a proprietary driver that implements some sort of API - it doesn't even have to be the Linux API, but even if it was there is nothing stopping someone else from implementing a compatible API support. So you look at this driver, on the same flash filesystem or whatever, and there is no reliable way to determine whether it is part of a "mere aggregation" or not, because there is no reliable definition of "mere aggregation" that includes other proprietary software in the device while excluding something that just happens to implement a compatible API. That means, as I said, that the only reliable way to do this is to make the license prohibit all joint distribution of GPL and proprietary software on the same media or on the same device, period. If the FSF is not willing to be so purist as that, it is hard to see how they are going to be successful grasping at metaphysical straws trying to decide what proprietary software can be included in a device and what can't.
Red Hat and the GPL Posted Mar 9, 2011 5:20 UTC (Wed) by branden (subscriber, #7029) [Link]
I agree with your first three paragraphs. (Well, except for the term "outrageous".)
I differ with you regarding triage, however. GNU GPL infringement is rampant; ask the FSF's compliance officer, or the SFLC, sometime.
Red Hat Software, Inc., has indeed been, on balance, a laudable participant in the community.
However, there are virtues in keeping honest people honest, and not confining ones attention to wreaking revenge on the dishonest.
I'd like to see Red Hat remain the good example that they have been. Sadly, there are few levers available to influence corporations, particularly publicly-traded ones, to remain on their best behavior.
Finally, I think you are forgetting that, by all accounts (those we've seen in comments here on LWN), Red Hat's own kernel engineers are unhappy with this decision. Their views, as capable hackers who willingly develop GPLed software, are deserving of consideration. While not dispositive, I'm inclined to pay them much more heed than those of a marketing manager.
"It is difficult to get a man to understand something when his job depends on not understanding it." -- Upton Sinclair
Red Hat and the GPL Posted Mar 9, 2011 5:05 UTC (Wed) by branden (subscriber, #7029) [Link]
Pretty unimpressive analysis; almost but not quite "completely without merit", as the author might put it.
Mr. Edge omits the case of preprocessed source as a "preferred form for modification", a case Mr. Corbet is well-aware of (having cited it himself), and of which the senior editor should have made him aware when assigning this story.
In the post-preprocessed source scenario, the source is all there. No variable names are obfuscated or rendered into gibberish (macros and preprocessor symbols aren't variables or function names). Nothing is split up in a difficult way; in fact, you tend to get more code at once for a more holistic source code experience.
It's surely far superior to a cuneiform tablet.
Similarly, we can view Red Hat's monolithic kernel source RPMs as an *improvement* over that unwieldy, tedious, split-up pile of rubble called patches to the upstream source.
Ergo, shipping post-preprocessed source as a means of complying with section 3 of the GNU GPL (version 2) is fine and dandy.
Moreover, the fact that the entire community (including those trivial portions not in the employ of Red Hat Software, Inc.) generally hand-waves away strict enforcement of section 2a, usually in favor of exterior changelogs, as acknowledged by GNU GPL version 3, is entirely beside the point. It is within copyright holders' prerogatives to overlook certain strict infringements, either because they were ill-considered in the first place, as I submit is the case with section 2a, or for any other reason.
If the widespread non-enforcement of 2a has any weight at all, then it applies just as well against *all* of the provisions of the GPL, including those contravened in situations Mr. Edge *does* recognize as infringement.
Another point: the facile notion that because "Red Hat has a top-notch legal team with a lot of GPL experience", they are unlikely to "believe it is [in]defensible in the unlikely event of a lawsuit" exposes its own flaw upon close reading.
Companies can and do infringe copyright knowingly and willfully. Why? Because they perform risk and cost-benefit analyses and decide that the business is best served by doing so; the multiplicative product of the likelihood of being challenged with the expected impact on the business if they are falls below a certain threshold of discomfort.
Red Hat's legal team can believe their actions with the kernel SRPM to be a GPL violation and proceed to do it anyway. If they do, no doubt they share Mr. Edge's assessment that facing a lawsuit from any copyright holder in the kernel is "unlikely".
This is particularly true if Red Hat can convince those copyright holders that those whom they are inconveniencing with this move are unsavory and unsympathetic. Hence the emphasis on free-riders, rather than on independent distributors of the Linux kernel who undertake their own development efforts and contributions. Thus, not only does ignoring the Debian Project's efforts fit Red Hat like a comfortable old shoe for distribution and packaging format rivalry reasons, it's tactically important. Red Hat needs to keep the eyes of the community on "parasites", not legitimate Linux distributions (however benighted they may be for not joining the Red Hat monoculture).
That is only one tool in Red Hat's box. If a copyright holder in the Linux kernel does squawk, they can 1) ignore the complaint; 2) settle for cash; or 3) break out patches touching the files in which that person (or other legal entity) has rights in future releases as a means of compliance. The last option does have the consequence of throwing a bone or two to the supposed free-riders, but it has to beat reverting this decision entirely.
In short, it simply does not follow at all that Red Hat has a bunch of smart lawyers who don't feel confident they would prevail in litigation. Perhaps they do; but the proper means for a journalist to determine that is through an interview with a person privy to their deliberations, not conjecture.
Congratulations, Mr. Edge, your analytical acumen has me considering canceling my subscription to LWN for the first time ever. (As it happens, though, there's no interface for doing that...)
Red Hat and the GPL Posted Mar 9, 2011 5:37 UTC (Wed) by frnknstn (subscriber, #68647) [Link]
I may be wrong here, but isn't the C preprocessor part of the C standard? And isn't preprocessing the first step of compilation?
If that is true, then supplying preprocessed source code is supplying partially compiled source code, and thus insufficient for GPL compliance.
Red Hat and the GPL Posted Mar 9, 2011 5:48 UTC (Wed) by branden (subscriber, #7029) [Link]
Yes, the C preprocessor is standardized.
The second question is arguable. Preprocessing certainly is not compilation in the classical computer-science sense.
The output of a macro assembler after it has expanded macros is no more object code ready for execution by the host CPU than the output of the C preprocessor is.
To extend your reasoning, enumerate the other "steps of compilation". Assembly is also compilation. So is optimization. So is linking.
What does that leave?
Well, uh, "compilation".
As is often the case, terms have contextual definitions. In some contexts, everything that happens after you execute gcc is "compilation". In others, gcc does a whole bunch of things, only some of which are "compilation".
I think it was astute of Mr. Edge to leave out the preprocessor-output-as-source-code angle, frankly. A close look at that example makes the case against Red Hat's decision with recent kernel SRPMs stronger, not weaker--and that's not the conclusion he wanted to reach.
Good polemics. Substandard journalism.
Red Hat and the GPL Posted Mar 9, 2011 10:39 UTC (Wed) by AlexHudson (guest, #41828) [Link]
"Similarly, we can view Red Hat's monolithic kernel source RPMs as an *improvement* over that unwieldy, tedious, split-up pile of rubble called patches to the upstream source."
I suspect the number of people who see separate "per-bug" patches as being less useful and a step backwards from a monolithic patch are going to be relatively small. Just considering bidirectionality (the ease of making a monolithic patch versus the difficulty of splitting a monolithic patch) makes that a very difficult argument to subscribe to.
So maybe tone down your own polemic about the standard of journalism.
Red Hat and the GPL Posted Mar 9, 2011 16:28 UTC (Wed) by MisterIO (guest, #36192) [Link]
Same thing I was thinking. Patches splitted in a way that makes sense are far more readable than a monolithic one.
Red Hat and the GPL Posted Mar 9, 2011 20:31 UTC (Wed) by branden (subscriber, #7029) [Link]
I entirely agree with both of you.
My sarcasm was too subtle, alas.
My point was that one big blob of post-cpp C source code is less useful than the original separate .c and .h files, as a monolithic kernel is less useful than a pristine upstream kernel plus a pile of patches.
In both cases, atomization and logical separation is valuable, even essential for downstream to developers to be on equal footing with the distributor. It is that equal footing that the GNU GPL seeks to establish and sustain.
I twigged that Mr. Edge understood how the preprocessor analogy weakened, rather than strengthened, the argument he wanted to make, and that that is why he omitted it despite it being one of the first examples on Mr. Corbet's lips (well, fingers) when the subject came up in an earlier LWN comment thread.
Red Hat and the GPL Posted Mar 9, 2011 21:17 UTC (Wed) by jake (editor, #205) [Link]
> I twigged that Mr. Edge understood how the preprocessor analogy
> weakened, rather than strengthened, the argument he wanted to make
No, I'm afraid that's incorrect. I didn't even consider the "preprocessor analogy" when writing the article. I don't think it weakens the case that Red Hat is not violating the GPL either.
Red Hat distributed its kernel the same way that various other projects have distributed theirs (including FSF projects). They are also distributing their kernel the same way that lots of embedded vendors do, and the community seems perfectly happy with those embedded vendors when they finally get around to doing so. Why is Red Hat different than the FSF or HTC?
I don't have to like what Red Hat is doing (I don't) to see that it doesn't rise to the level of a GPL violation, at least in my opinion. You are, of course, welcome to your own opinion on the matter.
jake
Red Hat and the GPL Posted Mar 9, 2011 21:43 UTC (Wed) by branden (subscriber, #7029) [Link]
Thanks for replying!
"No, I'm afraid that's incorrect. I didn't even consider the "preprocessor analogy" when writing the article. I don't think it weakens the case that Red Hat is not violating the GPL either."
Ah. I must wistfully admit that I wish you'd had a phone conversation or brief email exchange with Mr. Corbet about this, then. It seemed to be an example that was eminent in his mind when he commented in the past week or so.
"Red Hat distributed its kernel the same way that various other projects have distributed theirs (including FSF projects)."
The FSF has copyright in most of the works they distribute, and I can assure you with near-certainty (as I work professionally in this area) that for their most popular and well-known works (glibc, gcc, gdb, bash, ncurses, binutils, etc.) that what little third-party copyrighted code is present is *not* under the GNU GPL, but under far more permissive licenses, such as BSD-style without the advertising clause, the MIT/X11-style license, or others closely resembling the foregoing, none of which mandate redistribution of source forms at all.
Red Hat, as a licensee of the Linux kernel under the GNU GPL, has a responsibility not only to their downstream users but to the other copyright holders in the kernel as well.
Maybe all of the other copyright holders in Linux are cool with this decision. Or maybe they're not, but don't feel they have sufficient resources to pick a fight with a well-heeled public corporation. Or they're not, but have a personal affinity with Red Hat kernel engineers and feel a sense of gratitude to the firm for offering their friends employment. Or they're not, but feel that Red Hat is still a net positive force in Linux kernel development. LWN could try interviewing some of them to find out what they think.
Copyright law is only one avenue of persuasion. Another is the court of public opinion. I had hoped that LWN, as the news outlet of record in Linux kernel development, would have taken a stronger stance against this move.
What Red Hat is doing is corrosive to the community. The reason people are looking closely at the GNU GPL version 2 for possibilities of a license violation here is that this document, in spite of some members' institutional and/or personal biases against the FSF and RMS, is the pre-eminent social contract under which our community has operated for twenty years.
The GNU GPL has a spirit and a letter; both are important and it is foolish to denigrate either, when both have proven their utility time and again. (I invite anyone who doesn't think the GNU GPL has a spirit to read competing licenses like the CPL, the EPL, the MPL, or the APSL, and then reconsider.)
You just said that you don't agree with this decision. Why, then, write an article which gives Red Hat cover for it? Why offer apparently unsourced speculation as to the views of Red Hat's attorneys when you can speak with perfect authority about your own view?
Make your stand, LWN!
Red Hat and the GPL Posted Mar 9, 2011 21:56 UTC (Wed) by corbet (editor, #1) [Link] Ah. I must wistfully admit that I wish you'd had a phone conversation or brief email exchange with Mr. Corbet about this, then. It seemed to be an example that was eminent in his mind when he commented in the past week or so. Well, I did review the article before it was posted... I don't see how the preprocessor discussion changes things here. The GPL requires distributing the source that you modify. Preprocessing it would violate that; shipping your source tree does not. As a copyright holder in the kernel, I do not agree with or appreciate Red Hat's move in this area. That is a feeling I have communicated on this site and to the people involved in making the decision. It is a step in the wrong direction. That does not mean that I believe the GPL can be used to force Red Hat to change its mind. As far as I know, nobody has ever challenged tarball distribution of source in all these years. Why would we try to start now? I am sorry you do not like the stand we have taken. But I still don't believe that this action, obnoxious as it is, can be called a license violation.
Red Hat and the GPL Posted Mar 10, 2011 0:43 UTC (Thu) by branden (subscriber, #7029) [Link]
"The GPL requires distributing the source that you modify. Preprocessing it would violate that"
The text of the GPL does not mention the C preprocessor. "Everybody knows" that running source through cpp prior to distribution renders it violative of the GPL. Because this is a comfortable old truth, we haven't troubled ourselves to re-justify it from first principles again.
I think that if you explicitly articulate the reasons why post-preprocessed source code is inadequate to meet the definition of source code under the GNU GPL, the case against Red Hat's monolithification of their kernel SRPMS will become more clear.
I have tried to elucidate the matter myself, but I am clearly not a persuasive enough exponent.
Red Hat and the GPL Posted Mar 9, 2011 14:00 UTC (Wed) by samth (subscriber, #1290) [Link]
This is pretty badly wrong with regard to the definition of compilation. In the world of C compilers, the term compilation is often used to mean the transformation of the output of the C preprocessor into assembly, but this is far from universal. In general, cpp, gas, and gcc are all compilers. It's easy to see this by considering compilers for other languages with macro systems, such as Common Lisp, where the "compiler" includes macro expansion, and also the term "JIT compiler", which usually refers to the transformation of a low-level bytecode directly into a binary instruction stream.
If you look up the Dragon book, you'll see that they write "a compiler is a program that reads a program written in one language -- the source language -- and translates it into an equivalent program in another language -- the target language". This fits cpp and gas just as it does gcc.
Red Hat and the GPL Posted Mar 9, 2011 20:36 UTC (Wed) by branden (subscriber, #7029) [Link]
So you're telling me I'm wrong by reiterating my own assertion that the definition of the term is contextual and scope-dependent?
You might as well just call me names, man--it would save time.
Red Hat and the GPL Posted Mar 9, 2011 13:12 UTC (Wed) by pbonzini (subscriber, #60935) [Link]
This preprocessed source argument is a strawman, as hinted by your own sarcasm about a "more holistic experience". A VCS and the C preprocessor have completely different input and output, and especially produce completely different transformations.
The preprocessor is going to introduce lots of duplication in the output compared to the its input. It is not going to simplify modification in any way, except possibly if the non-preprocessed source code is already obfuscated in some why (e.g. one line per file with lots of #includes). So, the first step in performing a modification is not going to be "build the preprocessed sources".
The first step in performing most modifications from a "tarball+patches" form will be to get the sources with all patches applied. This is enough to show that, even though not distributing the history may indeed remove some interesting information, the two scenarios are completely different.
Red Hat and the GPL Posted Mar 9, 2011 14:55 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
In the past it was common for revision control systems to be private, with projects only making tarball releases. In doing so were these projects doing something other than releasing the preferred form for modification?
Red Hat and the GPL Posted Mar 9, 2011 21:05 UTC (Wed) by branden (subscriber, #7029) [Link]
I'm not interested in arguing against a straw man. The contents of a VCS can remain private to the developers as long as they aren't *distributing* non-source forms of the work generated from it.
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) [Link]
You're going to absolutely guarantee that every tarball of GPLed code in Debian is a product of either a public VCS repository or a developer who doesn't use any kind of revision control? I don't recall that ever being a condition of software being included.
Red Hat and the GPL Posted Mar 10, 2011 0:54 UTC (Thu) by branden (subscriber, #7029) [Link]
Again you're moving the goalposts. Why would the VCS need to be public as long the source package contained, oh, I don't know--an .orig.tar.gz plus one or more (nowadays) .diff.gz files representing the patches made by Debian to the upstream source?
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.
Red Hat and the GPL Posted Mar 10, 2011 1:24 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
You appear to be saying that Red Hat, by distributing a pre-patched tarball without the individual patches, are not providing the preferred form for modification. The point I'm trying to make is that multiple projects take individual patches (which may or may not be publicly available), merge them into their project and release a pre-patched tarball without the individual patches. The fact that Debian has no compunctions about shipping code in the latter category suggests that nobody's arguing that that's not the preferred form for modification, so where are you drawing the distinction?
Red Hat and the GPL Posted Mar 10, 2011 1:53 UTC (Thu) by branden (subscriber, #7029) [Link]
"The fact that Debian has no compunctions about shipping code in the latter category"
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.
Red Hat and the GPL Posted Mar 10, 2011 2:03 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
What? No, that's not even slightly what I'm talking about. The simple and obvious fact is that some upstream projects only distribute patchless tarballs despite their development being performed in a patch-oriented manner. Not all of these upstream projects are the sole copyright holders of the code in question. Debian ship these projects anyway, which implies that nobody seriously thinks that they're violating the GPL.
Red Hat and the GPL Posted Mar 10, 2011 3:05 UTC (Thu) by branden (subscriber, #7029) [Link]
And not all of those are even licensed under the GNU GPL.
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?
Red Hat and the GPL Posted Mar 10, 2011 3:20 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
The kernel's the highest profile example. 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. 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 .
Red Hat and the GPL Posted Mar 10, 2011 16:34 UTC (Thu) by branden (subscriber, #7029) [Link]
"The kernel's the higest profile example."
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
Have a look sometime.
Here's a terminal transcript, edited for space and clarity:
$ apt-get source linux-patch-debian-2.6.32
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.
Red Hat and the GPL Posted Mar 10, 2011 16:37 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
"Upstream projects".
Red Hat and the GPL Posted Mar 10, 2011 23:34 UTC (Thu) by branden (subscriber, #7029) [Link]
Gonna have to be less terse.
Are you saying that the Linux kernel isn't upstream for Red Hat, but it is for Debian, or vice-versa? Or both?
Or neither?
Red Hat and the GPL Posted Mar 10, 2011 16:38 UTC (Thu) by gregkh (subscriber, #8) [Link]
>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.
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.
Red Hat and the GPL Posted Mar 10, 2011 23:39 UTC (Thu) by branden (subscriber, #7029) [Link]
"Please do not read ANYTHING into my comments about this other than explicitly what I stated."
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.
Red Hat and the GPL Posted Mar 13, 2011 2:06 UTC (Sun) by vonbrand (subscriber, #4458) [Link] 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.
Red Hat and the GPL Posted Mar 11, 2011 9:25 UTC (Fri) by PaXTeam (subscriber, #24616) [Link]
> My personal opinion is that Red Hat is fine in doing this if they want to.
then why did you see the need to explicitly call them out in the 2.6.32.30 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?
Red Hat and the GPL Posted Mar 11, 2011 16:45 UTC (Fri) by gregkh (subscriber, #8) [Link]
I only "called out" a thanks to Max for digging through the large
patch from Red Hat to figure out what patches should be applied.
That work was hard based on the format that Red Hat is shipping their
>> Red Hat didn't make this very easy due to their "one giant patch"
Um, this makes no sense as that is not how upstream development works.
Red Hat and the GPL Posted Mar 11, 2011 22:43 UTC (Fri) by PaXTeam (subscriber, #24616) [Link]
> 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.
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?
Red Hat and the GPL Posted Mar 9, 2011 20:31 UTC (Wed) by sepreece (subscriber, #19270) [Link]
I have wondered for some time whether distributing original code plus patches was a compliant approach at all, given that the license requires "complete corresponding source code". Yes, the original code plus patches can be transformed into the complete corresponding source code, but it's hard to claim that it's the preferred form for working on the source code - most of us would want to apply the patches before we did any work on the code.
Red Hat and the GPL Posted Mar 9, 2011 20:58 UTC (Wed) by branden (subscriber, #7029) [Link]
On the one hand, that's not necessarily true. If you're working for a distribution but work closely with your upstream, you might work "in" your Debian source or SRPM environment, but test for the existence of a user-reported bug in the upstream code first, and if it is present there, patch it there before porting it back down to your own distro.
Needless to say, this pattern is often done in reverse, but I'm sure a lot of upstreams would like to see more instances of the above.
And that's exactly why Red Hat's move here has some kernel hackers (Greg K-H at least) wincing.
On the other hand, as long as there is no information loss either way in a two-way transformation, and the tools to convert from one form to the other are widely available, I don't think the spirit nor the letter of the GNU GPL is infringed.
That Red Hat's conversion from source+patches to monolithic when generating the SRPM is inescapably information-lossy is precisely the competitive advantage they are seeking from it.
Red Hat and the GPL Posted Mar 10, 2011 10:28 UTC (Thu) by pbonzini (subscriber, #60935) [Link]
> On the one hand, that's not necessarily true. If you're working for a
> distribution but work closely with your upstream, you might work "in" your > Debian source or SRPM environment, but test for the existence of a > user-reported bug in the upstream code first, and if it is present there, > patch it there before porting it back down to your own distro. > > Needless to say, this pattern is often done in reverse, but I'm sure a lot > of upstreams would like to see more instances of the above. > > And that's exactly why Red Hat's move here has some kernel hackers (Greg > K-H at least) wincing.
If I understand correctly, you want to cherry-pick patches from 2.6.32-el6 to 2.6.32-stable. So you're treating here "2.6.32-stable" as the downstream and "2.6.32-el6" as the upstream. Nobody disputes here that the monolithic kernel SRPM is making things harder. However, note that you are _not_ making modifications to RHEL kernel. You'd like the RHEL kernel to be distributed in your preferred form "for modification of something else", and that's not a right that the GPL grants you.
Red Hat and the GPL Posted Mar 10, 2011 23:46 UTC (Thu) by branden (subscriber, #7029) [Link]
"Nobody disputes here that the monolithic kernel SRPM is making things harder."
Please be more precise. What is being made harder?
"You'd like the RHEL kernel to be distributed in your preferred form "for modification of something else", and that's not a right that the GPL grants you."
RHEL's kernel is not an independent work from the Linux kernel, be it the latest drop of the 2.6.32 kernel or some other variant. If it were, Red Hat Software, Inc. could just slap their copyright notice on the whole thing and tell everyone else to get lost.
Both of the things you are talking about are the Linux kernel, copyright 1991-2011 Linus Torvalds et al.
The Linux kernel is "the Work" under the terms of the GNU GPL.
The Linux kernel is not a "something else" when compared to the Linux kernel.
Red Hat and the GPL Posted Mar 11, 2011 8:32 UTC (Fri) by pbonzini (subscriber, #60935) [Link]
> "Nobody disputes here that the monolithic kernel SRPM is making things harder."
> > Please be more precise. What is being made harder?
Identifying RHEL patches that are not in 2.6.32-stable and applying them to 2.6.32-stable. Red Hat engineers do try to Cc stable@kernel.org on their patches, but it's possible that: a) they sometimes forget; b) they cherry-pick patches by authors who didn't Cc stable@kernel.org. Attems is trying to get into stable those RHEL patches which "fell through the cracks", and the monolithic SRPM makes the job harder. But he's not trying to modify the RHEL kernel itself (read on).
> Both of the things you are talking about are the Linux kernel, copyright 1991-2011 Linus Torvalds et al.
The 2.6.32 kernel as released by Linus is a Work. The 2.6.32-stable kernel is another Work that is a derivative of the 2.6.32 kernel as released by Linus. So is the RHEL kernel. Each is distributed separately and modifications to each should be considered separately. Cross-pollination of the RHEL kernel into the Linux-stable tree is modification of _only one_ of these three works---and not the one that Red Hat distributes. In this sense you're modifying "something else".
The GPL does not force whoever distributes modifications to make backports of those modifications easy. For example, renaming variables is an example of a possibly-hostile action that is not prohibited by the GPL.
But we're wondering dangerously into IANAL area, so I'm unlikely to comment further on this topic.
Red Hat and the GPL Posted Mar 9, 2011 5:26 UTC (Wed) by ccurtis (guest, #49713) [Link]
Red Hat has every right to only support their own kernels; that only makes sense. And they're within their right to send their modifications as a single patch.
However - and this is the biggest problem I see (perhaps I don't see enough) - is that Red Hat *is* Linux and *is* Open Source for so many people. Red Hat is the standard bearer. Red Hat should stand to the highest levels of integrity and openness (when dealing wrt free software). Because if Red Hat can do it, then so can ${RANDOM} company.
I expect the financial situation is taking a toll on support contracts in general, and as more people become better versed in things Linux, the need for external support wanes. Hopefully, this is a passing phase and not actions taken on behalf of some mandate to increase revenues to improve shareholder valuations.
A stable player in a stable market is more valuable than a company eternally chasing quarterly returns.
Red Hat and the GPL Posted Mar 9, 2011 5:44 UTC (Wed) by gdt (subscriber, #6284) [Link] The complaint of the time was exactly as Jon wrote: In the distant past, there were also complaints that Red Hat will terminate its support contract for users that run their own kernel, rather than what is supplied with RHEL. This is not what you are arguing, where if you run a custom kernel you can gain support from Red Hat for an issue by rebooting with the Red Hat-provided kernel and reporting the issue in that environment. With this older policy, the act of running the custom kernel had terminated your support and thus you had no support contract to report the bug if it was also present when running the Red Hat-provided kernel.
Red Hat and the GPL Posted Mar 9, 2011 7:11 UTC (Wed) by juliank (subscriber, #45896) [Link]
git is really more like a file system, and thus not part of the source requirement.
Red Hat and the GPL Posted Mar 9, 2011 10:06 UTC (Wed) by dark (subscriber, #8483) [Link] One could argue that those methods do provide the source code, but it certainly isn't in a form preferred by anyonenor does it adhere to the "medium customarily used for software interchange" requirement.This in itself indicates that "preferred form" must refer to more than the choice of medium. Clause 3 already requires that source code must be presented on a medium customarily used for software interchange, so cuneiform tablets are right out. There would be no need for the "preferred form" definition if that is all it meant. As for VCSes: I think there's not necessarily an equivalence between what Red Hat does with the kernel and what most projects do. The ordinary use of a version control system is to keep track of older versions of the code, and these older versions are not used to produce the binary. They are not needed for "complete source code" because the tip of your VCS already has "all the source code for all modules it contains". That's if you use the VCS as an archive. But if you're using your VCS as a patch queue, where the whole queue evolves as you make modifications, then the patch queue itself is the preferred form of your work. Now, I don't know if Red Hat does this. I don't know their workflow. But the difference can be illustrated with a simple question: if Red Hat engineers discover that one of their patches has a problem and needs to be fixed, do they fix it by committing another patch to the head of that branch? Or do they edit the patch and then rebase? In the former case, they're just using their VCS to track their history of changes. In the latter case, the evolving branch is their source code.
Red Hat and the GPL Posted Mar 9, 2011 10:19 UTC (Wed) by airlied (subscriber, #9104) [Link]
describing the RHEL kernel has a patch queue is totally wrong.
Its a fork of the Linus kernel and is maintained nearly the same way, no rebase, linear development.
Red Hat and the GPL Posted Mar 9, 2011 10:50 UTC (Wed) by dark (subscriber, #8483) [Link] Well in that case I see no GPL issue with distributing the latest version as a single tarball.
Red Hat and the GPL Posted Mar 9, 2011 10:38 UTC (Wed) by pbonzini (subscriber, #60935) [Link]
> if Red Hat engineers discover that one of their patches has a problem and needs to be fixed, do they fix it by committing another patch to the head of that branch?
Yes, at least in the case of the kernel. Other packages may be handled differently.
Red Hat and the GPL Posted Mar 9, 2011 14:37 UTC (Wed) by vonbrand (subscriber, #4458) [Link] This is ludicrous. How can the fact that somebody does a Preferred form for "building, studying and modifying" just isn't the same as for doing archaeology.
Red Hat and the GPL Posted Mar 9, 2011 21:10 UTC (Wed) by branden (subscriber, #7029) [Link]
"This is ludicrous. How can the fact that somebody does a git rebase make that the preferred form for the code suddenly isn't a tarball anymore?"
Well-stated. I don't know why so many people keep dragging the VCS issue into things.
The complaint was *not* "Red Hat doesn't make their git trees public!"
Why do people insist on pretending as if it was?
It is possible for Red Hat to distribute the kernel SRPMs in a form which unambiguously satisfied the letter and spirit of the GPL without exposing their git trees to the public. How do we know that? Because until recently, they'd spent years doing it.
People are not asking for the moon here.
Red Hat and the GPL Posted Mar 9, 2011 21:36 UTC (Wed) by dark (subscriber, #8483) [Link] Well I wasn't talking about access to the VCS at all. I was talking about publication of the patch queue. If the patch queue as a whole is the thing that you modify and that changes over time, then that's the source. It would even make sense to check the patches into a VCS so that you get meta-patches to track the changes, which is something I've seen done.However this doesn't seem to apply to the RHEL kernel so it's just hypothetical.
Red Hat and the GPL Posted Mar 9, 2011 10:36 UTC (Wed) by giggls (subscriber, #48434) [Link]
So in future these patches will have to be posted somewhere in an annonymous way, because it is perfectly legal to publish them.
The only thing that happend is a breach of a Redhat support contract between the annonymous poster and Redhat. This is something most publishers of the patches do not need to care about.
Red Hat and the GPL Posted Mar 9, 2011 10:49 UTC (Wed) by paulj (subscriber, #341) [Link]
I'd like to restate my comments on earlier points. These points are speculative/exploratory, however I do think it's important for the community to be careful about ceding to a narrow interpretation of the GPL mostly out of respect for a friend. The friend may be trust-worthy and generally do the right thing, but others may not be.
Firstly, re "preferred form". The article makes the claim that RedHats' preferred form is not a factor for the GPL, but I can not find anything in the GPLv2 text to back this up. Surely the distributor's preferences for the form to work on *would* be a major factor in deciding whether the released source meets the "preferred form for modifications" criteria of the GPL? This part of the article seems very weak and poorly substantiated (if not outright wrong).
It used to be that RedHats' source for the kernel was a src.rpm with a base kernel and a series of patches, which was the source input to the build process for the kernel binary rpm. To me, it's fairly clear the GPL's definition of "source" would require that original src.rpm to be released, rather than any intermediate, auto-generated form with all the patches collapsed. However, it could be their process is now different and there no longer is such a "split patches" src.rpm. It could be their processes now are to build directly from the head of a git tree, in which case RedHat may be fine as this significantly decouples the history from the build process, and history is not source - though their reputation in the community may still suffer.
Red Hat and the GPL Posted Mar 9, 2011 10:54 UTC (Wed) by gevaerts (subscriber, #21521) [Link]
How do you modify source? Do you edit patches, and then apply them as part of the building process, or do you edit the actual source and generate the patches as part of your change management process?
The way I see it, the GPL talks about "the preferred form of the work for making modifications to it", *not* about "the preferred form of the work for tracking changes", or "the preferred form for storing the work"
Red Hat and the GPL Posted Mar 9, 2011 11:31 UTC (Wed) by paulj (subscriber, #341) [Link]
This isn't about editing patches directly (which, btw, is perfectly possible and something many maintainers of software projects will have done). This is about the sources which RedHat use for the kernel RPM. The process literally /did/ used to be about patches:
1. the src.rpm was created from an RPM spec file, which specified as input various files, including a base Linus kernel tarball and a bunch of patches.
2. the kernel binary RPM was built from this src.rpm.
RedHat maintainers literally did check in *patches* to CVS, as the source of their kernel src.rpm. Under this process, the patches clearly *are* part of the source for the build. (Note src.rpm is a reversible process, so the src.rpm file and the unpacked files are equivalent, i.e. step 2 could skip creating the actual src.rpm file - the point is the source consisted of patches).
Now, some of this has clearly changed - they're using git. It could they're now using git to apply patches to a kernel tree and building directly from that (as airlied seems to indicate), in which case it seems unlikely the history is covered by the GPL. However, if the start of the build process still works on a patch list, then that would still seem to be source and should be released.
Red Hat and the GPL Posted Mar 9, 2011 12:58 UTC (Wed) by gevaerts (subscriber, #21521) [Link]
It has changed, yes, and I agree that patches are nicer for other people to look at what's changed, and it is indeed possible to edit patches if you really want to, but I still claim that most (if not all) of the actual modifications were done on a fully patched tree. That there were (or possibly still are) separate processes to split out those patches is interesting from a maintenance and documentation point of view, but I really don't see how that makes the patches the preferred form for modifications.
Red Hat and the GPL Posted Mar 9, 2011 13:17 UTC (Wed) by paulj (subscriber, #341) [Link]
Evidence for base+patches being the preferred form:
1. RedHat used this form for maintaining (in the sense of humans doing the work) the source of their kernel RPMs
2. RedHat *still* have, at least, processes using this form, if not humans
3. Other corporates *also* have preferred this form (e.g. Sun)
It'd be interesting to know whether or not RedHat still internally are using the base+patches src RPM form for doing maintenance work. Your comment seems to suggest this is a possibility. In which case, RedHat really ought to be releasing the base+patches. It's really hard to argue the base+patches are NOT the preferred form if that's what you're using internally to maintain & build the distributed binary RPMs..
Red Hat and the GPL Posted Mar 9, 2011 13:35 UTC (Wed) by gevaerts (subscriber, #21521) [Link]
I think talking about "the preferred form" is misleading, because there is not one single preferred form.
I can think of the "preferred form for making modifications", the "preferred form for long-term maintaining the code", and the "preferred form to understand the history of the code".
In my opinion these are rather different.
You seem to be talking about the last two, but the GPL explicitely talks about the first.
Red Hat and the GPL Posted Mar 9, 2011 13:59 UTC (Wed) by paulj (subscriber, #341) [Link]
Talking about the "preferred form of the work for making modifications to it" is not misleading, it's the crux of the matter - this is the actual text of the GPL! Maintaining a work requires making modifications. Indeed, affording end-users the ability to maintain the software on their devices, even if the vendor has lost interest, was a prime motivation in formulating the GPL.
Red Hat and the GPL Posted Mar 9, 2011 20:43 UTC (Wed) by sepreece (subscriber, #19270) [Link]
Yes, but *whose* preferred form for making modifications? What matters, in the context of the intent of the license, is what would be preferred by a downstream modifier, NOT the preference of the entity distributing the source code.
Doesn't seem, to me, to be a question that has a single answer.
Red Hat and the GPL Posted Mar 9, 2011 13:14 UTC (Wed) by Los__D (guest, #15263) [Link]
Any of this does not change that the preferred form for making modifications is pure source, not patches.
How they track their changes and how they store the result of those changes does not matter at all.
You modify the source, not the patches.
Red Hat and the GPL Posted Mar 9, 2011 13:24 UTC (Wed) by ewan (subscriber, #5533) [Link]
Actually, a common pattern for modifying the RHEL kernel RPM is by ading or removing patches in the RPM spec file. Which is why people prefer it to have split patches.
If people actually preferred a monolithic tarball no-one would be objecting to this, and Red Hat wouldn't be talking about how this change is actually intended to make life harder for downstream users of the code.
Given that this is explicitly about obstructing Oracle et al it's clear that Red Hat are under no illusions that this form is actually preferred by anyone - if it were they wouldn't be doing it.
Red Hat and the GPL Posted Mar 9, 2011 14:01 UTC (Wed) by Los__D (guest, #15263) [Link]
And a common pattern for modifying a binary is by running it through a HEX editor, which is completely irrelevant, just like common patterns for modifying RPMs.
Again, the preferred form for making modifications is the raw source, not patches. The preferred form for tracking modifications might be patches, but this (again) is irrelevant.
Red Hat and the GPL Posted Mar 9, 2011 14:16 UTC (Wed) by ewan (subscriber, #5533) [Link] completely irrelevant, just like common patterns for modifying RPMsWe'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.
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.
Red Hat and the GPL Posted Mar 9, 2011 17:22 UTC (Wed) by paulj (subscriber, #341) [Link]
If you're developing a code-base, yes, you don't need anything but the source code.
OTOH, if you're maintaining a code-base, adding patches temporarily (or not) while tracking an upstream, then it's more convenient to work with a system that allows you to easily distinguish between each change, relative to the upstream. E.g. a pristine tarball + patches, or a git tree.
I've worked on both developing an upstream code-base and maintaining a supported version of that same code-base, at a big distributor/vendor, and we used both methods, as appropriate. For the supported, released binaries - they were built from pristine+patches, and that's what got released as the source (just as RedHat used to).
Red Hat and the GPL Posted Mar 9, 2011 14:05 UTC (Wed) by clugstj (subscriber, #4020) [Link]
I had tried to make this exact point in an earlier article. The "preferred form for making modifications" is NOT a pristine source and a large group of patches. RedHat (and anyone else) is fully within the GPL by doing what they are now doing. There is much bitching now only because they used to do something else which some people had become dependent upon.
Red Hat and the GPL Posted Mar 9, 2011 14:59 UTC (Wed) by vonbrand (subscriber, #4458) [Link] If you look at how git works, you will see that it nowhere handles patches, only blobs containing actual file contents at a point in time. So asking for patches as the "way in which Red Hat does their work" is total nonsense.
Red Hat and the GPL Posted Mar 9, 2011 17:38 UTC (Wed) by paulj (subscriber, #341) [Link]
You're making the standard engineers mistake of considering that boundaries defined by technicalities in one field map to boundaries in the legal world. They don't. Judges are juries are often perfectly free to gloss over non-legal technicalities, and even take things like human intent into consideration.
(Another common example of such a mistake is thinking that GPL derivation status can be washed away by adding technical boundaries like shared libraries or network sockets).
Red Hat and the GPL Posted Mar 9, 2011 20:33 UTC (Wed) by vonbrand (subscriber, #4458) [Link] I'm quite aware that legal and technical worlds are apart. But that doesn't make that to distribute source "in the preferred form for modification" you have to create new artifacts (patches) that arguably aren't that useful for direct modification. Sure, said patches help in reconstructing the history and (via attached comments) the motivation for changes that have been made. But GPL looks forward (build on what you have got) not backwards (go scrounge around in the history of the code) and even less considers creating chimaeras out of applying a random subset of the changes that got the code as it is today. Perhaps that was a mistake in drafting the GPL, take that up with the appropiate people.
Red Hat and the GPL Posted Mar 9, 2011 20:20 UTC (Wed) by vonbrand (subscriber, #4458) [Link] Taking this to an extreme, my preferred form for hacking on random code is a running XEmacs with a buffer open on each file. Do I have to distribute that somehow? That in the course of working on some piece of code I use (for convenience, for speeding up compilation, or any other random reason) some particular representation does not make that automatically useful for others (some people I respect use vim ;-), and thus not necesarily "preferred". So that/if Red Hat uses/used a SRPM with broken out patches at some point is wide off the mark: They have to distribute the complete source with with to rebuild the binaries, nothing more.
Red Hat and the GPL Posted Mar 18, 2011 18:55 UTC (Fri) by mishad (guest, #69757) [Link]
> Taking this to an extreme,
The law doesn't do that -- judges interpret contracts "reasonably" not as what they might mean if taken to extremes.
> They have to distribute the complete source with with to rebuild the binaries,
Yes.
> nothing more.
Not quite -- they also need to identify their changes:
GPL v2 $2 (a): You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change
Distributing "base + patches" is arguably one way to do that. "Base + monolithic-patch" might be another. Simply adding a note in the file header is also OK.
preferred form Posted Mar 9, 2011 10:51 UTC (Wed) by wingo (subscriber, #26929) [Link] The GPL says: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. Surely if we consider the work to be the Linux kernel, then the source of the Linux kernel is the preferred form for modifications to it, and not the patches that make it up, a dump of the filesystem it is stored on, etc. I do not understand the objection that separate patches are necessary to comply with the GPL, as the patches are not the work in consideration: the source code is.
preferred form Posted Mar 9, 2011 15:23 UTC (Wed) by __alex (subscriber, #38036) [Link]
Some people seem to think that the change to the source distribution effects their rights under freedom 1 ("The freedom to study how the program works, and change it to make it do what you wish") of the FSF philosophy, which is what the GPL is meant to represent through copyright law.
I think any argument that they are breaking the word of the GPL with this change is pretty tenuous but I can understand why people are a bit upset about it. Also people love to rage about things and GPL compliance is easy to bikeshed over.
Preferred form for whom? Posted Mar 9, 2011 11:01 UTC (Wed) by dwmw2 (subscriber, #2063) [Link] Obfuscated source code, are a bit more of a gray areabut not much. Those kinds of actions should be seen as clear attempts to circumvent the GPL requirements. But that's not at all what Red Hat is doing.Isn't it? When coupled with a clear attempt to dissuade customers who do have access to the patches from disseminating them further, how could it be interpreted differently? The lack of patches from the SRPM is not just a benign side-effect of some other change in the development process; it seems clear that it is intentional, and done in order to avoid releasing those patches to the public. The tarball that Red Hat is releasing may not be the preferred form for the Red Hat kernel developers to use, but that is not part of the requirement.Isn't it? The GPL requires that the source be distributed in the "preferred form of the work for making modifications to it". The GPL is silent on whose preference is relevant here, and what they should have to do to prove that they really prefer things the way they claim. It's not reasonable for a distributor to claim that their preferred form is precompiled assembly code, nor for a recipient to claim that they prefer the code to be distributed with full hardware documentation and the email address, phone number or ICBM co-ordinates of the hardware designer (although the latter is certainly true in many cases). I only really see one reasonable interpretation of the "preferred form" clause it has to be "the form which is agreed by consensus, among experts in the field, to be the preferred form for modifying the work". Is there any other sane interpretation? (Or, as I suppose is more to the point, is there any other interpretation which is likely to be accepted in court?)
And Red Hat's kernel engineers are a representative sample of the experts in this particular field. I think their preferences are exactly part of the requirement, aren't they? So, what is the general consensus on the preferred form for modifying a work? In the case of an "upstream" work, tarballs are certainly fine. But where the work is a fork or modification of an existing project, the situation is very different. Just go and talk to any competent open source developer about how to distribute that kind of code, and she will tell you that distributing a simple tarball of your modified version is ABSOLUTELY NOT the preferred form. Nor is it even close. I've done a lot of work on porting Linux to embedded devices where the device manufacturer has "had a go" at porting it for themselves, and has given us their attempts as a starting point. Back in the early years of this century, we regularly used to get tarball releases like that. Trust me, if you had heard the language we used as we went through these abominations, trying to work out what the hell was in there (e.g. 2.4.14 + rmk1 + np3 + random other patch sets before they even started to make their own changes), you would not be trying to make an argument that a monolithic tarball could possibly be the "preferred form of the work for making modifications to it."
Preferred form for whom? Posted Mar 9, 2011 11:42 UTC (Wed) by paulj (subscriber, #341) [Link]
Amen to this. Having been a software maintainer myself (including in a large corporate setting), pristine upstream base-line + patches (as fine-grained as possible) are quite obviously the preferred form for maintaining corporately supported versions of free software projects. Anything else leads to significant inefficiencies and hair-pulling.
It used to be you'd check in actual tarball + patch files into an SCM (RedHat did this - perhaps still do; Sun did this with its SFW consolidation). However, current SCMs are now so good at examining history (git particularly) you can afford to check in the patched sources.
The interesting question then is, does that affect the preferred form requirement? If the patches used to be directly a source input to your build process (and hence clearly covered by the GPL), if having access to those patches is important to be able to maintain (i.e. modify further) that code base, if then by some technicality the build process no longer works on the patches to what extent are the patches no longer preferred for the purposes of the GPL?
Preferred form for whom? Posted Mar 9, 2011 20:37 UTC (Wed) by vonbrand (subscriber, #4458) [Link] Nope, that is just the typical way forks that intend to track upstream are handled internally.
Preferred form for whom? Posted Mar 9, 2011 20:41 UTC (Wed) by dwmw2 (subscriber, #2063) [Link] Because we "typically" do things the way we don't prefer to?
Preferred form for whom? Posted Mar 9, 2011 23:12 UTC (Wed) by rahvin (subscriber, #16953) [Link]
What you prefer is not how the GPL is defined.
The definition of preferable form if not defined in the license it is defined by the creator of the licenses intent, verified through statements or writings. If that is not conclusive the court will create it's own definition.
As the creator of the GPL defined preferable form numerous times in public writings and speeches that last step will never be necessary and the GPL's author's intent is not in question. RMS has stated several dozen times that the clause you are citing was to prevent the paper source code exploit. Since Redhat is not distributing source code by printing it out, the issue is null.
Preferred form for whom? Posted Mar 10, 2011 1:30 UTC (Thu) by branden (subscriber, #7029) [Link]
You're confusing the paragraph defining source code with clause 2b), which comes two paragraphs earlier:
" b) Accompany it with a written offer, valid for at least three
The above is wholly sufficient to eliminate the paper copy loophole.
I told you originalism was bad exegetics. It promotes muddled thinking. Primarily, it encourages one to sublimate one's own views into the minds of historical personages and pretend there is no difference.
If you think the U.S. courts of law are bound, through either law or tradition, to treat RMS as an oracle, you are mistaken. They are entirely within their discretion to accept him as an expert on the intended meaning of the GNU GPL--or not--and to give his pronouncements as little or as much weight as they please.
Preferred form for whom? Posted Mar 10, 2011 3:11 UTC (Thu) by branden (subscriber, #7029) [Link]
There's a typo in the above; I quoted 3b), not 2b).
But 3a) is even more squarely on point:
" a) Accompany it with the complete corresponding machine-readable
That's what closes the source-printed-on-paper loophole. Not the "preferred form of the work for making modifications to it."
Put differently, if you're right about the "preferred form" wording being the cause of the elimination of the paper loophole, then the "medium customarily used for software interchange" language becomes redundant and therefore meaningless.
Ask an attorney (I'm not one), and they will tell you that there are standard rules of construction that courts use when interpreting legal documents that strive *not* to create redundancies or rob language of meaning.
Preferred form for whom? Posted Mar 11, 2011 1:00 UTC (Fri) by rahvin (subscriber, #16953) [Link]
Your right, I've confused the two clauses. But that doesn't change the arguement. The GPL is a software license. It's commonly handled in the US under precedents and written law that differs materially from Contract law in only a few circumstances.
Anyway, when brought before a Judge it's the plain language of the license that matters. Where that plain language is ambiguous and the parties don't agree on the intent the court is obligated to consider extrinsic evidence including the intent of both parties at the time the agreement was executed (good luck on that). It's important that both parties know each other intent or have made available their intent in some way otherwise their intent becomes ambiguous and you move to the next step. Baring that knowledge the Judge is obligated to turn to the creators of the agreement. Baring that there are many other sources of extrinsic evidence that can be examined. Baring that it's up to the Judge to try to find an equitable solution to the disagreement.
My main point all along is that RMS has defined what every single one of the clauses in the GPL are for, what they mean and what exploit of the agreement they are meant to prohibit. Baring some exchange of intent between the licensee and the licensor those statements are the highest value source the Judge is going to find explaining the intent of the GPL license. There may be other information that adds to the information available but to argue that isn't the basis for the agreement is ignoring the entire history of how the GPL came about and why it was created. RMS is directly responsible for the GPL, through his work that agreement was created and when you sign on to use that agreement, unless you state otherwise, you are agreeing to those terms and the reasons they exist.
My secondary point is that there are probably as many work flows and preferred forms of source code as there are developers. Baring any clear statements of intent from a developer what does a licensee have to rely on other than the plain language of the agreement based on RMS's definition of what the agreement means? I'll argue that there is nothing wrong with changing that meaning, but you need to write your own agreement and call it something other than the GPL because if your intent and interpretation differs from RMS, you aren't using the General Public License.
RMS has defined preferred form, that's the definition that applies baring the use of a different license.
Preferred form for whom? Posted Mar 11, 2011 9:51 UTC (Fri) by PaXTeam (subscriber, #24616) [Link]
> [...]you are agreeing to those terms and the reasons they exist.
unless those reasons are explicitly spelled out in the license, no, you can't possibly be agreeing to them. what you do agree to is what's in the license, nothing more, nothing less.
> RMS has defined preferred form, that's the definition that applies
you keep mentioning his definition/interpretation, where is it?
Preferred form for whom? Posted Mar 11, 2011 18:14 UTC (Fri) by rahvin (subscriber, #16953) [Link] unless those reasons are explicitly spelled out in the license, no, you can't possibly be agreeing to them. what you do agree to is what's in the license, nothing more, nothing less.If the licensor hasn't made his definition of preferred form (if it's different than the GPL definition) available to the licensee at the time the license is executed the extrinsic evidence available to the court will be considered. The best of that evidence is the statements by the FSF and RMS on what the GPL means and why they wrote it, after all they are essentially the legal team that crafted the license. To legally demonstrate any other interpretation you would have to prove that the licensee was aware of some alternative interpretation at the time of license AND prove that the GPL definition is ambiguous. Whatever your preference is (and most people will have different preferences) is not necessarily what the licensee interprets when he draws a license. The problem I have with this discussion is that people are pulling a single sentence out of the license and trying to reinterpret that sentence however they want without regard to the agreement or it's history. There are numerous places within the GPL where the preferred form is defined implicitly although not directly. 3. B. Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,The reference to preferred form, in my opinion, is a direct reference back to the paper copy exploit section and the binary source exploit section. Although the language could be a little clearer I don't think there is any doubt that the preferred form is machine readable source code on a medium typically used for software interchange. How that source is arranged as long as it's not obfuscated is beyond the license agreement. It would be absolutely silly to assume that whatever the licensee interprets to be their preferred form is the form the licensor has to comply with. There is absolutely no doubt that the vanilla with patches and comments method is far more useful. But the license only requires that you be provided the source code in a manner that is editable and machine readable. As far as providing quotes of RMS's speeches I have better things to do with my time. I've seen him discuss this and the methodology they went through when they created the agreement (basically trying to figure out how a naughty licensee will try to exploit the license to prevent free use of the source). I'm sure a paralegal can dig up plenty of references to RMS's and the FSF's intent when the GPL was drafted. Maybe at some point he'll weigh in on the issue but I doubt he will. If you want to pursue this line though you need to consider that there are probably more projects using the unified tarball than there are projects that are providing vanilla, patches and comments. I think RedHat's move will complicate development of the kernel. But I also believe it's a necessary move if RedHat has any intention of responding to Oracle's attempts to destroy them. And I also believe RedHat could address the concerns by giving the concerned developers access to the information that's now missing. And I believe that if they fail to address this issue it could hurt them more than it helps. But I don't believe this is a GPL violation and I think it's a dramatic situational reinterpretation of the GPL and is something that could scare a lot of companies away from GPL. Just imagine for a moment that anyone that uses the software can redefine "preferred form" however they would like and what that would do to the community.
Preferred form for whom? Posted Mar 11, 2011 22:35 UTC (Fri) by PaXTeam (subscriber, #24616) [Link]
> If the licensor hasn't made his definition of preferred form (if it's different than the GPL definition) [...]
ok, i think i see where your thinking went astray. you keep mentioning this 'GPL definition' of 'preferred form'. thing is, it does *not* exist. really, look at the GPLv2 (the license of linux) and see for yourself. what the GPL does define there is the 'source code', in terms of 'preferred form for modification'. it does *not* further elaborate on just what this 'preferred form' is. this is the entire reason for these discussions here because different people have quite different (or even contradictory) ideas about 'preferred form'.
> The reference to preferred form, in my opinion[...]
see, that's your own opinion only, noone seems to share it. and for good reason, that sentence in section 3.b does not define 'preferred form for modification'. really, if the license wanted to further elaborate on that term, it should and would have done so explicitly, like it already does for other terms where the license authors saw it necessary to be precise (whether they achieved that or not is another question but let's not digress). as to what your highlighted sentence was about see this thread somewhere else where others explained it. it's most definitely not about the 'preferred form for modification' term.
> Although the language could be a little clearer I don't think there is
the GPL does *not* contain the word 'obfuscation'. where did you pull that requirement from? and what does it mean? what is considered 'obfuscation'?
> It would be absolutely silly to assume that whatever the licensee
i've seen people argue the exact opposite view in defense of RH here, but let see, if i take your view then it's bad news for RH as their *own* 'preferred form' is clearly sending patches around among their own developers, not entire tarballs as in the RHEL6 srpm. you know, not unlike what they currently distribute in the RHEL5 kernel srpm. how do you explain that two very different forms can both be preferred at the same time?
> But the license only requires that you be provided the source code in a
somewhere above you said it must not be 'obfuscated'. now you say it does not matter as long as the 'source code' is 'editable' (another word not present in the GPL, i don't know where you're getting these from ;). what does that mean? does it have to be in ASCII? 'cos your editor may not do EBCDIC, or whatever i invent for my own 'preferred form'. what if i translate everything into some intermediary representation and do my modification on that, what am i supposed to distribute then? certainly my own tools are mine and not affected by the GPL, so what will you do with that form then? really, instead of inventing new terms not present in the GPL, you should stick to its language and acknowledge where it is ambiguous.
> As far as providing quotes of RMS's speeches I have better things to do with my time.
it's just that you seemed very confident that he had precisely explained 'preferred form'. but it's not important at all, what really matters is the copyright holders' opinion, not his.
> But I also believe it's a necessary move if RedHat has any intention of
paying customers of RH have access to the patches in question (one wonders why they exist if they're not the preferred form for modification, but let's not digress) and so does Oracle (how do you think Sun servers are certified to run RHEL?).
> Just imagine for a moment that anyone that uses the software can
i don't need to imagine anything, i just need to look at the past decades and see what people preferred and did not complain about. i'm sure you know it as well and apparently it didn't scare anyone.
Preferred form for whom? Posted Mar 9, 2011 12:56 UTC (Wed) by pbonzini (subscriber, #60935) [Link]
> The GPL requires that the source be distributed in the "preferred form of
> the work for making modifications to it". > ... > where the work is a fork or modification of an existing project, the > situation is very different.
Note that the GPL is incompatible with licenses that mandate distribution of forks as a patch or series of patches (like the gnuplot license).
Preferred form for whom? Posted Mar 9, 2011 14:57 UTC (Wed) by dwmw2 (subscriber, #2063) [Link] Note that the GPL is incompatible with licenses that mandate distribution of forks as a patch or series of patches (like the gnuplot license).No, the mere fact of requiring that modified sources be distributed in base+patch form rather than as a monolithic tarball is not what makes the gnuplot licence incompatible with the GPL. If you are shipping GPL-based code and, like the gnuplot authors, you want to insist on that behaviour, all you need to do with is add a clarifying note stating explicitly what we all know, which is that "where you distribute a modified form of the software, the preferred form for modifications is the original upstream code base, plus your patches to it." In the gnuplot case, it is other clauses which impose additional restrictions that are incompatible with the GPL. For example the requirement to distribute the patches with the binaries, while the GPL only requires you to provide sources on demand. And the requirement to provide your name and address when you ship a modified version, etc.
Preferred form for whom? Posted Mar 9, 2011 17:25 UTC (Wed) by pebolle (guest, #35204) [Link]
> And Red Hat's kernel engineers are a representative sample of the experts in this particular field. I think their preferences are exactly part of the requirement, aren't they?
Well, look at what the FSF says about Free Software [0]:
I'd say it's no coincidence the FSF only focuses on users here. It seems one of the FSF's goals is to eliminate the barriers between users and the other parties usually involved in software (ie, vendors and developers). The FSF goal is that everyone can be user, vendor and developer of the software they use (if they wish).
So if the discussion of the meaning of "preferred form" should go into this much detail - which I actually think it shouldn't - one should not focus on a very specific group, such as kernel developers, but at users in general. So then the question should be: what is the "preferred form" for, well, almost anyone using computers?
Preferred form for whom? Posted Mar 9, 2011 18:19 UTC (Wed) by dwmw2 (subscriber, #2063) [Link] So then the question should be: what is the "preferred form" for, well, almost anyone using computers?If we accept your premise that we should concentrate on users rather than developers, then the answer is simple. The preferred form of source is no source at all; it just confuses them.
Preferred form for whom? Posted Mar 9, 2011 19:05 UTC (Wed) by pebolle (guest, #35204) [Link]
> If we accept your premise that we should concentrate on users rather than developers, then the answer is simple. The preferred form of source is no source at all; it just confuses them.
No, the answer is almost any reasonable form that allows the user to (at first) "study", (later) "change", and (perhaps, eventually) "improve" the software. (These terms are from the quote I used in my previous post.) The fact that source code will likely just confuse most people using computers (at first, I'd say) is no reason to concentrate on (in this case) kernel developers when interpreting "preferred form".
Preferred form for whom? Posted Mar 9, 2011 20:08 UTC (Wed) by dwmw2 (subscriber, #2063) [Link] It's not just kernel developers. Absolutely anyone with any experience of open source software development will know that dealing with a modified version of an upstream project is painful if you just have a tarball. You absolutely need to see the changes.
Red Hat and the GPL Posted Mar 9, 2011 16:56 UTC (Wed) by RogerOdle (subscriber, #60791) [Link]
1. The GPL only imposes an obligation on RedHat to those is distributes to. Not to anyone else.
2. The GPL does not require RedHat to reveal the patches unless those patches are distributed as items as separate items. That may be the case here, I have not looked at the details.
3. The GPL requires RedHat to share the source of the final product that is distributed with those it distributes to. Those receiving that source can use common GNU tools for building patches themselves, though this will not help them understand much about why the differences are there.
4. It has been a courtesy and a matter of honor that distributors have shared patches. The GPL does not demand it. Any obligation to share patches is outside of the obligations of the GPL and is a matter of contracts beyond the GPL.
RedHat is honoring its GPL obligations by providing the source for its product to its customers. It is protecting itself, as much as it can, by withholding the information for how it got from one distribution to the next.
RedHat is still operating Fedora and that has been and will continue to be a great tool for promoting Linux and educating the public. It is less stable and less suitable than enterprise versions for business purposes but that is intentional. It is the proving ground after all.
Making an enterprise class distribution is very expensive. How long did it take RedHat to lock down, verify, and test RHEL 6 before releasing it? It large team of engineers, time, and equipment. I think the beta was out at least 6 months before the official release. Now companies have started up relying on RedHat to carry the water while they are not obligated to contribute to this hardening process. That is not fair.
I wish people would calm down. This bickering is only a source of laughter for Microsoft and it's proprietary buddies. The Open Source business model was established on a model of trust. We struggle daily with how we honor that trust and the obligations that it imposes on us while we are trying to put bread on our tables. While honorable people are growing in ways that benefit everyone, less honorable people are looking for ways to game the legal system to make a buck at other's expense. I think that RedHat is trying to find a way to protect itself from the less hororable type.
Not quite Posted Mar 9, 2011 17:00 UTC (Wed) by corbet (editor, #1) [Link] Without addressing the real point of your comment, let me note that your point "1" above is incorrect. Unless the source distribution accompanies the binary distribution, the GPL obligates distributors to make the code available to any third party who asks for it. That's an important aspect of the license to understand.
Not quite Posted Mar 9, 2011 17:47 UTC (Wed) by nix (subscriber, #2304) [Link]
RogerOdle's comment would have been correct *if* RH was the sole copyright holder of the kernel. Of course, it is not.
Not quite Posted Mar 9, 2011 21:44 UTC (Wed) by RogerOdle (subscriber, #60791) [Link]
[IANAL]
I do not see an obligation to distribute source to third-parties in the GPL. It declares the rights of those immediately downstream from the distributor to receive source code. Third-party rights are unclear. A third party is entitled to receive source from the second party in the direct distribution chain but how do these rights propagate upward to the original distributor?
I see no obligation to distribute source to parties that are not in the distribution chain. If you allow public downloading of binaries then each download is a distribution and source must be available for each download. If you distribute to specific parties then your obligation is to those specific parties but not to the public.
Section 10. Automatic Licensing of Downstream Recipients.
This section releases the distributor from obligations to enforce the GPL terms on third parties.
This may be nit picking but it is important to know what you obligations and rights are.
Not quite Posted Mar 9, 2011 21:58 UTC (Wed) by corbet (editor, #1) [Link] I do not see an obligation to distribute source to third-parties in the GPL. It declares the rights of those immediately downstream from the distributor to receive source code. Third-party rights are unclear. From the license text:
You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following... b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange... (Emphasis added). Seems pretty clear to me...
Red Hat and the GPL Posted Mar 9, 2011 21:03 UTC (Wed) by sepreece (subscriber, #19270) [Link]
"3. The GPL requires RedHat to share the source of the final product that is distributed with those it distributes to. Those receiving that source can use common GNU tools for building patches themselves, though this will not help them understand much about why the differences are there."
Minor caveat: This is true IFF the files have diligently been marked up, as required by the license, with the nature of the changes made to them in each successive change and all of those markings (if there are multiple changes in a file) have been preserved. If, as is often the case, that information is only in the changelog, then you can't reconstruct the successive patches, but only a single patch that applies the net result of the whole sequence of changes to a particular file.
Red Hat and the GPL Posted Mar 9, 2011 22:05 UTC (Wed) by RogerOdle (subscriber, #60791) [Link]
In regards to the GPL, the only requirement I can see to report changes to the source is
"5. Conveying Modified Source Versions.
and optional requirement
"7. Additional Terms.
Neither of these imposes an obligation to provide detailed accounting of changes or to produce patches.
The only GPL requirement that I can see is to produce the source code that is necessary to build the binary product.
If there is a patch requirement then it is by agreement outside of the GPL. This does not mean that a source distribution requirement can not be satisfied by distributing a patch. It is probably more efficient to do so. But I do not see that as a legal requirement.
If you can find a legal requirement in the GPL to produce patches then please show us. Let us try to avoid creating opportunities for FUD by declaring obligations that aren't there.
I am uncomfortable with implied obligations in contracts. If you think patch reporting is an important enough of a burden to impose on developers then ask the community to add it to the next version of the GPL in an unambiguous manner. I think this is just opening a can of worms.
Red Hat and the GPL Posted Mar 9, 2011 22:14 UTC (Wed) by corbet (editor, #1) [Link] You are looking at GPLv3! Given that the context here is the kernel, you really need to be looking at GPLv2.
Red Hat and the GPL Posted Mar 9, 2011 22:59 UTC (Wed) by pebolle (guest, #35204) [Link]
> Given that the context here is the kernel, you really need to be looking at GPLv2.
Though, if one is discussing a problem with GPLv2 one might look at the GPLv3 to see if, and how, the author of the GPLv2 (the FSF) tried to solve that specific problem in the GPLv3. So it could provide reasons for a certain interpretation of the GPLv2.
Red Hat and the GPL Posted Mar 10, 2011 1:34 UTC (Thu) by branden (subscriber, #7029) [Link]
Mr. Corbet is spot-on here.
Linus Torvalds quite deliberately chose to go with version 2 of the GNU GPL, and not any other version. Certainly not "any later version, as published by the Free Software Foundation".
It'd be a funny old world if this matter ended up in court and the judge accepted RMS as an expert witness to expound upon the rationale behind the GNU GPL, while refusing to hear from Linus Torvalds, the leading copyright holder in the work in question.
(N.B., for all I know, Linus is 100% cool with Red Hat's move. If the TiVo lockdown didn't bother him, I don't know what would.)
Red Hat and the GPL Posted Mar 11, 2011 17:31 UTC (Fri) by dwmw2 (subscriber, #2063) [Link] GPLv2 actually requires more here than GPLv3. Although GPLv3 only requires the work as a whole to carry a prominent notice that you modified it, GPLv2 requires it of individual modified files:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
Distributing the original source plus the patches would meet this requirement, at least in spirit although perhaps one could argue that for the modified files to carry prominent notices you'd actually have to insert obnoxious comments into the files themselves, rather than providing that information "out-of-band" in the patch set.
Red Hat and the GPL Posted Mar 18, 2011 19:06 UTC (Fri) by mishad (guest, #69757) [Link]
> Although GPLv3 only requires the work as a whole to carry a prominent notice that you modified it, GPLv2 requires it of individual modified files:
Does that mean that GPLv2 is incompatible with GPLv3.?
That is, that GPLv2 code cannot be incorporated into a GPLv3 derived work, because of the "no additional restrictions" clause?
Surely not?
Red Hat and the GPL Posted Mar 18, 2011 19:24 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]
Yes, it does mean precisely that. Unless a codebase is licensed under GPLv2 or later, it typically cannot be incorporated with GPLv3 code.
http://fedoraproject.org/wiki/Licensing:Main#GPL_Compatib...
Red Hat and the GPL Posted Mar 12, 2011 20:37 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
my issue on this topic is around your point #2
RedHat _does_ distrbute the patches as separate items, but only to people who get a redhat support contract (no problem so far), and only under the condition that they don't redistribute the patches (under penalty of having their support contract terminated). It's this "don't redistribute" portion that I have a problem with
This means that anyone distributing GPL code is in violation of the GPL Posted Mar 9, 2011 17:17 UTC (Wed) by southey (subscriber, #9466) [Link] The preferred form argument sounds just plain silly as if you fail to provide the source code in all conceivable ways including different encodings (such as ansci vs unicode) then you must be in violation of the GPL V2 because someone needs something different (or just is being difficult like wanting a new tablet)!You should be arguing that Red Hat is providing foremost an executable not source code because RHEL is not Gentoo or some other distro that requires you to build from source. So Red Hat is correctly meeting the part of GPL v2 section 3 is For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable (my emphasis added). This says complete code not partial code so Red Hat is now fulfilling that requirement better than just distributing original source plus patches - especially if those patches lack complete instructions on modifying the original (such as dependencies). If RHEL sources contain valid copyright statements involving Red Hat, then Red Hat must be complying with Section 2. Unfortunately the GPL V2 (or V3) only specifies date not the format or standard for representation. So just the year alone is marginally valid date, even if it really means all days in the complete year. Also you can argue that a specific day (a more common usage) is inappropriate for something that involves many days of work as it includes finding and testing final changes. Also you forgetting one critical aspect in the Trading GPL rights for support part (which I tend to agree with): If Red Hat owns the copyrights of those changes (and it does contribute a lot to the kernel) then it can distribute those patches or code under whatever terms it likes! So for those parts that Red Hat, there is no GPL violation at all. Thus, Red Hat would be in violation of any changes that it does not own and, as you point out, any GPL rights are likely removed by the support agreement (as EULAs are apparently valid).
This means that anyone distributing GPL code is in violation of the GPL Posted Mar 10, 2011 11:15 UTC (Thu) by paulj (subscriber, #341) [Link]
No one discussing the preferred form has argued that it means distributors must provide whatever arcane form any user wants (and by extension, provide all possible arcane forms), other than those erecting straw-men. If that's what you believe some people have seriously argued that that is what preferred form means, then you likely have gone out of your way to misunderstand them.
This means that anyone distributing GPL code is in violation of the GPL Posted Mar 10, 2011 15:18 UTC (Thu) by southey (subscriber, #9466) [Link]
That's makes no sense - just see the comments where people wanting access to an actual git repository. The floppy drive and even the pure CD-ROM drive are essentially arcane, I still have essentially unused computers with these so I should be able to ask for source code on a floppy or cd-rom as that my 'preferred form' for those computers but I need online access for day to day computers.
I am not misunderstanding, just pointing out the stupidity of that line of argument because the GPL does not go into any definition of it. So if the 'preferred form' of source is patches, then we must always get the original plus all patches. Of course that means no distributed revision control systems such as git for distribution. (Yes I know git can create and apply patches but it is more correct just to push and pull.)
This means that anyone distributing GPL code is in violation of the GPL Posted Mar 10, 2011 15:57 UTC (Thu) by paulj (subscriber, #341) [Link]
Actually, the GPL does say you should be able to get source on a "medium customarily used for software interchange", which floppies may once have satisfied. Note that your individual situation doesn't alone determine it.
However, we're discussing a different part of the GPL.
If the preferred form were original plus patches, than that's indeed what would have to be distributed, as you say. I don't see how that means git can't be used though. Indeed, a git repository made available IS a form of distribution, just as much as placing a tarball in a folder accessible via HTTP is (some people have argued a git repo is "content storage", and hence somehow different to distribution, which seems an incorrectly restrictive view) - indeed, the git repository is a much BETTER form of distribution.
Another important point. Preferences are perfectly capable of changing, particularly as technology does. Just because 10+ years ago the vast majority of developers preferred to trade big tarballs of the source, with history restricted to a ChangeLog file, does not mean that they prefer it today. As the state of the art in SCMs changed, developers/maintainers now tend to use the likes of 'git pull' rather than ftp'ing a tarball from tsx-11 or sunsite (or buying a walnut creek CD set).
Just as floppies today almost certainly no longer meet the "custom medium" requirement because of change, even though they once did, so it is perfectly possible for source form requirements to evolve from tarballs to a git repo. The habits and expectations of GPL software developers/maintainers do not have to be static.
Note Carefully: Even if that were so, that does NOT mean all GPL projects would HAVE TO all switch from tarballs to (e.g.) git repos together. It's perfectly possible for different communities and different projects to have different standards for preferred forms of sources.
The problem with what RedHat have done is that it's difficult for anyone to argue with a straight face that kernel developers prefer not to have the history *today* (that Linus once distributed only tarballs is somewhat irrelevant, when he's been distributing full history with releases for at least a decade - note that the GPL does NOT require that the format for the history be itself in a non-proprietary format).
Note Carefully 2: No one person can say what the preferred form is. It presumably depends on consensus.
This means that anyone distributing GPL code is in violation of the GPL Posted Mar 10, 2011 16:37 UTC (Thu) by branden (subscriber, #7029) [Link]
Yes. This.
The "preferred form for modification" varies in time and space.
We know what the preferred form for the Linux kernel is because major distributors like Debian and--until recently--Red Hat supplied it.
This means that anyone distributing GPL code is in violation of the GPL Posted Mar 10, 2011 17:18 UTC (Thu) by paulj (subscriber, #341) [Link]
And can vary between upstream development and vendor packagers. Preferred form can be a tarball for one, and tarball+patches for the other, in theory.
Course, wrt Linux, if *all* the kernel copyright holders don't have a problem with packagers not distributing the history of their fork, then there's not a problem.
This means that anyone distributing GPL code is in violation of the GPL Posted Mar 10, 2011 21:39 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]
> If Red Hat owns the copyrights of those changes (and it does contribute
> a lot to the kernel) then it can distribute those patches or code under > whatever terms it likes!
not exactly. if their changes are considered as derived work from linux, then the GPL controls what they can do with it (namely, distribute it under the GPL). for non-derivative works it's indeed their call. for the kernel specifically it's a somewhat grey area whether one can create a non-derivative work, see all the 'are binary only modules legal' discussions of the past decade or two. based on past RHEL versions (and the RHEL6 beta which did come with patches), the majority if not all of RHEL's modifications fall under the derived work category and therefore RH can distribute them only under the GPL.
GPL3 is much clearer on "preferred form" Posted Mar 9, 2011 18:38 UTC (Wed) by pebolle (guest, #35204) [Link]
From the GPL3 [0]:
> 1. Source Code.
In the GPL3 "preferred form" is used only to distinguish source code from, say, binaries. It is, unsurprisingly, a very broad term. We're talking about something vague like: "computer files with human readable text that can be used to edit programs and can be fed to compilers, interpreters, etc.". It seems very unlikely that "preferred form" can be used to demand rather specific things, like (in this case) individual patches. The GPL3 doesn't go into such details. And, I'd say, neither does the GPL2.
bash Posted Mar 9, 2011 20:21 UTC (Wed) by marcH (guest, #57642) [Link]
> Tarball releases of GPL code are a longstanding tradition in the free software world. Many projects still do it that way and the FSF itself has made releases that way in the past.
... and still does: http://www.gnu.org/software/bash/
bash Posted Mar 9, 2011 20:44 UTC (Wed) by vonbrand (subscriber, #4458) [Link] Great! Let's now go bash the FSF for not complying with GPL then!
bash Posted Mar 9, 2011 21:18 UTC (Wed) by branden (subscriber, #7029) [Link]
Sure. You go right ahead and tell the FSF to sue itself.
bash Posted Mar 9, 2011 23:52 UTC (Wed) by airlied (subscriber, #9104) [Link]
double standard much?
since you aren't suing anybody in here but just bashing Red Hat and claiming uber-GPL knowledge, not sure why you don't feel the need to bash FSF.
bash Posted Mar 10, 2011 1:37 UTC (Thu) by branden (subscriber, #7029) [Link]
It's because the FSF is the copyright holder in their own works. (Not the *sole* copyright holder, but their works are vastly more homogeneous in copyright ownership than the Linux kernel is.)
It is a long established principle that a copyright holder cannot violate the license in his/her/its own work.
Consequently, the copyright holder can distribute the "source" of a GPLed work of theirs in any form they wish, or not at all.
Red Hat is not in this position with respect to the Linux kernel.
Does that clear things up?
(I swear--people don't read my long posts, and don't understand the short ones.)
bash Posted Mar 10, 2011 1:40 UTC (Thu) by branden (subscriber, #7029) [Link]
To further clarify:
1) The FSF really is the sole copyright holder in bash. I've reviewed its source code many times.
2) The double standard of which you complain is established by Title 17 of the United States Code. Copyright holders enjoy exclusive rights. That's just the way it is.
We could discuss reforming copyright law to be more equitable, but that's out of scope for this thread even by my freeweheeling assessment.
bash Posted Mar 10, 2011 1:42 UTC (Thu) by branden (subscriber, #7029) [Link]
If you want to hear me bash the FSF, just say my name (I'm like the devil and appear when thus summoned) next time LWN covers the GNU FDL.
Red Hat and the GPL Posted Mar 9, 2011 22:23 UTC (Wed) by jondkent (guest, #19595) [Link]
omg, everyone here is a lawyer all of a sudden, quoting their own understanding (or not) of the GPL, or what they wish it was, which I think is the main issue.
I'm not going to pretend I understand the GPL fully enough to comment (and wish other would do so), but I'll comment on the negative emotion going on here. Step back and look at what is actually happening here.
- are Red Hat stopping committing upstream - no
so what on earth is the issue here? Do not mention the GPL, that is _not_ an issue.
Red Hat and the GPL Posted Mar 9, 2011 22:50 UTC (Wed) by foom (subscriber, #14868) [Link]
The issue is that a kernel developer for Debian (Maximilian Attems) and the upstream stable kernel maintainer (Greg Kroah-Hartman) complained about RH's behavior, and that it made their work (maintaining a 2.6.32 stable kernel that is not based on RHEL's) more difficult.
Red Hat and the GPL Posted Mar 9, 2011 23:26 UTC (Wed) by rahvin (subscriber, #16953) [Link]
So isn't the solution to the problem for Redhat to work directly with those developers to ease their concerns, possibly by even giving them free support access that grants them access to Redhat's information rather than complaining that they violate some term of the GPL that someone is defining however they would like?
I can understand the developers complaint and I can understand the community anger at the change. But I won't ever understand someone trying to redefine the GPL to imply that whatever work flow they prefer to use is the only valid form of compliance. RMS defined numerous times what that clause means, that is the definition that applies unless you want to write your own license.
Red Hat and the GPL Posted Mar 10, 2011 1:08 UTC (Thu) by foom (subscriber, #14868) [Link]
I completely agree with you. I think the whole "Is it or isn't it a GPL Violation?" discussion is a huge distraction from the actual issue.
Red Hat and the GPL Posted Mar 10, 2011 9:41 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]
> - are Red Hat stopping committing upstream - no
nothing to do with the RHEL6 srpm.
> - are Red Hat refusing to work with other devs - no
nothing to do with the RHEL6 srpm.
> - are Red Hat trying to protect their business - yes
nothing to do with the RHEL6 srpm.
> - does this really affect other distros - no;
yes it does (you could have inferred that from all the complaints of said 'other distros'). and more than just 'distros' (there're many in-house 'distros' too that every now and then take a look at what RHEL has, e.g., for backports of security fixes, etc).
> they do not use rhel kernel, at least not the rhel ripoffs
childish namecalling doesn't help your cause. i know, i just did it too.
> - do you want to use a rhel kernel - no;
strawman. if you put it this way: "do you want to use PARTS OF a rhel kernel" then you're getting closer to understanding the issue.
> they are very old and have little in common with the vanilla tree
RHEL6 (the topic of this whole discussion) is anything but 'very old'. and it has a lot in common with the vanilla tree, not the least because of RH's own effort to send upstream as many bits and pieces as possible.
just publish the git tree Posted Mar 9, 2011 22:51 UTC (Wed) by jone (guest, #62596) [Link]
I could care less if RH splits out all the patches into cute little patch files to make it harder for Centos, SL, OEL, or pick your favorite RHEL compat vendor to create a duplicate or slightly modified kernel with the RH generated rpmbuild system .. I just want to know what they are in their tree - so I'd argue (particularly since the RHEL kernels tend to be in heavy use) that the generated git trees should really be in kernel.org and if they really are pushing upstream (where some of their developers already live) they should have a for-linus merge branch against their entire tree .. why I see this as important has less to do with the contributed patchsets themselves but more to do with the integration point necessary for many 3rd party products - there's a larger infrastructure here that's in danger of collapse if RH starts closing it's doors out of competitive fear
now intentionally obfuscating the commit logs if that rumor is true .. is another matter altogether
Red Hat and the GPL Posted Mar 26, 2011 7:59 UTC (Sat) by triclone (guest, #73879) [Link]
Ran out of popcorn and ended up eating my own fingers. I foresee more specific details in future developments of the GPL. Up next: "Are Christians really following the Bible?". I apologize for sounding ignorant (because I am), but through this post and replies I have learned a lot of things. My greatest admiration and thanks for all the people that participate. This time I got more meat than I dreamed of. =)
|
|||||||||||||