"The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable."
When someone checks out code from whatever revision control system they have, you end up with directories that have source files + project files for the IDE (if applicable), and other related files. You don't directly edit git, cvs, svn, or whatever, you work directly with source files in a directory structure. You modify those files. Even with something like clearcase's dynamic views, to the compiler and programmer, it's still a filesystem (source files + directories). A tarball of that file system contains the source code in the format (C / headers / makefiles, etc) that is used for making modifications and preparing derivative works.
"for my specific example yes, very likely, but i can imagine other transformations that i can pull off by hand and would still irk the casual programmer when looking at it. also, what if my transformations were done within an IDE? no scripts to distribute would exist then..."
Fine, if your coding style is such than ok, I have no problem if that's how you work internally. But be prepared to show that you're not obfuscating the code prior to releasing the source. So, if someone sues you for a GPL violation and during discovery it's shown through your revision control system that you work in a normal fashion then proceed to obfuscate the code then release source, you'll be in trouble. You went through a step to transform the source from it's preferred form for modifications to something useless for the recipient of your source. As far as the IDE goes, it'd be the same thing. One of two things happens in the IDE case:
1) The IDE writes screwy source files but presents them to the programmer in an understandable format (in which case a receiver of the source could just use the same IDE).
2) The IDE has an obfuscate function which translates the source away from anything understandable so its no longer the preferred form for making modifications, which is in direct violation of the GPL section quoted above.
By the way, since RH is _NOT_ obfuscating their source, you've created a strawman here.
The thing you're failing to address is that there is a difference between version control and the actual sources. git, svn, cvs, etc are _not_ source code. They are repositories _for_ source code. Let me turn this around and present you with an argument:
To justify _your_ position, you need to prove than I can't download a kernel release (in source tar ball format) and make modifications to that source. Keep in mind that this is the method kernel.org used for years prior to git. Were they violating the GPL? If not, then how can RH be in violation for doing the exact same thing?
"hold that right there. first, what exactly makes your "meta-c" code not human-readable"
Ok, so remember way back when C++ code was translated to C code then that code was compiled (there were quite a few compilers that did this)? You, being the programmer, started and worked on the normal C++ code. The machine took over after this point doing the translations to C and went on from there. I'm not going to pretend that I can understand that C code, and I surely can;t ship that and claim it's the "source" fo rthe program. Your example is similar in nature. There is a starting point in the process that a person edits and works with source files (C / C++ / IDL files, project settings, etc). Past that point is where the source code ends. That's the clear line in the sand. Sure the translated C is readable in one way (I can see the characters), but it's not readable in terms of comprehension and all but useless for modifying.
I realize full well it's still C code, but in your example, it went from a normal format that people can read and follow to a syntactically correct (for C), but incomprehensible format, thus my "meta" term.
"second, the GPL has exactly zero mention of 'human', let alone 'human-readable'. where did that requirement come in?"
That's exactly why the "preferred form of the work for making modifications to it" language in the GPL exists. To modify the code, you need to be able to read and understand it. Deliberately obfuscated code fails this requirement and is thus against the GPL. This requirement also protects against the application vendors sending downstream users printed hard-copies, screen captures of an IDE, or other methods of source distribution that can't be worked with for the purposes of modifying and preparing derivative works. The GPL was very well crafted in this regard.
"and? what does that have to do with the GPL's 'source code' distribution clause? not to mention that following your logic, RHEL6's source chain most likely started with some git tree (for the sake of discussion let's assume 2.6.32) and then it got mangled over time."
Wrong. RHEL6's kernel source started as exactly that: source code. It might have come out of a version control system, but it's _NOT_ the version control itself. Modifications to source files happen over time, versions get committed back to a control system, but the _source code_ that's being modified is still the C and associated files. You keep trying to tie the versioning system and source code together and that's where your logic fails.
"so as i said to vonbrand already, you either accept my proposed one-liner files or you don't accept RHEL6's current form of distribution. which is it? ;)"
Your logic is flawed for the reasons outlined above, so I can both reject your proposed one-liner files as being against the GPL and accept RH's current distribution as being GPL compliant.
"i may or may not use the mangled form for modifications myself, much like you're saying that we shouldn't care what form RH developers use as long as the released 'source code' compiles), the mangled files are perfectly compilable."
Wrong again. Version control != source code. The RHEL folks probably edit in emacs or vi... who knows, but they're modifying files (C, headers, makefiles, etc), not directly editing git. Once you appreciate the difference, you'll see that the hypothetical situation you're describing and what RH is doing is completely different. RH provides the tarball for their kernel just like a full source download from kernel.org. They aren't obfuscating the source or coming anywhere near that, which is what your hypothetical situation is all about. What RH _is_ doing is restricting access to the version control system. These are two different things, one of which is prohibited by the GPL, one of which is not. Show me anywhere in the GPL where revision control system is mentioned. At best, there is the language which says to illustrate the changes. Since, IIRC, there is a single large patch that is released along with the complete tarball for their kernel versions, RH meets this obligation as well.
Yes this is a PR nightmare, but no, it's not a GPL violation.
If someone wants to be angry over the policy change, then fine. But let's at least be reasonable about what there is to be angry over. Let's discuss real issues (effects on the community, transparency in the development process or whatever) rather than fabricating scenarios that just aren't there.