Obfuscated source code, are a bit more of a gray areabut not much. Those kinds of actions should be seen as clear attempts to circumvent the GPL requirements. But that's not at all what Red Hat is doing.Isn't it? When coupled with a clear attempt to dissuade customers who do have access to the patches from disseminating them further, how could it be interpreted differently? The lack of patches from the SRPM is not just a benign side-effect of some other change in the development process; it seems clear that it is intentional, and done in order to avoid releasing those patches to the public.
The tarball that Red Hat is releasing may not be the preferred form for the Red Hat kernel developers to use, but that is not part of the requirement.Isn't it? The GPL requires that the source be distributed in the "preferred form of the work for making modifications to it".
The GPL is silent on whose preference is relevant here, and what they should have to do to prove that they really prefer things the way they claim. It's not reasonable for a distributor to claim that their preferred form is precompiled assembly code, nor for a recipient to claim that they prefer the code to be distributed with full hardware documentation and the email address, phone number or ICBM co-ordinates of the hardware designer (although the latter is certainly true in many cases).
I only really see one reasonable interpretation of the "preferred form" clause it has to be "the form which is agreed by consensus, among experts in the field, to be the preferred form for modifying the work". Is there any other sane interpretation? (Or, as I suppose is more to the point, is there any other interpretation which is likely to be accepted in court?)
And Red Hat's kernel engineers are a representative sample of the experts in this particular field. I think their preferences are exactly part of the requirement, aren't they?
So, what is the general consensus on the preferred form for modifying a work? In the case of an "upstream" work, tarballs are certainly fine.
But where the work is a fork or modification of an existing project, the situation is very different.
Just go and talk to any competent open source developer about how to distribute that kind of code, and she will tell you that distributing a simple tarball of your modified version is ABSOLUTELY NOT the preferred form. Nor is it even close.
I've done a lot of work on porting Linux to embedded devices where the device manufacturer has "had a go" at porting it for themselves, and has given us their attempts as a starting point. Back in the early years of this century, we regularly used to get tarball releases like that.
Trust me, if you had heard the language we used as we went through these abominations, trying to work out what the hell was in there (e.g. 2.4.14 + rmk1 + np3 + random other patch sets before they even started to make their own changes), you would not be trying to make an argument that a monolithic tarball could possibly be the "preferred form of the work for making modifications to it."
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds