Red Hat and the GPL
The 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 form
While 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 support
While 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.
Posted Mar 9, 2011 0:33 UTC (Wed)
by pranith (subscriber, #53092)
[Link] (3 responses)
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.
Posted Mar 9, 2011 0:49 UTC (Wed)
by mbanck (guest, #9035)
[Link] (2 responses)
If a competitor does this, they might even consider suing for trade secret espionage, cf. Oracle vs. SAP for something apparently slightly similar.
Posted Mar 9, 2011 14:26 UTC (Wed)
by vonbrand (guest, #4458)
[Link] (1 responses)
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.
Posted Mar 9, 2011 22:13 UTC (Wed)
by jrn (subscriber, #64214)
[Link]
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.
Posted Mar 9, 2011 4:17 UTC (Wed)
by gmaxwell (guest, #30048)
[Link] (7 responses)
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.
Posted Mar 9, 2011 5:13 UTC (Wed)
by butlerm (subscriber, #13312)
[Link] (5 responses)
Unless 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.
Posted Mar 9, 2011 5:27 UTC (Wed)
by gmaxwell (guest, #30048)
[Link] (4 responses)
Posted Mar 9, 2011 6:36 UTC (Wed)
by butlerm (subscriber, #13312)
[Link] (3 responses)
I 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.
Posted Mar 9, 2011 9:00 UTC (Wed)
by khim (subscriber, #9252)
[Link] (2 responses)
You mean routers? Yes, they are distributed in such form. And most (if not all) are pushing limits if not outright violationg GPL. 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.
Posted Mar 9, 2011 20:22 UTC (Wed)
by sepreece (guest, #19270)
[Link]
Posted Mar 10, 2011 1:14 UTC (Thu)
by butlerm (subscriber, #13312)
[Link]
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.
Posted Mar 9, 2011 5:20 UTC (Wed)
by branden (guest, #7029)
[Link]
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
Posted Mar 9, 2011 5:05 UTC (Wed)
by branden (guest, #7029)
[Link] (35 responses)
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...)
Posted Mar 9, 2011 5:37 UTC (Wed)
by frnknstn (guest, #68647)
[Link] (10 responses)
If that is true, then supplying preprocessed source code is supplying partially compiled source code, and thus insufficient for GPL compliance.
Posted Mar 9, 2011 5:48 UTC (Wed)
by branden (guest, #7029)
[Link] (9 responses)
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.
Posted Mar 9, 2011 10:39 UTC (Wed)
by AlexHudson (guest, #41828)
[Link] (6 responses)
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.
Posted Mar 9, 2011 16:28 UTC (Wed)
by MisterIO (guest, #36192)
[Link] (5 responses)
Posted Mar 9, 2011 20:31 UTC (Wed)
by branden (guest, #7029)
[Link] (4 responses)
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.
Posted Mar 9, 2011 21:17 UTC (Wed)
by jake (editor, #205)
[Link] (3 responses)
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
Posted Mar 9, 2011 21:43 UTC (Wed)
by branden (guest, #7029)
[Link] (2 responses)
"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!
Posted Mar 9, 2011 21:56 UTC (Wed)
by corbet (editor, #1)
[Link] (1 responses)
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.
Posted Mar 10, 2011 0:43 UTC (Thu)
by branden (guest, #7029)
[Link]
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.
Posted Mar 9, 2011 14:00 UTC (Wed)
by samth (guest, #1290)
[Link] (1 responses)
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.
Posted Mar 9, 2011 20:36 UTC (Wed)
by branden (guest, #7029)
[Link]
You might as well just call me names, man--it would save time.
Posted Mar 9, 2011 13:12 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link]
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.
Posted Mar 9, 2011 14:55 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (17 responses)
Posted Mar 9, 2011 21:05 UTC (Wed)
by branden (guest, #7029)
[Link] (16 responses)
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.
Posted Mar 9, 2011 23:11 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (15 responses)
Posted Mar 10, 2011 0:54 UTC (Thu)
by branden (guest, #7029)
[Link] (14 responses)
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.
Posted Mar 10, 2011 1:24 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (13 responses)
Posted Mar 10, 2011 1:53 UTC (Thu)
by branden (guest, #7029)
[Link] (12 responses)
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.
Posted Mar 10, 2011 2:03 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (11 responses)
Posted Mar 10, 2011 3:05 UTC (Thu)
by branden (guest, #7029)
[Link] (10 responses)
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?
Posted Mar 10, 2011 3:20 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (9 responses)
Posted Mar 10, 2011 16:34 UTC (Thu)
by branden (guest, #7029)
[Link] (8 responses)
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.
Posted Mar 10, 2011 16:37 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (1 responses)
Posted Mar 10, 2011 23:34 UTC (Thu)
by branden (guest, #7029)
[Link]
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?
Posted Mar 10, 2011 16:38 UTC (Thu)
by gregkh (subscriber, #8)
[Link] (5 responses)
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.
Posted Mar 10, 2011 23:39 UTC (Thu)
by branden (guest, #7029)
[Link] (1 responses)
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.
Posted Mar 13, 2011 2:06 UTC (Sun)
by vonbrand (guest, #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.
Posted Mar 11, 2011 9:25 UTC (Fri)
by PaXTeam (guest, #24616)
[Link] (2 responses)
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?
Posted Mar 11, 2011 16:45 UTC (Fri)
by gregkh (subscriber, #8)
[Link] (1 responses)
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.
Posted Mar 11, 2011 22:43 UTC (Fri)
by PaXTeam (guest, #24616)
[Link]
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?
Posted Mar 9, 2011 20:31 UTC (Wed)
by sepreece (guest, #19270)
[Link] (4 responses)
Posted Mar 9, 2011 20:58 UTC (Wed)
by branden (guest, #7029)
[Link] (3 responses)
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.
Posted Mar 10, 2011 10:28 UTC (Thu)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
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.
Posted Mar 10, 2011 23:46 UTC (Thu)
by branden (guest, #7029)
[Link] (1 responses)
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.
Posted Mar 11, 2011 8:32 UTC (Fri)
by pbonzini (subscriber, #60935)
[Link]
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 [email protected] on their patches, but it's possible that: a) they sometimes forget; b) they cherry-pick patches by authors who didn't Cc [email protected]. 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.
Posted Mar 9, 2011 5:26 UTC (Wed)
by ccurtis (guest, #49713)
[Link] (1 responses)
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.
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.
Posted Mar 9, 2011 7:11 UTC (Wed)
by juliank (guest, #45896)
[Link]
Posted Mar 9, 2011 10:06 UTC (Wed)
by dark (guest, #8483)
[Link] (6 responses)
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.
Posted Mar 9, 2011 10:19 UTC (Wed)
by airlied (subscriber, #9104)
[Link] (1 responses)
Its a fork of the Linus kernel and is maintained nearly the same way, no rebase, linear development.
Posted Mar 9, 2011 10:50 UTC (Wed)
by dark (guest, #8483)
[Link]
Posted Mar 9, 2011 10:38 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link] (3 responses)
Yes, at least in the case of the kernel. Other packages may be handled differently.
Posted Mar 9, 2011 14:37 UTC (Wed)
by vonbrand (guest, #4458)
[Link] (2 responses)
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.
Posted Mar 9, 2011 21:10 UTC (Wed)
by branden (guest, #7029)
[Link] (1 responses)
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.
Posted Mar 9, 2011 21:36 UTC (Wed)
by dark (guest, #8483)
[Link]
However this doesn't seem to apply to the RHEL kernel so it's just hypothetical.
Posted Mar 9, 2011 10:36 UTC (Wed)
by giggls (subscriber, #48434)
[Link]
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.
Posted Mar 9, 2011 10:49 UTC (Wed)
by paulj (subscriber, #341)
[Link] (48 responses)
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.
Posted Mar 9, 2011 10:54 UTC (Wed)
by gevaerts (subscriber, #21521)
[Link] (45 responses)
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"
Posted Mar 9, 2011 11:31 UTC (Wed)
by paulj (subscriber, #341)
[Link] (40 responses)
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.
Posted Mar 9, 2011 12:58 UTC (Wed)
by gevaerts (subscriber, #21521)
[Link] (4 responses)
Posted Mar 9, 2011 13:17 UTC (Wed)
by paulj (subscriber, #341)
[Link] (3 responses)
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..
Posted Mar 9, 2011 13:35 UTC (Wed)
by gevaerts (subscriber, #21521)
[Link] (2 responses)
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.
Posted Mar 9, 2011 13:59 UTC (Wed)
by paulj (subscriber, #341)
[Link] (1 responses)
Posted Mar 9, 2011 20:43 UTC (Wed)
by sepreece (guest, #19270)
[Link]
Doesn't seem, to me, to be a question that has a single answer.
Posted Mar 9, 2011 13:14 UTC (Wed)
by Los__D (guest, #15263)
[Link] (34 responses)
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.
Posted Mar 9, 2011 13:24 UTC (Wed)
by ewan (guest, #5533)
[Link] (32 responses)
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.
Posted Mar 9, 2011 14:01 UTC (Wed)
by Los__D (guest, #15263)
[Link] (31 responses)
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.
Posted Mar 9, 2011 14:16 UTC (Wed)
by ewan (guest, #5533)
[Link] (30 responses)
We're talking about the source code for a binary RPM. The preferred form of the source for the RPM is all that matters.
Again, the preferred form for making modifications is the raw source
That's a non-sequitur. Clearly what is required is 'the source'. The entire intent of the 'preferred form for modification' wording is to address the question of what counts as 'the source'. I think everyone agrees that a tarball of machine generated pre-processor output is not 'the source', even though it can be compiled to a binary.
If you have a build system that starts with a single tarball and works from there then that single tarball may indeed be 'the source'. If you have a build system that starts from a pristine upstream tarball and a pile of patches, then it's reasonable to say that the pristine upstream tarball and the pile of patches together form 'the source'.
It appears Red Hat's build process does still involve a pristine upstream and a pile of patches since they're making the patches available to customers. If that's the case, then the collapsed single tarball is just as much a machine-generated intermediate stage as pre-processor output would be.
Posted Mar 9, 2011 14:50 UTC (Wed)
by Los__D (guest, #15263)
[Link] (29 responses)
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".
Posted Mar 9, 2011 15:18 UTC (Wed)
by ewan (guest, #5533)
[Link] (28 responses)
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.
Posted Mar 9, 2011 15:52 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (26 responses)
Posted Mar 9, 2011 16:00 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (1 responses)
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!
Posted Mar 9, 2011 22:56 UTC (Wed)
by jone (guest, #62596)
[Link]
Posted Mar 9, 2011 16:12 UTC (Wed)
by avik (guest, #704)
[Link]
Posted Mar 9, 2011 17:09 UTC (Wed)
by ewan (guest, #5533)
[Link] (22 responses)
Posted Mar 9, 2011 17:11 UTC (Wed)
by ewan (guest, #5533)
[Link]
Posted Mar 9, 2011 17:20 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (20 responses)
Posted Mar 9, 2011 17:26 UTC (Wed)
by ewan (guest, #5533)
[Link] (1 responses)
Posted Mar 10, 2011 10:31 UTC (Thu)
by pbonzini (subscriber, #60935)
[Link]
Posted Mar 9, 2011 17:30 UTC (Wed)
by paulj (subscriber, #341)
[Link] (17 responses)
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?
Posted Mar 9, 2011 17:34 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (12 responses)
Posted Mar 9, 2011 17:44 UTC (Wed)
by paulj (subscriber, #341)
[Link]
Posted Mar 9, 2011 21:14 UTC (Wed)
by branden (guest, #7029)
[Link] (1 responses)
You cannot violate the copyright license in your own work.
Posted Mar 9, 2011 22:47 UTC (Wed)
by Los__D (guest, #15263)
[Link]
Posted Mar 9, 2011 21:46 UTC (Wed)
by branden (guest, #7029)
[Link] (4 responses)
Posted Mar 9, 2011 23:21 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (3 responses)
Posted Mar 10, 2011 1:22 UTC (Thu)
by branden (guest, #7029)
[Link] (1 responses)
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.
Posted Mar 10, 2011 10:38 UTC (Thu)
by pbonzini (subscriber, #60935)
[Link]
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.
Posted Mar 10, 2011 10:00 UTC (Thu)
by paulj (subscriber, #341)
[Link]
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.
Posted Mar 10, 2011 11:24 UTC (Thu)
by dwmw2 (subscriber, #2063)
[Link] (3 responses)
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.
Posted Mar 10, 2011 12:47 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (1 responses)
Posted Mar 10, 2011 14:43 UTC (Thu)
by paulj (subscriber, #341)
[Link]
Posted Mar 10, 2011 18:48 UTC (Thu)
by martinfick (subscriber, #4455)
[Link]
Posted Mar 9, 2011 23:03 UTC (Wed)
by rahvin (guest, #16953)
[Link] (3 responses)
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.
Posted Mar 10, 2011 1:23 UTC (Thu)
by branden (guest, #7029)
[Link]
Posted Mar 10, 2011 3:03 UTC (Thu)
by ewan (guest, #5533)
[Link] (1 responses)
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.
Posted Mar 18, 2011 18:48 UTC (Fri)
by mishad (guest, #69757)
[Link]
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.
Posted Mar 9, 2011 16:04 UTC (Wed)
by Los__D (guest, #15263)
[Link]
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.
Posted Mar 9, 2011 17:22 UTC (Wed)
by paulj (subscriber, #341)
[Link]
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).
Posted Mar 9, 2011 14:05 UTC (Wed)
by clugstj (subscriber, #4020)
[Link]
Posted Mar 9, 2011 14:59 UTC (Wed)
by vonbrand (guest, #4458)
[Link] (2 responses)
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.
Posted Mar 9, 2011 17:38 UTC (Wed)
by paulj (subscriber, #341)
[Link] (1 responses)
(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).
Posted Mar 9, 2011 20:33 UTC (Wed)
by vonbrand (guest, #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.
Posted Mar 9, 2011 20:20 UTC (Wed)
by vonbrand (guest, #4458)
[Link] (1 responses)
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.
Posted Mar 18, 2011 18:55 UTC (Fri)
by mishad (guest, #69757)
[Link]
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.
Posted Mar 9, 2011 10:51 UTC (Wed)
by wingo (guest, #26929)
[Link] (1 responses)
The GPL says:
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.
Posted Mar 9, 2011 15:23 UTC (Wed)
by __alex (guest, #38036)
[Link]
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.
Posted Mar 9, 2011 11:01 UTC (Wed)
by dwmw2 (subscriber, #2063)
[Link] (16 responses)
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."
Posted Mar 9, 2011 11:42 UTC (Wed)
by paulj (subscriber, #341)
[Link] (9 responses)
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?
Posted Mar 9, 2011 20:37 UTC (Wed)
by vonbrand (guest, #4458)
[Link] (8 responses)
Nope, that is just the typical way forks that intend to track upstream are handled internally.
Posted Mar 9, 2011 20:41 UTC (Wed)
by dwmw2 (subscriber, #2063)
[Link] (7 responses)
Posted Mar 9, 2011 23:12 UTC (Wed)
by rahvin (guest, #16953)
[Link] (6 responses)
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.
Posted Mar 10, 2011 1:30 UTC (Thu)
by branden (guest, #7029)
[Link] (5 responses)
" 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.
Posted Mar 10, 2011 3:11 UTC (Thu)
by branden (guest, #7029)
[Link] (4 responses)
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.
Posted Mar 11, 2011 1:00 UTC (Fri)
by rahvin (guest, #16953)
[Link] (3 responses)
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.
Posted Mar 11, 2011 9:51 UTC (Fri)
by PaXTeam (guest, #24616)
[Link] (2 responses)
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?
Posted Mar 11, 2011 18:14 UTC (Fri)
by rahvin (guest, #16953)
[Link] (1 responses)
Posted Mar 11, 2011 22:35 UTC (Fri)
by PaXTeam (guest, #24616)
[Link]
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.
Posted Mar 9, 2011 12:56 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link] (1 responses)
Note that the GPL is incompatible with licenses that mandate distribution of forks as a patch or series of patches (like the gnuplot license).
Posted Mar 9, 2011 14:57 UTC (Wed)
by dwmw2 (subscriber, #2063)
[Link]
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.
Posted Mar 9, 2011 17:25 UTC (Wed)
by pebolle (guest, #35204)
[Link] (3 responses)
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?
Posted Mar 9, 2011 18:19 UTC (Wed)
by dwmw2 (subscriber, #2063)
[Link] (2 responses)
Posted Mar 9, 2011 19:05 UTC (Wed)
by pebolle (guest, #35204)
[Link] (1 responses)
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".
Posted Mar 9, 2011 20:08 UTC (Wed)
by dwmw2 (subscriber, #2063)
[Link]
Posted Mar 9, 2011 16:56 UTC (Wed)
by RogerOdle (subscriber, #60791)
[Link] (13 responses)
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.
Posted Mar 9, 2011 17:00 UTC (Wed)
by corbet (editor, #1)
[Link] (3 responses)
Posted Mar 9, 2011 17:47 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Mar 9, 2011 21:44 UTC (Wed)
by RogerOdle (subscriber, #60791)
[Link] (1 responses)
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.
Posted Mar 9, 2011 21:58 UTC (Wed)
by corbet (editor, #1)
[Link]
From the license text:
(Emphasis added). Seems pretty clear to me...
Posted Mar 9, 2011 21:03 UTC (Wed)
by sepreece (guest, #19270)
[Link] (7 responses)
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.
Posted Mar 9, 2011 22:05 UTC (Wed)
by RogerOdle (subscriber, #60791)
[Link] (6 responses)
"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.
Posted Mar 9, 2011 22:14 UTC (Wed)
by corbet (editor, #1)
[Link] (5 responses)
Posted Mar 9, 2011 22:59 UTC (Wed)
by pebolle (guest, #35204)
[Link] (1 responses)
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.
Posted Mar 10, 2011 1:34 UTC (Thu)
by branden (guest, #7029)
[Link]
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.)
Posted Mar 11, 2011 17:31 UTC (Fri)
by dwmw2 (subscriber, #2063)
[Link] (2 responses)
Posted Mar 18, 2011 19:06 UTC (Fri)
by mishad (guest, #69757)
[Link] (1 responses)
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?
Posted Mar 18, 2011 19:24 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Mar 12, 2011 20:37 UTC (Sat)
by dlang (guest, #313)
[Link]
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
Posted Mar 9, 2011 17:17 UTC (Wed)
by southey (guest, #9466)
[Link] (6 responses)
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).
Posted Mar 10, 2011 11:15 UTC (Thu)
by paulj (subscriber, #341)
[Link] (4 responses)
Posted Mar 10, 2011 15:18 UTC (Thu)
by southey (guest, #9466)
[Link] (3 responses)
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.)
Posted Mar 10, 2011 15:57 UTC (Thu)
by paulj (subscriber, #341)
[Link] (2 responses)
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.
Posted Mar 10, 2011 16:37 UTC (Thu)
by branden (guest, #7029)
[Link] (1 responses)
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.
Posted Mar 10, 2011 17:18 UTC (Thu)
by paulj (subscriber, #341)
[Link]
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.
Posted Mar 10, 2011 21:39 UTC (Thu)
by PaXTeam (guest, #24616)
[Link]
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.
Posted Mar 9, 2011 18:38 UTC (Wed)
by pebolle (guest, #35204)
[Link]
> 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.
Posted Mar 9, 2011 20:21 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (7 responses)
... and still does: http://www.gnu.org/software/bash/
Posted Mar 9, 2011 20:44 UTC (Wed)
by vonbrand (guest, #4458)
[Link] (6 responses)
Great! Let's now go bash the FSF for not complying with GPL then!
Posted Mar 9, 2011 21:18 UTC (Wed)
by branden (guest, #7029)
[Link] (4 responses)
Posted Mar 9, 2011 23:52 UTC (Wed)
by airlied (subscriber, #9104)
[Link] (3 responses)
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.
Posted Mar 10, 2011 1:37 UTC (Thu)
by branden (guest, #7029)
[Link]
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.)
Posted Mar 10, 2011 1:40 UTC (Thu)
by branden (guest, #7029)
[Link]
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.
Posted Mar 10, 2011 1:42 UTC (Thu)
by branden (guest, #7029)
[Link]
Posted Mar 9, 2011 22:23 UTC (Wed)
by jondkent (guest, #19595)
[Link] (4 responses)
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.
Posted Mar 9, 2011 22:50 UTC (Wed)
by foom (subscriber, #14868)
[Link] (2 responses)
Posted Mar 9, 2011 23:26 UTC (Wed)
by rahvin (guest, #16953)
[Link] (1 responses)
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.
Posted Mar 10, 2011 1:08 UTC (Thu)
by foom (subscriber, #14868)
[Link]
Posted Mar 10, 2011 9:41 UTC (Thu)
by PaXTeam (guest, #24616)
[Link]
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.
Posted Mar 9, 2011 22:51 UTC (Wed)
by jone (guest, #62596)
[Link]
now intentionally obfuscating the commit logs if that rumor is true .. is another matter altogether
Posted Mar 26, 2011 7:59 UTC (Sat)
by triclone (guest, #73879)
[Link]
Red Hat and the GPL
which will not enable me to get any more future updates for that subscription.
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
like extensions to the kernel with proprietary binary blobs
Red Hat and the GPL
Red Hat and the GPL
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
Red Hat and the GPL
You mean routers?
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.
You mean routers?
To claim that WiFi driver and GPLed kernel are "mere aggregation" in this case you must do a lot of squinting.
You mean routers?
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
> weakened, rather than strengthened, the argument he wanted to make
Red Hat and the GPL
Red Hat and the GPL
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 and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
linux-source-2.6.32 - Linux kernel source for version 2.6.32 with Debian patches
[...]
NOTICE: 'linux-2.6' packaging is maintained in the 'Svn' version control system at:
svn://svn.debian.org/svn/kernel/dists/sid/linux-2.6/
[...]
$ cd linux-2.6-2.6.32/debian/patches
$ ls
bugfix debian features series
$ find -name "*.patch" | wc -l
1024
$ find -name "*.patch" | xargs du -ch | tail -n 1
37M total
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
>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
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
patch from Red Hat to figure out what patches should be applied.
kernel patch in these days, and the work should be thanked. It has
no relevance on my opinion of what Red Hat is doing here.
>> format[...]
>
> now imagine if *everyone* else followed suit, where would that leave Linux
> development? is that the future you envision?
If the upstream development procedure changed to be this way, then that
would be a different conversation and topic. But as it is, it has no
relevance at all here.
Red Hat and the GPL
> kernel patch in these days, and the work should be thanked.
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
> 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.
Red Hat and the GPL
Red Hat and the GPL
>
> Please be more precise. What is being made harder?
>
> 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
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
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.
Red Hat and the GPL
Well in that case I see no GPL issue with distributing the latest version as a single tarball.
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
git rebase make that the preferred form for the code suddenly isn't a tarball anymore? Or is they used some other form of VCS, where the end result is always the result of weawing together a changing set of patches?Red Hat and the GPL
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.
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
completely irrelevant, just like common patterns for modifying RPMs
Red Hat and the GPL
Red Hat and the GPL
The engineers checks out the source, makes modifications (!!!!) to the checked out source, and checks in their changes.
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
index 53c2115..f11b488 100644
diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index c4017cf..b44bcf6 100644
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
<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
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
> assumed based on second-hand reports in previous LWN discussions. I
> appreciate having my misconceptions punctured.
Red Hat and the GPL
Red Hat and the GPL
"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.
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
This clause exists in the GPL to prevent some company from sending you a printed book of source code.
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
preferred form
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.
preferred form
Preferred form for whom?
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".Preferred form for whom?
Preferred form for whom?
Because we "typically" do things the way we don't prefer to?
Preferred form for whom?
Preferred form for whom?
Preferred form for whom?
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,"
Preferred form for whom?
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,"
Preferred form for whom?
Preferred form for whom?
> baring the use of a different license.
Preferred form for whom?
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?
> 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.
> interprets to be their preferred form is the form the licensor has to
> comply with.
> manner that is editable and machine readable.
> responding to Oracle's attempts to destroy them.
> redefine "preferred form" however they would like and what that would do
> to the community.
Preferred form for whom?
> the work for making modifications to it".
> ...
> where the work is a fork or modification of an existing project, the
> situation is very different.
Preferred form for whom?
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.
Preferred form for whom?
> Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software. More precisely, it means that the program's users have the four essential freedoms:
> [...]
> A program is free software if users have all of these freedoms.
Preferred form for whom?
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?
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.Preferred form for whom?
Red Hat and the GPL
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
Not quite
Not quite
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?
Not quite
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.
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...
Red Hat and the GPL
Red Hat and the GPL
a) The work must carry prominent notices stating that you modified it, and giving a relevant date."
c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version;"
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
Red Hat and the GPL
Red Hat and the GPL
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:
Red Hat and the GPL
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
Red Hat and the GPL
Red Hat and the GPL
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)!This means that anyone distributing GPL code is in violation of the GPL
This means that anyone distributing GPL code is in violation of the GPL
This means that anyone distributing GPL code is in violation of the GPL
This means that anyone distributing GPL code is in violation of the GPL
This means that anyone distributing GPL code is in violation of the GPL
This means that anyone distributing GPL code is in violation of the GPL
This means that anyone distributing GPL code is in violation of the GPL
> a lot to the kernel) then it can distribute those patches or code under
> whatever terms it likes!
GPL3 is much clearer on "preferred form"
>
> The source code for a work means the preferred form of the work for making modifications to it. Object code means any non-source form of a work.
bash
bash
bash
bash
bash
bash
bash
Red Hat and the GPL
- are Red Hat refusing to work with other devs - no
- are Red Hat trying to protect their business - yes
- does this really affect other distros - no; they do not use rhel kernel, at least not the rhel ripoffs
- do you want to use a rhel kernel - no; they are very old and have little in common with the vanilla tree
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
Red Hat and the GPL
just publish the git tree
Red Hat and the GPL