It's not so simple [LWN.net]

It's not so simple

Posted Mar 1, 2011 8:44 UTC (Tue) by pLub (guest, #73230)
In reply to: It's not so simple by ekj
Parent article: Red Hat's "obfuscated" kernel source

> RedHat here made a change SPECIFICALLY to make it harder to "make modifications" to their kernel. (for example the modification of removing a single patch)

The overwhelming majority of the patches that go to Red Hat's kernel tree are already upstream so, to remove a single patch that you know causes a regression or something like that you only need the _upstream_ git tree and the SHA1 of the patch in the upstream git tree (or, for that matter, an URL for gitweb or lkml).

The list of patches is necessary to bisect problems and perform other support chores, but is definitely not necessary in order to "make modifications".

to post comments

It's not so simple

Posted Mar 1, 2011 10:31 UTC (Tue) by ekj (guest, #1524) [Link] (1 responses)

This is true -- i.e. it's possible to do that modification, even without the patches, and the information is available elsewhere for those who invest the time to do the detective-work.

Adding to this workload was however, if we are to believe the information in the comments here, *explicitly* stated as the reason for the change.

Notice that the GPL does not say "possible", it says "prefered", and a naked kernel-tree with no history, no changesets, no version-control is definitely not the "prefered" starting-point for making changes. (the prefered starting-point seems to be a clone of somebodys git-tree)

When someone changes the distributed form of the kernel-source, explicitly to make it LESS convenient to make changes, it's questionably if the same people can at the same time claim that they distribute it in the prefered form for making changes.

Like I said: I've got no idea how the law would interpret it, but it's definitely against the *spirit* of the GPL. (which is: you should give me the source-code in the form that is *prefered* for making changes, i.e. the form that is most convenient.) Making changes explicitly to make life *less* convenient for people who want to make changes to the code, certainly conflicts with the spirit of that.

It's not so simple

Posted Mar 2, 2011 7:34 UTC (Wed) by pLub (guest, #73230) [Link]

> This is true -- i.e. it's possible to do that modification, even without the patches, and the information is available elsewhere for those who invest the time to do the detective-work.

In theory, there is one kind of modification which is helped by the presence of the patch list, namely reverting a patch. In practice, riel said above that on a modern kernel this is made much harder by the fine-grained structure of the patches. I'll take his word for it.

But if you agree with me that you can do the same work with an upstream clone, you're not talking about _that_ modification, you're talking about _another kind_ of modification. You're talking about one of the following:

1) backporting a patch into the Red Hat kernel from stable, or upstream, or from another distro kernel. In this case the patch wouldn't obviously be in the Red Hat SRPM, so the patches wouldn't help.

2) backporting a patch from the Red Hat kernel to stable, or to the Debian kernel (it is not a coincidence that the problem was raised by a Debian kernel maintainer). In this case the patches obviously help, but in this case you're not talking about modifications to the Red Hat kernel! And the GPL talks about "preferred form for modification" of what you're distributing, not modification of something else.

Besides, I would rather avoid talking about the spirit of the GPL, since it is a very multifaceted spirit. For example, unlike other licenses it includes the "right" for you to make money on Free Software (for example from support), and Red Hat is obviously exercising it.

It's not so simple

Posted Mar 1, 2011 11:28 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

... and you can figure out what the patches are with a diff and a lot of 'git blame' calls. (Actually, you can reduce the git blame calls to a maximum of the number of commits that touch the changed lines.)

And if I can think of this method in three seconds Oracle certainly already have.

This isn't going to slow Oracle down much, but it'll annoy everyone. Great move, RH bosses.

It's not so simple

Posted Mar 1, 2011 13:58 UTC (Tue) by nix (subscriber, #2304) [Link]

Some obvious heuristics (simple-minded ones: they don't need the tool to have any knowledge of C) will also suffice to produce plausible patches even from the set of changes that do not yet exist in an upstream git tree: it seems to me that things like patches introducing API changes can be reconstructed automatically with fairly high precision. With a bit more work (and a lot more CPU time) you can even produce plausible patches which will compile. (Sure, they probably won't be identical to the upstream patches, but they'd be good enough to bisect against.)

(The more I think about a tool to do automatic patch composition like this, the more useful it seems, and not just for this application either. After all, it's not RHEL-kernel-specific: it's a generalized way of turning giant third-party code drops against git-maintained projects into 'this came from git: this did not: of those, these bits look like they are unrelated'.)