"Un-obscur[ing] JS" and "decompil[ing] a binary file" have nothing to do with applying or removing whitespace from CSS markup.<div><br></div><div>Removing whitespace from a CSS file has absolutely nothing to do with obfuscating PHP. I find the mere suggestion to be a disingenuous straw man. Code obfuscation <i>actually changes the content</i> of the code. Removing whitespace does no such thing.</div>
<div><br></div><div>Removing whitespace does not require decompiling, unencoding, reverse-engineering, or any other content-altering method in order to undo.</div><div><br></div><div>I would assert that your interpretation of "preferred form of the work for making modifications" strains both the wording and the intent of the license. Otherwise, If I don't like the way that you indent, camelcase, or inline-document, etc. your code, by your interpretation of "preferred form of the work for making modifications", I could, under the auspices of the license, compel you to provide me code that meets my "preferences".</div>
<div><br></div><div>Chip</div><div><br><div class="gmail_quote">On Fri, Feb 18, 2011 at 10:24 AM, Austin Matzko <span dir="ltr"><<a href="mailto:austin@pressedcode.com">austin@pressedcode.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Feb 18, 2011 at 9:19 AM, Otto <otto at <a href="http://ottodestruct.com" target="_blank">ottodestruct.com</a>> wrote:<br>
> Folks, seriously? This is not a GPL issue.<br>
><br>
> Even minified CSS is still CSS, and it's not rendered uneditable by<br>
> minification. Use any CSS Beautifier and voila, it'll add the<br>
> whitespace right back for you.<br>
<br>
</div>And I can un-obscure JS <<a href="http://core.trac.wordpress.org/ticket/15262" target="_blank">http://core.trac.wordpress.org/ticket/15262</a>><br>
and even decompile a binary file.<br>
<br>
Just because obscured or compiled files can be reverse-engineered<br>
doesn't mean that they meet the requirements of the GPL. Chip's<br>
one-rule CSS example demonstrates that at the fringes GPL-compliance<br>
can be vague, but that doesn't imply there are no boundaries.<br>
<div class="im"><br>
On Fri Feb 18 15:11:20 UTC 2011, Chip Bennett <<a href="mailto:chip@chipbennett.net">chip@chipbennett.net</a>> wrote:<br>
> Whether or not that text file is easy to read is completely irrelevant to compliance to the license under which that text file is distributed.<br>
<br>
</div>This strains the natural interpretation of "preferred form of the work<br>
for making modifications to it." It also makes the unfortunate<br>
implication that PHP obfuscators generate GPL-compatible source code.<br>
<div class="im"><br>
> How the FSF "interprets" that, or how it coincides with their "philosophy", is essentially irrelevant.<br>
<br>
</div>True: a license's real test is in court; everything outside of that is<br>
speculation. Lacking a relevant court case so far, I'm choosing to<br>
side with prima facie and the FSF and admit that our disagreement on<br>
this point seems intractable.<br>
<div><div></div><div class="h5">_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
</div></div></blockquote></div><br></div>