It's not so simple [LWN.net]

It's not so simple

Posted Mar 2, 2011 7:59 UTC (Wed) by paulj (subscriber, #341)
In reply to: It's not so simple by dlang
Parent article: Red Hat's "obfuscated" kernel source

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

to post comments

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.