It's not so simple [LWN.net]

It's not so simple

Posted Mar 2, 2011 5:57 UTC (Wed) by AndreE (guest, #60148)
In reply to: It's not so simple by dskoll
Parent article: Red Hat's "obfuscated" kernel source

You may say it's a punishment, I might suggest it's protecting their business. And I still don't see where in the GPL this is prevented, although I will admit reading yours and some other points have made me think of things differently.

We can both come up with extreme cases supporting the legitimacy or illegitimacy of this decision. I might suggest that Red Hat has no obligation to provide support to entities that just repackage their efforts under different logos, although they DO have obligations to respect the GPL when distributing code to all subscribers.

to post comments

It's not so simple

Posted Mar 2, 2011 6:11 UTC (Wed) by dlang (guest, #313) [Link] (7 responses)

I agree they have no obligation to _support_ people to repackage their code and redistribute it, but they do have an obligation to _allow_ people to repackage their code and redistribute it.

this obligation is based on the fact that most of 'their code' is not actually theirs, it's code from other people who let them use it on the condition that they let others use it (and derived works) as well.

RedHat has traditionally made it easy for people to make rebranded distros by keeping all their branding fairly nicely isolated.

they would be perfectly within their rights to stop doing so, no longer provide broken out patches for anything, and start including trademarked logos embedded in the source files to make it harder for people to strip the trademarked branding out.

and there may even be technical arguments for doing exactly this in the final build code version (and no, I don't buy the argument that a series of patches is the "preferred means of modification" patches aren't edited by humans, they are a way of transmitting changes from one entity to another).

If that is what they were doing, I would be silent, or supporting their right to do so (while not necessarily agreeing that it's a good idea to do so)

It's not so simple

Posted Mar 2, 2011 6:41 UTC (Wed) by paulj (subscriber, #341) [Link] (6 responses)

If RedHat internally keep patches separate and build from stock + patches then that's their preferred source. If the source they distribute has the patches applied in part to frustrate cloners, and if there is sufficient value in having the broken out patches that customer demand still forces them to make these available to customers, then that would clearly seem to make that form of redistribution be of source in a 'less preferred' form. Contrary to the GPL.

Think very carefully about defending RedHat here. While RedHat generally get Free Software and are reasonably trust-worthy[1], and we might feel like cutting them slack, there are plenty of other Linux distributors who don't. Particularly in the embedded world, if you can even get (all) the source, it's usually a giant tarball. To the extent such distributors keep patches separated out internally, users who buy such devices *should* be able to get at those patches. It's not a massive issue yet, because usually the changes they make are small enough that diffing is still tractable - but that need not always remain the case.

1. Even if they've apparently acquired some amount of middle-management that doesn't and may not be, according to daniel (which, if correct, makes for a long-term worry the community should have for RedHat: some of those middle-managers may progress to top-level management one day).

It's not so simple

Posted Mar 2, 2011 7:33 UTC (Wed) by dlang (guest, #313) [Link] (5 responses)

the preferred form of editing is not patch files, it's source files that some tool creates patches from

yes, I know that there are people who edit and write patch files directly. I also know a person who taught himself C from the K&R book by compiling the examples and then reading the machine code that resulted (a long time mainframe systems guy), such people are very much the exception and are not what we base expectations on :-)

I wouldn't expect to require patches, or git trees any more than I would require a someone who used a proprietary compiler to compile GPL source code into a binary provide me with a copy of the compiler because that is what I would need to recreate the binary I got from that person.

so I have no problem with someone just providing one tarball of the result instead of broken out patches (I may have concerns about why someone is doing this, especially if they used to do something more useful, but that's not concerns over what is being done, but rather why they are doing it)

while I think it would be nice to get a git tree of the patches, deciding that such a thing is a requirement gets very ugly very quickly (what if they use a proprietary version control system instead of git? for example?)

It's not so simple

Posted Mar 2, 2011 7:59 UTC (Wed) by paulj (subscriber, #341) [Link] (4 responses)

The GPL doesn't say "preferred form for editing the code" it says "the preferred form of the work for making modifications to it". RedHat internally prefer to make modifications using change-sets on top of a canonical source-code. IME this holds nearly universally in the free software world, and much of the proprietary world. That /edits/ are made after applying the patches is a subset of the work-flow of modifying source code. However, many people /do/ edit diffs directly - Linus in the past (pre version control days) said he did, and patch-utils has a 'rediff' tool to remove the tedium of counting and adjusting the line numbers. Whenever companies distribute their Linux kernel sources as a source tarball, one of the first things recipients do is to diff it against the stock kernel.

I actually agree with you in your caution about drawing firm lines. However, I'd argue such caution should go /both/ ways. Not only should be cautious about concluding that publishing changesets is a GPL requirement, but we should also be cautious about concluding that only publishing the aggregated-together sources and NOT the changesets is sufficient to comply with the GPL. I'm not sure myself where the line is, or what principle can be drawn other than "decide on a case-by-case basis", but I do think that in cases where there clearly is such a large amount of information contained in the deltas that /not/ publishing them effectively frustrates anyone trying to replicate the work, and that the publisher retains a significant advantage by having its own internal work-flow still be based on those deltas, that then there is a strong case to be made that the published source no longer is in preferred form...

It's not so simple

Posted Mar 2, 2011 9:06 UTC (Wed) by airlied (subscriber, #9104) [Link] (3 responses)

so if I download a tarball from kernel.org of Linus kernel, kernel.org is violating the GPL?

just because there is a git tree somewhere I can access if I want it doesn't change the fact that I was given a tarball which wasn't in what you are calling the preferred form.

It's not so simple

Posted Mar 2, 2011 10:24 UTC (Wed) by maks (guest, #32426) [Link] (2 responses)

> so if I download a tarball from kernel.org of Linus kernel, kernel.org is
> violating the GPL?

The point beeing that linus doesn't really hide his git tree on kernel.org, whereas RH does. I'm pretty sure that you know that they didn't before, as up to RH 6.0 beta all patches are visible.

Wow. Talk about fogetting history.

Posted Mar 2, 2011 15:17 UTC (Wed) by khim (subscriber, #9252) [Link] (1 responses)

The point beeing that linus doesn't really hide his git tree on kernel.org, whereas RH does.

Well, Linus did that for a few years. It was not possible to get meta-information from bikeeper.com without agreeing to pretty onerous terms. Note that some developers refused to accept such terms - but none tried to imply that what Linus and other were doing is breach of the GPL!

Sorry, but this ship sailed long ago.

Wow. Talk about fogetting history.

Posted Mar 2, 2011 16:59 UTC (Wed) by paulj (subscriber, #341) [Link]

There may well be a difference between making available what you can versus, versus deliberately withholding things you have easily to hand (or not). The judicial system certainly can take intent into consideration, and does so as a matter of course.

It's not so simple

Posted Mar 2, 2011 10:41 UTC (Wed) by pboddie (guest, #50784) [Link]

You may say it's a punishment, I might suggest it's protecting their business. And I still don't see where in the GPL this is prevented, although I will admit reading yours and some other points have made me think of things differently.

I don't care about Red Hat's business, but I do care about GPL compliance, so let's look at that aspect. To those who receive binaries (as part of their subscription), Red Hat also make the corresponding sources available, albeit in a form that others (who additionally have access to that software) may not prefer. In addition, Red Hat also appear to make the patches available on the condition that these are not redistributed, with the penalty for breaking this condition being that the offending subscriber's subscription is terminated and that they will receive no more patches.

Now, in the context of upholding the terms of the GPL, Red Hat appear to provide the corresponding sources to the binaries being distributed, so they aren't violating the GPL in this respect. Meanwhile, the patches distributed separately, whilst potentially being considered derived works of GPL-licensed work by other authors, still presumably come with all the privileges conferred by the GPL: you may still redistribute them, but Red Hat may then decide not to share any further patches with you.

Clearly, the GPL doesn't make anyone promise that they will continue to share new updates and revisions to a piece of software that has already been shared, so Red Hat can probably get away with making such continued sharing conditional on the "good behaviour" of subscribers. You can even turn this on its head and say that Red Hat only promises to share one revision's worth of patches but may continue to do so on the basis of such "good behaviour".

Having said all this, the divisive and isolating effect such policies might have, disempowering recipients of software and making them mere consumers, arguably work against the spirit of Free Software.