Interesting discussion. Just a couple points of clarification on WLM (I’m one of the developers at WishList Products):

1. WishList Member is not developed by a single person. We have 14 full-time employees, the majority of which are developers and support staff. We also have a few part-time employees to add to that.

2. WishList Member is technically obfuscated, not encrypted. It’s probably more just semantic difference, but obfuscation means it can be reversed (as Carl pointed out).

3. WishList Member is not released under the GPL. As mentioned, while technically okay, it would be a bit silly for us to release it as GPL, but encrypt it.

As for releasing GPL vs not releasing GPL, we’ll see how this whole discussion plays out and adapt accordingly.

Speaking for myself and not the company, I personally agree with Carl that a business or developer needs to look at their own situation and make the best decision for them.

With regard to the potential dual licensing of WordPress themes (PHP under GPL and CSS/images under non GPL) and Thesis in particular, Chris Pearson is between a rock and a hard place since his customers buy Thesis not for the CSS and images but for ease of customization in adding their own CSS and images (and PHP customizations).

If GPL is enforceable at all, Chris is likely to lose. It will be down to higher level principles, not the specifics of WordPress and Thesis. I guess that Chris simply does like the idea of the GPL as he sees it as ‘inorganic’ in his organic business, and believes that, in the land of the free, WordPress should not be able to impose their view on how he should sell his own software. We may have a GPL test case on our hands in the coming months as the rhetoric on both sides shows no mood for compromise.

However, I was merely questioning the assertion that such a plugin is inherently incompatible with the GPL. I contend that it isn’t – and, like you said, using encryption on such a GPL plugin would be foolish.

@Jason: if the developer of Wish List claims that the plugin is released under GPL, then he violates his own license by not releasing the source code. Of course, as the copyright holder, he’s within his rights to do so – but in so doing, he’s not actually releasing GPL-compliant code.

Also:

1) Releasing code under GPL explicitly expresses the developer’s intent to allow users to use, modify, and redistribute his code – regardless of any implied intent of encryption.

2) The GPL is explicit that the user is completely unrestricted in his use of any code licensed under it. Thus, the user has every right, as granted by the GPL, to decrypt/unencode code released under GPL. Thus, breaking the encryption of GPL-released code is no evidence whatsoever that the user violated the license – in fact, quite the opposite. Any attempt by the developer to restrict the use of his code contradict the GPL under which he has released it.