Weekly Edition
Return to the Announcements page
| |||||||||||||
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution
Bradley M. Kuhn shares
some thoughts about Red Hat's GPL compliance. "Meanwhile, what people are actually complaining about is that Red Hat RHEL customers have access to better meta-information about why various patches were applied. Some have argued (quite reasonably) that this information is required under GPLv2§2(a), but usually that section has been interpreted to allow a very terse changelog. [Jon] Corbet's original article mentioned that the Red Hat distribution of the kernel named Linux contains no changelog. I see why he said that, because it took me some time to find it myself (and an earlier version of the blog post was therefore incorrect on that point), but the src.rpm file does have what appears to be a changelog embedded in the kernel.spec file. There's also a simple summary as well that in release notes found in a separate src.rpm (in the file called kernel.xml). This material seems sufficient to me to meet the letter-of-the-license compliance for GPLv2§2(a) requirements. I, too, wish the log were a bit more readable and organized, but, again, the debate isn't about whether there's optimal community cooperation going on, but rather whether this distribution complies with the GPL."
(Log in to post comments)
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 12, 2011 4:55 UTC (Sat) by pr1268 (subscriber, #24648) [Link] > This material seems sufficient to me to meet the letter-of-the-license compliance... Yeah, sure, what Red Hat is doing satisfies the letter of the license, but from what I gather from the discussion comments at the three previous articles here on LWN, no one was ever really denying that. Wasn't Tivo complying with the letter of the GPL(v2) also? Not that I'm defending Tivo here. Or Red Hat. I just think that what RH is doing by obfuscating their kernel changes like this is reactionary. But then again, big business sometimes does what it needs for survival...
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 12, 2011 8:45 UTC (Sat) by lambda (subscriber, #40735) [Link] If you read the article linked, you'll see that he does cover the fact that it's an anti-social practice, but that you can't forbid every type of anti-social behavior using a copyright license. He's merely discussing whether the practice meets the letter of the GPLv2, and concludes that it does.
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 12, 2011 9:38 UTC (Sat) by petegn (guest, #847) [Link]
they need kicking back into line simple ..
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 12, 2011 14:57 UTC (Sat) by ovitters (subscriber, #27950) [Link]
I presume they're waiting for some other company to behave socially
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 12, 2011 23:28 UTC (Sat) by vonbrand (subscriber, #4458) [Link] Oh, come on. If FSF wanted to make clear they don't like this behaviour, they could very well have done so (GPLv2's text is mostly a rant on what the license means, so they could have made it clear in GPLv3 or other places long ago).
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 12, 2011 9:21 UTC (Sat) by danieldk (guest, #27876) [Link]
> I have been a bit amazed to watch that so much debate on this has happened around the words of preferred form of the work for making modifications to it from GPLv2§3. In particularly, I can't help chuckling at the esoteric level to which many people believe they can read these words.
People do, because it is terribly vague. A programmer is not a lawyer, but unless you can afford one, a programmer has to read some licenses at some point for new software projects. As a programmer, it is an interpretation one could easily fall for. After all, if I make my software available via git and ask people to fork and issue pull requests, isn't that the preferred form of making modifications to the software?
If one would add a clarification stating "the preferred form is a git repository forking from upstream", would this violate the GPL?
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 12, 2011 9:22 UTC (Sat) by danieldk (guest, #27876) [Link]
Let me restate that: s/would this violate the GPL/is this in conflict with the GPL/
Yes, it would... Posted Mar 12, 2011 10:56 UTC (Sat) by khim (subscriber, #9252) [Link] Oh, sure it violates GPL. Many FSF projects use other VCS systems. The fact that there are git mirrors are irrelevant - they are not "canonical" and can go away at any time. This means such clarification will be "an additional restriction".
Yes, it would... Posted Mar 12, 2011 12:37 UTC (Sat) by danieldk (guest, #27876) [Link]
I am not talking about existing software, but my own software.
Yes, it would... Posted Mar 14, 2011 12:03 UTC (Mon) by mpr22 (subscriber, #60784) [Link] You would certainly have the right to add such a clarification to the licence you apply to your own original work. Whether a court of law would find it to be an enforceable term of the licence in $JURISDICTION is a separate question in respect of which you would be well advised to consult a copyright lawyer for advice. Oh, and telling people what VCS they should use would make you look like a control freak.
Yes, it would... Posted Mar 15, 2011 0:01 UTC (Tue) by rahvin (subscriber, #16953) [Link]
I believe what the poster you were replying to was asking was if you add a definition of "preferred form" does it violate the no additional restrictions clause. Although in general your reply is accurate it doesn't appear to deal with that specific situation and the OP may feel you didn't answer their question.
I'd argue that preferred form is already defined by the license although I'm sure some will disagree based on the previous threads. From the minimal amount of legalese training I've had it's apparent to me that preferred form is already defined in the license, although indirectly. Whether clarifying some additional description of preferred form violates the no additional clauses would be as you say up to the courts of whatever jurisdiction the case is brought to trial. It would take some research on precedents in the US to draw any kind of conclusion on what the ruling would be in the US district courts.
Personally I believe you have a pretty good chance of the courts accepting that additional clarification as long as the licensee is aware of the clarification at the time of license. The key to that would probably adding the definition to the license but the FSF would probably tell you to stop calling it GPL if you did so. Therein lies the major complications of such an action.
Indirectly? Hardly. Posted Mar 16, 2011 15:26 UTC (Wed) by khim (subscriber, #9252) [Link] From the minimal amount of legalese training I've had it's apparent to me that preferred form is already defined in the license, although indirectly. Actually it's not defined there - and this is by design. Times are changing and "preferred form" may change too. For example some systems don't allow you to work with source using text files (lots of BASIC, Logo or Smalltalk systems are like this), some people actually code programs without text files even if they can use them (see here, for example), etc. So no, "prefferred form" is not covered by license - and this is feature, not bug. Still to try to extend "source code" term to mean "git repository contents" is really pushing it. You'll be going not against letter of the license but against many centuries of tradition. Even if you sign the contract which transfers you rights for some artistic creation to other person it rarely (if ever) includes your notes, drafts, etc. These are usually sold separately and are covered by different license. More often then not they are not sold at all, but rather kept private forever (okay, not really forever - usually till the death of author). To claim that "program source code" is unique in this regard you'll need some exceptional justification.
Indirectly? Hardly. Posted Mar 16, 2011 23:24 UTC (Wed) by anselm (subscriber, #2796) [Link] Surely the »preferred form for modifications« of a software package is whatever the upstream developers prefer to work with when making changes to the software package in question, not necessarily what the downstream recipients of the GPL'ed code would prefer to have. Given the choice, a developer from, say, Taiwan would quite probably »prefer« all the comments and identifiers in the source code to be in Chinese, but that doesn't mean you need to translate all your comments and identifiers if somebody from Taiwan asks you for a copy of the source code of your GPL'ed package. In the case of kernel sources, the »preferred form for modifications« is presumably a patched, ready-to-compile source tree. So IMHO there is nothing wrong in principle with Red Hat shipping exactly that, for GPL compliance. Having access to a Git repository that has all the individual changesets and changelog entries is certainly a nice touch but it is by no means indispensable for what the GPL requires that recipients of the code be able to do, namely rebuild the binaries from the corresponding source.
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 12, 2011 18:01 UTC (Sat) by intgr (subscriber, #39733) [Link]
> If one would add a clarification stating "the preferred form is a git
> repository forking from upstream"
This wouldn't prevent anyone from doing what Red Hat did, though.
They could just publish a git repository with a single git commit that combines all the changes they made. And we're back in square one.
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 12, 2011 19:59 UTC (Sat) by iabervon (subscriber, #722) [Link]
In every project I've worked on, the preferred form for making changes is actually files in a filesystem. I've also seen projects where the preferred form is a particular IDE's configuration. Unless you've got a compiler that builds object files out of git and a build process that uses multiple commits to generate the output, git is the medium of transfer, not the form of the work.
That said, you may well have a build process that generates srpms out of git repositories. If you imagine a project whose goal is to package the Linux kernel, and whose developers work to produce a git repository with an "origin" branch and a HEAD, and, in addition to this git repository, they have a build system which produces packages containing an origin tarball, a set of patches, a changelog, and scripts to apply the patches, the git repository is part of their source. On the other hand, the project need not be under the GPL just because the kernel is, any more than the kernel being under the GPL requires compilers that compile it to be under the GPL. And the GPL doesn't mean that I can insist that RMS loan me his computer to work on gcc with.
To my knowledge, there are no distro-maintenance projects that actually function like that, in part because such a project would have a hard time finding a version control system that could handle it; to my knowledge, there aren't any version control systems that handle repositories as revision contents, without getting confused and trying to handle the revision contents of the repositories as the revision contents. In order to keep them straight, metaprojects either aren't stored in revision control, or they track patch series (possibly preparing commits using a version control system applied to the project they package, which may be a common resource or may be individual and not in any way official).
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 12, 2011 20:55 UTC (Sat) by ballombe (subscriber, #9523) [Link]
Debian has a system (git-buildpackage and svn-buildpackage) that generates a source packages from a git or SVN repository by converting commit in the Debian branch to a quilt series, and updating the changelog. The Debian kernel is packaged that way.
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 13, 2011 0:28 UTC (Sun) by vonbrand (subscriber, #4458) [Link] No, this is nonsense. For, e.g., Ubuntu people (who use bzr, not git) or others who just don't like VCS this isn't exactly "preferred". Also, if I happen to hack on my program by keeping XEmacs buffers open on each file, do I have to distribute the memory image of the editor?
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 13, 2011 20:46 UTC (Sun) by mpr22 (subscriber, #60784) [Link] If J. Random Hacker produces a program that is 100% their own code, they are certainly free to licence it under copyleft terms that explicitly state the preferred form for modifications to be a $VCS_TOOL tree forked from the master tree. However, doing so would rather smack of corporatesque control freakery.
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 12, 2011 10:29 UTC (Sat) by xtifr (subscriber, #143) [Link]
I don't use RH at the moment, so this isn't directly relevant to me, but I have to wonder why someone isn't already designing a tool to take a monolithic patch and search a git repository for matching changesets. Seems like it should be reasonably straightforward (even though it might be slow). Even if the results weren't 100%, such a tool could probably identify a substantial number of the public changesets incorporated by RH in their kernels, leaving a much smaller chunk of unknown patch to deal with.
(This might not help in a case where someone keeps all their changes private, except for a monolithic patch, but as I understand it, RH does push pretty much all of their changes upstream to git in some form or other, and the only real question here is which specific changesets they're using in a specific kernel binary.)
If this isn't happening simply because people still have more respect for RH than for Oracle, and would feel uncomfortable undermining RH to possibly benefit Oracle, despite distaste for RH's current actions, then I understand (that's actually a part of why I haven't looked into it myself).
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 12, 2011 11:27 UTC (Sat) by adobriyan (guest, #30858) [Link]
People who work with kernel on daily basis and follow developments in mainline, can do this faster than some tool. :^)
This whole monolithic issue only seriously affect clueless who thinks that if patch applies to different kernel, it's OK to apply and ship it.
In fact, RedHat could just strip changelogs from individual patches to put them in panic mode.
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 12, 2011 12:27 UTC (Sat) by foom (subscriber, #14868) [Link] If it was really the case that the change doesn't affect anyone, RedHat wouldn't have made it.Or alternatively, if RedHat considers everyone else clueless and unable to understand patches, they really wouldn't have made this change, since all those clueless people were just going to waste their time building broken kernels by applying RH patches directly, without testing or understanding. And that just makes RH look better! No, clearly RH understands that this does affect some clueful people, a particular subset of which they really want to make things difficult for...
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 12, 2011 12:41 UTC (Sat) by adobriyan (guest, #30858) [Link]
> If it was really the case that the change doesn't affect anyone, RedHat wouldn't have made it.
I'm not saying that.
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 12, 2011 18:34 UTC (Sat) by xtifr (subscriber, #143) [Link] People who work with kernel on daily basis and follow developments in mainline, can do this faster than some tool. :^)I was under the impression that most such people ran their own kernels in any case. I was thinking more of independent developers who are trying to support their own code, but aren't generally afraid to trace a problem into the kernel when it seems necessary—I've found myself in that exact position a few times in my life. If your users are reporting different results on, say, Debian vs. Red Hat, you might want to do some quick-and-dirty triage, but with a monolithic patch set on one side, that becomes much, much harder. Of course, the last time I had to face a similar circumstance, the kernel devs were mostly still using BK, and I didn't want to deal with that whole mess, so I was forced to debug the old-fashioned way, but now the kernel devs are using the same VC that I use for most of my own projects, so I'd be much more likely to be irritated and inconvenienced by RH's monolithic patch.)
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 12, 2011 20:13 UTC (Sat) by jondkent (guest, #19595) [Link]
> If your users are reporting different results on, say, Debian vs. Red Hat, you might want to do some quick-and-dirty triage
Obviously that might be possible, but the RH kernel is such a mess of backports and patches, that realistically these days you'd be better off banging you head on the desk than trying.
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 14, 2011 13:39 UTC (Mon) by nix (subscriber, #2304) [Link]
To be honest when I've done that I've often combined a pile of printk()s in the kernel with comparison with upstream git. The RH changelog sequence wasn't terribly useful (in fact I'm not sure I used it at all).
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 14, 2011 23:38 UTC (Mon) by rahvin (subscriber, #16953) [Link]
Or buying a RedHat support contract and asking them to bang their heads against the desk until the problem is solved. After all that is how they make their money.
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 13, 2011 0:44 UTC (Sun) by vonbrand (subscriber, #4458) [Link] As has been explained numerous times already, the RHEL 6 kernel is numbered 2.6.32, but that is only because that was the starting point: It has pieces that are much nearer 2.6.34, and even 2.6.37, than 2.6.32. So the patches with respect to 2.6.32 are mostly massive backports and tweaks on top of that. So trying to identify the patches by comparing to the 2.6.32 stable series is futile.
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 12, 2011 21:12 UTC (Sat) by ballombe (subscriber, #9523) [Link]
I think the reason there are so much reaction to this in that the kernel is the only interesting component of RHEL for people using non RHEL-based distribution, because first it is very far of the upstream kernel and second there are applications that are "certified" only when running under this kernel (and some will actually fail to work under any other kernel). For that reason, there have been Debian packages made of the RHEL kernel in the past.
The other issue is that the ability to avoid vendor-locking and change the enterprise that provide support is always listed as an advantage of using free software, which RedHat try to remove.
For that reason, French administration tenders sometimes require Debian, because this a vendor-neutral platform that does not favor any company.
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 13, 2011 0:48 UTC (Sun) by vonbrand (subscriber, #4458) [Link] This "Debian packaged exact RHEL kernel" would not be inconvenienced in the least by getting a monolithic patch, er even just a tarball. Not any more than it is a (non)problem for CentOS or Scientific Linux.
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 13, 2011 10:38 UTC (Sun) by jrn (subscriber, #64214) [Link]
Let me make a non-sequitur: the Debian packaged libbdb certainly seems to be inconvenienced by getting tarballs without patches split out. Of course this is different from CentOS, I think, since CentOS is meant to have almost identical sources to RedHat, to the extent allowed by trademark law, right? For what it's worth.
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 14, 2011 23:45 UTC (Mon) by rahvin (subscriber, #16953) [Link]
I don't think RedHat is trying to stop anyone from supporting RHEL. That is still trivially easy to do as you wouldn't be changing the kernel, just offering support on it.
There is a very small subset under attack by this change and is the subset that is trying to use all of RedHat's work, but up-sell a better kernel that more closely matches mainline but at the same time contains all of RedHat's work on bug fixes that are rolled into dozens of different kernel versions. This small subset is now presumably forced to reverse engineer every single change and security update RedHat does on their kernel. That could possibly be a very costly task depending on how difficult acquiring the reverse engineering is. Time will tell if this change is effective or if the reality of RedHat moving everything upstream makes the reverse engineering easy.
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 13, 2011 9:08 UTC (Sun) by branden (subscriber, #7029) [Link]
It does not bother me in the least to be to the left of Bradley Kuhn when it comes to interpreting the GNU GPL. :)
I fully agree with his point that actual enforcement of the GPL's terms is a specialized domain. My experience is in voluntary compliance with it, which means trying to discourage people from adopting innovative, community-hostile readings of its terms.
If you want to know how to work with GPLed code in your organization, look first to common practice.
I can only hope that Red Hat's approach does not become common.
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 13, 2011 19:48 UTC (Sun) by gowen (guest, #23914) [Link] The only important thing about freedom -- software freedom or any other kind -- is the freedom to do those things of which those who granted that freedom do not approve."Freedom to behave as we want you to" is not actually freedom.
Kuhn: Thoughts On GPL Compliance of Red Hat's Linux Distribution Posted Mar 14, 2011 12:53 UTC (Mon) by Daddl (guest, #66681) [Link]
Isn't it really simple? If I change GPL'ed source code I have to make the altered sources available to those I distribute my binaries to (my customers). So if I have a customer, I can just give him a cd with the source code and be fully compliant. No need for a VCS or online repository at all - I can even have him pay for the cd and the work to burn it. The customer's right and ability to change the code to his liking isn't impaired by that - on the contrary he gets a code archive that I can at least make certain assurances for (like: if you have a given environment, just type 'make' and you're done). Yes, it is not comfortable for people making their own forks, and yes, it might not be 'playing nice' - but the other players (like in Red Hat's case Oracle and Novell) aren't either.
As a developer I don't have to push my changes upstream (something Red Hat is still doing for quite a lot of stuff), I don't have to actively support forks and make life easier for my competitors. In the end Red Hat, too, has to make a living somehow in order to continue being able to pay developers to contribute.
|
|||||||||||||