Well, one could argue that "the preferred form" of changing the program is the source + version control, but the version control is not really "part" of the source, for all intents and purposes it's something "internal" they use to manage their development work. It's part of the developer's environment so to speak; not much unlike the editor and compiler.
As far as the GPL is concerned, the purpose of providing the source is not to "participate in the community", but to have the ability to change the program. Do the clients of RedHat lose their ability to change the "program"? I think they don't.
You don't think there is any degradation in your ability to deal with source code if you have no idea that it's got various patches and where they come from? If your copy includes patches and a process to install them, it's a matter of a few minutes to compile without one of them (if it has no dependencies) because you don't want it. With a big ball of source code, you'd have to track down the original patch and see about how to reverse it - much more complicated.
It's clearly not impossible to change the program, but you have lost information. I don't think it's "obfuscation" in the traditional sense, but it's certainly not what I'd call friendly, either.
As the article points out, legally there is nothing wrong, they are perfectly in line with the GPL and anything it was meant to protect.
That doesn't take away from the fact that (apparently, it's not like I know anything about it...) some actions are being taken to make it more difficult for downstream 'users' (as in, repackagers) to make their modifications. Not impossible, just more difficult.
Unless they start renaming files, interfaces, functions and structures for no reason, it's really trivial to start with tree A and get a set of differences between it and tree B.
Almost a decade ago, I wrote some utilities that did exactly that, for merging and finding commonalities between the many (almost a dozen) different versions of the C programs that ran on our electronic voting systems.
> now figure out which patch each of those differences belongs to
Why would I have to do that?
And don't forget we not only have the current tarball, but we can analyze every release for differences, capturing some history with it.
Reconstructing each original patch may not be possible (it's an interesting problem), but reconstructing a set of distinct patches is. Humans would then be better at assigning meaning to them, even if it means calling Red Hat's support line and paying for the answer.
There is a difference between disabling a Red Hat patch and a group of changes between a set of files. Separating the large diffsets by fileset alone may provide good cues as to what they do.
> Now though, the company ships a tarball of the source code with the patches already applied.
No obfuscation what so ever.
Unless you define "source" as "source code + version control history".