Reasoning behind the "preferred form" language in the GPL

so are you saying that RH's (their software developers') preferred form for modification is a single monolithic tree with no track of changes? because we know it's not the case therefore according to your own criteria they'd be violating the GPL when they distribute the monolithic tree.

> If you distribute original source and patches, you are complying with
> GPL with respect to the original source.

this is what i thought too but RHEL6 doesn't have this in the srpm so if you think RH is in the clear when they're distributing a monolithic tree for RHEL6's kernel then so would i be with my one liners *regardless* of what form i use myself for development. so you see something doesn't compute here, you're basically contradicting yourself: you want me to justify my development method when i distribute one liners but you accept RH's monolithic tree even if that's not how they develop RHEL's kernel.

> As you don't distribute any patched stuff, that is all you need to do.

i lost you here. we're talking about someone (like RH) who took a GPL'd work and created a derivative ('patched' it) and distributed it in binary form and therefore has to provide the 'source code'. if the work is original and not derivative, there's nothing to talk about, the author does whatever he wants with his work.

> GPL allows to patch the original (via your patches or by hand),
> so anyone who gets the package from you is in the clear too.

i don't understand how this came up here, there is no question that you can patch a GPL licensed work (i.e., create derivatives of it) and there's no question that you can distribute the derivative work (per the GPL's conditions). what is in question is the *form* of the derivative work, in particular what the 'preferred form for modification' means. but you already established that it's the form that the author(s) of the derivative work themselves use, from which it follows that RH is in violation according to you as well.