> Well, the only feasible way this could be done would be with an automated script.
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...
> In this case, someone went from human-readable code -> "meta-c" code (using automated script) -> C compiler -> binary
hold that right there. first, what exactly makes your "meta-c" code not human-readable (it's not 'meta', it's normal C btw)? second, the GPL has exactly zero mention of 'human', let alone 'human-readable'. where did that requirement come in?
> The "source" chain still starts at the original unmangled C files.
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. yet we don't see the 'original unmangled C files' released. 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? ;)
> You could also argue that the organization that did this would have to
> release their mangling script too, since it's part of the required build
first, the mangling script wouldn't help you much if you only had its output (i.e., what you'd want is a reverse script but the GPL doesn't require you to even create it). second, the mangling script, for all you know, is *not* part of the build process (you don't know what i do in my own environment, 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.