Wouldn’t this pretty much prohibit anyone distributing commercial software for linux as well?

David’s comment also covers a common understanding between me and my clients. Even if the work for hire concept didn’t apply, I or my clients are under no compulsion to distribute the source code to anyone except those whom we choose. Nothing in the GPL gives anyone the right to demand I release my source code to them, only to the ones to whom I’m distributing it. It doesn’t grant the right for someone to be distributed to. And that’s my two cents.

Now, I anticipate that some will simply say that, under my proposal, nothing would prevent commercial vendors from circumventing the fact that core is GPL and simply using plugins to effectively fork WP without forking it.

But if they were doing this, they would have an interest in improving the core to support new features and capabilities. Chances are high that they would be contributing to the core or at least testing and reporting bugs. If you want to do a lot of things with plugins, you’ll probably contribute to the core development of WordPress–even if it is just fixing the bugs that you notice.

A better way would be to provide an alternate theming mechanism that doesn’t make the theme reliant on GPL code.

WordPress has several public APIs that spit data out of WordPress. When you interact with these APIs, you are not forming one intertwined codebase, like with a theme or a plugin. These APIs are Atom, RSS, AtomPub, and various XML-RPC APIs. You can use these APIs and be 100% outside of WordPress, with no code interdependencies. You can license the software that interfaces through those external APIs any way you like. But at that point, you’ve re-implemented a non-trivial portion of what makes WordPress WordPress. Thesis has hundreds of hook registrations and function calls and class extensions to WordPress. So it’s a lot of work to avoid the license. You’d be better off developing on another platform that doesn’t have a viral license, or just building your own platform (which I believe Chris has suggested he might do).

Maybe that’s the best solution. Chris believes that Thesis stands alone from WordPress. It doesn’t, clearly, but he could make it stand alone (assuming he gets rid of all the code that was taken from WordPress).

If you are a freelancer, however, you normally hold copyright on a theme you develop but don’t use it for your own purposes—you give it to a client under some sort of license… which is exactly what amounts to distribution.

Yes, and how exactly is this a problem? The theme goes under GPL as it is being distributed. If your client wants to distribute the theme, they also will need to do so under the GPL. The GPL only stipulates that if you distribute the software, you must also provide the source code at no more than the price of the software. Just because it’s GPL doesn’t mean that it needs to be released to the public.

Should the theme somehow include code that is owned by the client—for example to interface to one of their internal systems—that code might well be covered by the GPL, too, thus opening a can of worms of elephantine proportions: the client has gone from ordering a bunch of templates for its website to having to open-source and distribute its own proprietary code.

Why would the theme touch proprietary code? Even if it does, why would the organisation have to open-source and distribute their code? GPL doesn’t require distribution. It just means that if the organisation were to distribute their proprietary code *together with the GPL theme*, it would then have to be under the GPL.

The real issue here is actually on your end, as you’d be the one distributing code that is incompatible with the GPL. The only way around it that I can think of is providing the theme under GPL, then provide a patch separately to inject the proprietary bits.