LWN: Comments on "Red Hat and the GPL"

Red Hat and the GPL

triclone — Sat, 26 Mar 2011 07:59:21 +0000

Ran out of popcorn and ended up eating my own fingers. I foresee more specific details in future developments of the GPL. Up next: "Are Christians really following the Bible?". I apologize for sounding ignorant (because I am), but through this post and replies I have learned a lot of things. My greatest admiration and thanks for all the people that participate. This time I got more meat than I dreamed of. =)

Red Hat and the GPL

rahulsundaram — Fri, 18 Mar 2011 19:24:15 +0000

Yes, it does mean precisely that. Unless a codebase is licensed under GPLv2 or later, it typically cannot be incorporated with GPLv3 code.

http://fedoraproject.org/wiki/Licensing:Main#GPL_Compatib...

Red Hat and the GPL

mishad — Fri, 18 Mar 2011 19:06:10 +0000

> Although GPLv3 only requires the work as a whole to carry a prominent notice that you modified it, GPLv2 requires it of individual modified files:

Does that mean that GPLv2 is incompatible with GPLv3.?

That is, that GPLv2 code cannot be incorporated into a GPLv3 derived work, because of the "no additional restrictions" clause?

Surely not?

Red Hat and the GPL

mishad — Fri, 18 Mar 2011 18:55:34 +0000

> Taking this to an extreme,

The law doesn't do that -- judges interpret contracts "reasonably" not as what they might mean if taken to extremes.

> They have to distribute the complete source with with to rebuild the binaries,

Yes.

> nothing more.

Not quite -- they also need to identify their changes:

GPL v2 $2 (a): You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change

Distributing "base + patches" is arguably one way to do that. "Base + monolithic-patch" might be another. Simply adding a note in the file header is also OK.

Red Hat and the GPL

mishad — Fri, 18 Mar 2011 18:48:59 +0000

Agreed.

To know for sure we'd have to ask the GPL's original authors, but my reading of it was that the term was added to ensure that the right to produce modified works could be meaningfully exercised. In particular, it was to preclude distribution of "source" that was obfuscated (e.g. variable names changed, no whitespace, no comments, replace control structures with equivalent gotos) or which was already compiled (e.g. as "binary blobs" which form part of the resulting program/work).

I don't think anyone was thinking about VCSen back then.

Red Hat and the GPL

vonbrand — Sun, 13 Mar 2011 02:06:02 +0000

Yes, a single tarball is less valuable than a upstream tarball + individual patches + running commentary. But that is wide off the point: GPL does not mandate distributing the later, only the former. Sure, I'm miffed that I don't have access to a valuable resource anymore, but that doesn't make Red Hat's actions against GPL.

Red Hat and the GPL

dlang — Sat, 12 Mar 2011 20:37:04 +0000

my issue on this topic is around your point #2

RedHat _does_ distrbute the patches as separate items, but only to people who get a redhat support contract (no problem so far), and only under the condition that they don't redistribute the patches (under penalty of having their support contract terminated). It's this "don't redistribute" portion that I have a problem with

Red Hat and the GPL

PaXTeam — Fri, 11 Mar 2011 22:43:51 +0000

> That work was hard based on the format that Red Hat is shipping their
> kernel patch in these days, and the work should be thanked.

actually, i forgot to point it out previously, that 'kernel patch' does not exist. what does exist is a big monolithic tree with all changes applied on top of whatever base they had at the time.

> It has no relevance on my opinion of what Red Hat is doing here.

you just called this 'digging through their giant patch' hard the second time now. in my little world that's an opinion, and not exactly a flattering one (note how you thanked someone else, not RH).

> Um, this makes no sense as that is not how upstream development works.

we're not talking about upstream development. we're talking about RHEL development. they're two different 'products' with different development methods. what i was pointing out is that if all similar products (to RHEL, not upstream) began to distribute their derived works the RHEL6 way, what would you think of that? still be ok with it?

Preferred form for whom?

PaXTeam — Fri, 11 Mar 2011 22:35:58 +0000

> If the licensor hasn't made his definition of preferred form (if it's different than the GPL definition) [...]

ok, i think i see where your thinking went astray. you keep mentioning this 'GPL definition' of 'preferred form'. thing is, it does *not* exist. really, look at the GPLv2 (the license of linux) and see for yourself. what the GPL does define there is the 'source code', in terms of 'preferred form for modification'. it does *not* further elaborate on just what this 'preferred form' is. this is the entire reason for these discussions here because different people have quite different (or even contradictory) ideas about 'preferred form'.

> The reference to preferred form, in my opinion[...]

see, that's your own opinion only, noone seems to share it. and for good reason, that sentence in section 3.b does not define 'preferred form for modification'. really, if the license wanted to further elaborate on that term, it should and would have done so explicitly, like it already does for other terms where the license authors saw it necessary to be precise (whether they achieved that or not is another question but let's not digress). as to what your highlighted sentence was about see this thread somewhere else where others explained it. it's most definitely not about the 'preferred form for modification' term.

> Although the language could be a little clearer I don't think there is
> 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.

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
> interprets to be their preferred form is the form the licensor has to
> comply with.

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
> manner that is editable and machine readable.

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
> responding to Oracle's attempts to destroy them.

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
> redefine "preferred form" however they would like and what that would do
> to the community.

i don't need to imagine anything, i just need to look at the past decades and see what people preferred and did not complain about. i'm sure you know it as well and apparently it didn't scare anyone.

Preferred form for whom?

rahvin — Fri, 11 Mar 2011 18:14:17 +0000

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.

Red Hat and the GPL

dwmw2 — Fri, 11 Mar 2011 17:31:21 +0000

GPLv2 actually requires more here than GPLv3. Although GPLv3 only requires the work as a whole to carry a prominent notice that you modified it, GPLv2 requires it of individual modified files:

    a) You must cause the modified files to carry prominent notices
    stating that you changed the files and the date of any change.

Distributing the original source plus the patches would meet this requirement, at least in spirit although perhaps one could argue that for the modified files to carry prominent notices you'd actually have to insert obnoxious comments into the files themselves, rather than providing that information "out-of-band" in the patch set.

Red Hat and the GPL

gregkh — Fri, 11 Mar 2011 16:45:57 +0000

I only "called out" a thanks to Max for digging through the large
patch from Red Hat to figure out what patches should be applied.

That work was hard based on the format that Red Hat is shipping their
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.

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

Um, this makes no sense as that is not how upstream development works.
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.

Preferred form for whom?

PaXTeam — Fri, 11 Mar 2011 09:51:36 +0000

> [...]you are agreeing to those terms and the reasons they exist.

unless those reasons are explicitly spelled out in the license, no, you can't possibly be agreeing to them. what you do agree to is what's in the license, nothing more, nothing less.

> RMS has defined preferred form, that's the definition that applies
> baring the use of a different license.

you keep mentioning his definition/interpretation, where is it?

Red Hat and the GPL

PaXTeam — Fri, 11 Mar 2011 09:25:13 +0000

> My personal opinion is that Red Hat is fine in doing this if they want to.

then why did you see the need to explicitly call them out in the 2.6.32.30 announcement?

> Red Hat didn't make this very easy due to their "one giant patch" format[...]

now imagine if *everyone* else followed suit, where would that leave Linux development? is that the future you envision?

Red Hat and the GPL

pbonzini — Fri, 11 Mar 2011 08:32:58 +0000

> "Nobody disputes here that the monolithic kernel SRPM is making things harder."
>
> Please be more precise. What is being made harder?

Identifying RHEL patches that are not in 2.6.32-stable and applying them to 2.6.32-stable. Red Hat engineers do try to Cc stable@kernel.org on their patches, but it's possible that: a) they sometimes forget; b) they cherry-pick patches by authors who didn't Cc stable@kernel.org. Attems is trying to get into stable those RHEL patches which "fell through the cracks", and the monolithic SRPM makes the job harder. But he's not trying to modify the RHEL kernel itself (read on).

> Both of the things you are talking about are the Linux kernel, copyright 1991-2011 Linus Torvalds et al.
>
> The 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.

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.

Preferred form for whom?

rahvin — Fri, 11 Mar 2011 01:00:28 +0000

Your right, I've confused the two clauses. But that doesn't change the arguement. The GPL is a software license. It's commonly handled in the US under precedents and written law that differs materially from Contract law in only a few circumstances.

Anyway, when brought before a Judge it's the plain language of the license that matters. Where that plain language is ambiguous and the parties don't agree on the intent the court is obligated to consider extrinsic evidence including the intent of both parties at the time the agreement was executed (good luck on that). It's important that both parties know each other intent or have made available their intent in some way otherwise their intent becomes ambiguous and you move to the next step. Baring that knowledge the Judge is obligated to turn to the creators of the agreement. Baring that there are many other sources of extrinsic evidence that can be examined. Baring that it's up to the Judge to try to find an equitable solution to the disagreement.

My main point all along is that RMS has defined what every single one of the clauses in the GPL are for, what they mean and what exploit of the agreement they are meant to prohibit. Baring some exchange of intent between the licensee and the licensor those statements are the highest value source the Judge is going to find explaining the intent of the GPL license. There may be other information that adds to the information available but to argue that isn't the basis for the agreement is ignoring the entire history of how the GPL came about and why it was created. RMS is directly responsible for the GPL, through his work that agreement was created and when you sign on to use that agreement, unless you state otherwise, you are agreeing to those terms and the reasons they exist.

My secondary point is that there are probably as many work flows and preferred forms of source code as there are developers. Baring any clear statements of intent from a developer what does a licensee have to rely on other than the plain language of the agreement based on RMS's definition of what the agreement means? I'll argue that there is nothing wrong with changing that meaning, but you need to write your own agreement and call it something other than the GPL because if your intent and interpretation differs from RMS, you aren't using the General Public License.

RMS has defined preferred form, that's the definition that applies baring the use of a different license.

Red Hat and the GPL

branden — Thu, 10 Mar 2011 23:46:52 +0000

"Nobody disputes here that the monolithic kernel SRPM is making things harder."

Please be more precise. What is being made harder?

"You'd like the RHEL kernel to be distributed in your preferred form "for modification of something else", and that's not a right that the GPL grants you."

RHEL's kernel is not an independent work from the Linux kernel, be it the latest drop of the 2.6.32 kernel or some other variant. If it were, Red Hat Software, Inc. could just slap their copyright notice on the whole thing and tell everyone else to get lost.

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

branden — Thu, 10 Mar 2011 23:39:58 +0000

"Please do not read ANYTHING into my comments about this other than explicitly what I stated."

I was not trying to do, nor imply as much.

It is challenging for me to understand how a roster of RHEL's patches to its 2.6.32 kernel has value when Mr. Attems excavates it, but not when Red Hat provides it.

Because if it has value both ways, then clearly Red Hat has removed value from their kernel SRPM offering.

The pregnant question is whether such removed value brings the RHEL kernel SRPM below the threshold of being a "preferred form for modifying the work".

I acknowledge that, in your assessment, it doesn't.

Red Hat and the GPL

branden — Thu, 10 Mar 2011 23:34:39 +0000

Gonna have to be less terse.

Are you saying that the Linux kernel isn't upstream for Red Hat, but it is for Debian, or vice-versa? Or both?

Or neither?

This means that anyone distributing GPL code is in violation of the GPL

PaXTeam — Thu, 10 Mar 2011 21:39:37 +0000

> If Red Hat owns the copyrights of those changes (and it does contribute
> a lot to the kernel) then it can distribute those patches or code under
> whatever terms it likes!

not exactly. if their changes are considered as derived work from linux, then the GPL controls what they can do with it (namely, distribute it under the GPL). for non-derivative works it's indeed their call. for the kernel specifically it's a somewhat grey area whether one can create a non-derivative work, see all the 'are binary only modules legal' discussions of the past decade or two. based on past RHEL versions (and the RHEL6 beta which did come with patches), the majority if not all of RHEL's modifications fall under the derived work category and therefore RH can distribute them only under the GPL.

Red Hat and the GPL

martinfick — Thu, 10 Mar 2011 18:48:44 +0000

To make this argument you'd have to be able to define upstream, which I suspect that you cannot actually do in a satisfactory way. Red Hat in many ways is acting as an upstream for their long term kernels.

This means that anyone distributing GPL code is in violation of the GPL

paulj — Thu, 10 Mar 2011 17:18:55 +0000

And can vary between upstream development and vendor packagers. Preferred form can be a tarball for one, and tarball+patches for the other, in theory.

Course, wrt Linux, if *all* the kernel copyright holders don't have a problem with packagers not distributing the history of their fork, then there's not a problem.

Red Hat and the GPL

gregkh — Thu, 10 Mar 2011 16:38:42 +0000

>That Greg K-H singles out a Debian kernel maintainer, Maximilian
>Attems, for praise specifically regarding the matter of unscrambling
>the RHEL kernel egg suggests very strongly to me that Debian's got a
>better handle on the preferred form of distributing a patched Linux
>kernel than Red Hat currently does.

Please do not read ANYTHING into my comments about this other than explicitly what I stated.

I thank Max for doing this work as it is great stuff and benifits all of the distros when he does so. It has nothing to do with how Red Hat distributes their kernel and my viewpoint of that being a "better" way or not at all.

My personal opinion is that Red Hat is fine in doing this if they want to. It's their kernel, their process, and they are abiding by the GPL just fine.

Red Hat and the GPL

mjg59 — Thu, 10 Mar 2011 16:37:24 +0000

"Upstream projects".

This means that anyone distributing GPL code is in violation of the GPL

branden — Thu, 10 Mar 2011 16:37:12 +0000

Yes. This.

The "preferred form for modification" varies in time and space.

We know what the preferred form for the Linux kernel is because major distributors like Debian and--until recently--Red Hat supplied it.

Red Hat and the GPL

branden — Thu, 10 Mar 2011 16:34:33 +0000

"The kernel's the higest profile example."

Of what? You said earlier:

"The simple and obvious fact is that some upstream projects only distribute patchless tarballs despite their development being performed in a patch-oriented manner. ... Debian ship these projects anyway, which implies that nobody seriously thinks that they're violating the GPL."

Debian's packaging of the Linux kernel is not an example of this at all, and hasn't been for several years. Have you forgotten how Debian handles its kernels? I'll grant that things might have changed in the past few years, but they don't appear to have done. What you get on a freshly-squeezed (natch) system is, structurally, what you'd have gotten several years ago:

linux-patch-debian-2.6.32 - Debian patches to version 2.6.32 of the Linux kernel
linux-source-2.6.32 - Linux kernel source for version 2.6.32 with Debian patches

Have a look sometime.

Here's a terminal transcript, edited for space and clarity:

$ apt-get source linux-patch-debian-2.6.32
[...]
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

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.

This means that anyone distributing GPL code is in violation of the GPL

paulj — Thu, 10 Mar 2011 15:57:08 +0000

Actually, the GPL does say you should be able to get source on a "medium customarily used for software interchange", which floppies may once have satisfied. Note that your individual situation doesn't alone determine it.

However, we're discussing a different part of the GPL.

If the preferred form were original plus patches, than that's indeed what would have to be distributed, as you say. I don't see how that means git can't be used though. Indeed, a git repository made available IS a form of distribution, just as much as placing a tarball in a folder accessible via HTTP is (some people have argued a git repo is "content storage", and hence somehow different to distribution, which seems an incorrectly restrictive view) - indeed, the git repository is a much BETTER form of distribution.

Another important point. Preferences are perfectly capable of changing, particularly as technology does. Just because 10+ years ago the vast majority of developers preferred to trade big tarballs of the source, with history restricted to a ChangeLog file, does not mean that they prefer it today. As the state of the art in SCMs changed, developers/maintainers now tend to use the likes of 'git pull' rather than ftp'ing a tarball from tsx-11 or sunsite (or buying a walnut creek CD set).

Just as floppies today almost certainly no longer meet the "custom medium" requirement because of change, even though they once did, so it is perfectly possible for source form requirements to evolve from tarballs to a git repo. The habits and expectations of GPL software developers/maintainers do not have to be static.

Note Carefully: Even if that were so, that does NOT mean all GPL projects would HAVE TO all switch from tarballs to (e.g.) git repos together. It's perfectly possible for different communities and different projects to have different standards for preferred forms of sources.

The problem with what RedHat have done is that it's difficult for anyone to argue with a straight face that kernel developers prefer not to have the history *today* (that Linus once distributed only tarballs is somewhat irrelevant, when he's been distributing full history with releases for at least a decade - note that the GPL does NOT require that the format for the history be itself in a non-proprietary format).

Note Carefully 2: No one person can say what the preferred form is. It presumably depends on consensus.

This means that anyone distributing GPL code is in violation of the GPL

southey — Thu, 10 Mar 2011 15:18:07 +0000

That's makes no sense - just see the comments where people wanting access to an actual git repository. The floppy drive and even the pure CD-ROM drive are essentially arcane, I still have essentially unused computers with these so I should be able to ask for source code on a floppy or cd-rom as that my 'preferred form' for those computers but I need online access for day to day computers.

I am not misunderstanding, just pointing out the stupidity of that line of argument because the GPL does not go into any definition of it. So if the 'preferred form' of source is patches, then we must always get the original plus all patches. Of course that means no distributed revision control systems such as git for distribution. (Yes I know git can create and apply patches but it is more correct just to push and pull.)

Red Hat and the GPL

paulj — Thu, 10 Mar 2011 14:43:33 +0000

The distinction he was drawing is pretty widely understood really, embodied fairly concretely as it is by the difference between the sources distributed by Linus for the Linux kernel (upstream) and those distributed by RedHat as the sources for the kernel RPM previously (to choose one example amongst many). It's not hard to grasp really. ;)

Red Hat and the GPL

mjg59 — Thu, 10 Mar 2011 12:47:33 +0000

It's also preferable for an upstream maintainer to provide new releases in a manner that allows people to bisect patch history. I don't understand the distinction you're drawing.

Red Hat and the GPL

dwmw2 — Thu, 10 Mar 2011 11:24:00 +0000

"Back when people sent patches directly to Linus and he just released tarballs, was he violating the GPL?"

It's important to remember that there is a clear distinction between upstream, and a modified version or fork.

Tarballs are a perfectly sane way for upstream releases to happen.

But I think that every competent open source developer, when they're not trying to twist things to make a point, will agree: When releasing a modified code base which is based on some upstream project, it is definitely preferable to release that in the form of original + patches, rather than as a monolithic tarball of the whole damn mess.

This means that anyone distributing GPL code is in violation of the GPL

paulj — Thu, 10 Mar 2011 11:15:42 +0000

No one discussing the preferred form has argued that it means distributors must provide whatever arcane form any user wants (and by extension, provide all possible arcane forms), other than those erecting straw-men. If that's what you believe some people have seriously argued that that is what preferred form means, then you likely have gone out of your way to misunderstand them.

Red Hat and the GPL

pbonzini — Thu, 10 Mar 2011 10:38:50 +0000

> Red Hat kernel engineers are not as upset about this development as I had
> assumed based on second-hand reports in previous LWN discussions. I
> appreciate having my misconceptions punctured.

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

Red Hat and the GPL

pbonzini — Thu, 10 Mar 2011 10:31:56 +0000

The combined reading of the parent comment, and the CTO's press release, will give you the answer.

Red Hat and the GPL

pbonzini — Thu, 10 Mar 2011 10:28:32 +0000

> On the one hand, that's not necessarily true. If you're working for a
> distribution but work closely with your upstream, you might work "in" your
> Debian source or SRPM environment, but test for the existence of a
> user-reported bug in the upstream code first, and if it is present there, > patch it there before porting it back down to your own distro.
>
> Needless to say, this pattern is often done in reverse, but I'm sure a lot > of upstreams would like to see more instances of the above.
>
> And that's exactly why Red Hat's move here has some kernel hackers (Greg
> K-H at least) wincing.

If I understand correctly, you want to cherry-pick patches from 2.6.32-el6 to 2.6.32-stable. So you're treating here "2.6.32-stable" as the downstream and "2.6.32-el6" as the upstream. Nobody disputes here that the monolithic kernel SRPM is making things harder. However, note that you are _not_ making modifications to RHEL kernel. You'd like the RHEL kernel to be distributed in your preferred form "for modification of something else", and that's not a right that the GPL grants you.

Red Hat and the GPL

paulj — Thu, 10 Mar 2011 10:00:17 +0000

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

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

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

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

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

Red Hat and the GPL

PaXTeam — Thu, 10 Mar 2011 09:41:23 +0000

> - are Red Hat stopping committing upstream - no

nothing to do with the RHEL6 srpm.

> - are Red Hat refusing to work with other devs - no

nothing to do with the RHEL6 srpm.

> - are Red Hat trying to protect their business - yes

nothing to do with the RHEL6 srpm.

> - does this really affect other distros - no;

yes it does (you could have inferred that from all the complaints of said 'other distros'). and more than just 'distros' (there're many in-house 'distros' too that every now and then take a look at what RHEL has, e.g., for backports of security fixes, etc).

> they do not use rhel kernel, at least not the rhel ripoffs

childish namecalling doesn't help your cause. i know, i just did it too.

> - do you want to use a rhel kernel - no;

strawman. if you put it this way: "do you want to use PARTS OF a rhel kernel" then you're getting closer to understanding the issue.

> they are very old and have little in common with the vanilla tree

RHEL6 (the topic of this whole discussion) is anything but 'very old'. and it has a lot in common with the vanilla tree, not the least because of RH's own effort to send upstream as many bits and pieces as possible.

Red Hat and the GPL

mjg59 — Thu, 10 Mar 2011 03:20:18 +0000

The kernel's the highest profile example. There's various bits of software I've released where I've never pushed a repository (or even a changelog worth a damn). It's not a question anyone's ever really asked before this issue. From a Debian perspective, my recollection is that people have argued that "source" as defined by the DFSG means "preferred form for modification" as defined by the GPL, in which case it's an issue for Debian regardless of whether the code's under the GPL or not - in fact, you seem to argue that point in http://lists.debian.org/debian-devel/2002/11/msg00662.html .

Preferred form for whom?

branden — Thu, 10 Mar 2011 03:11:54 +0000

There's a typo in the above; I quoted 3b), not 2b).

But 3a) is even more squarely on point:

" a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,"

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.

Red Hat and the GPL

branden — Thu, 10 Mar 2011 03:05:39 +0000

And not all of those are even licensed under the GNU GPL.

But for those which are, if the copyright holders have a consensus view that one unpatched tarball is all they deign to provide, then there is no GPL issue.

I have already said multiple times that if all the copyright holders in the kernel are cool with this (or disappeared, or disinterested), then there is little practical that can be done on the legal front. Only copyright holders have standing to sue for infringement of their copyrights. In the case at issue, Red Hat subscribers *might* have standing to sue on different grounds, breach of contract, if the subscriber agreement promises, explicitly or implicitly, that packages provided under the agreement will be delivered in compliance with their applicable copyright licenses. I honestly don't know whether this is the case for the RHEL subscriber agreement, as I haven't read it in something like seven years.

Could you make this less hypothetical and name some examples of packages that meet your qualifying criteria?