WordPress Theme Licensing

The WordPress community is currently having a big debate over whether themes are considered derivative works of WordPress as per the GPL, the license used by WP.  The SFLC has previously declared that they consider the PHP code in WP themes a derivative work.  Other open source CMS software makers, such as Drupal, also consider themes derivative.  Drew Blas has a thoughtful post where he compares WP themes to Linux applications and likens declaring themes as derivative the equivalent of declaring Linux applications as derivative.  I left a few comments on his post noting that a more apt comparison is with Linux Kernel Modules (LKMs) rather than applications running on top of Linux.  Linux applications are more comparable to XML-RPC clients that use WP’s XML-RPC API.  Neither Linux applications nor XML-RPC clients are considered derivative.  LKMs, however, are considered by many Linux developers to be derivative works.  LKMs load directly into the running kernel and have direct access to internal data structures and APIs.  WP themes are the same way.  They load directly into WP and have access to WP internals.  The distinction between the different classes of interactions is important when discussing the letter of the GPL as well as the general spirit in which many authors of open source software regard modules, themes, and plugins that extend their works.

I’ve not followed Linux kernel development closely for the past few years, but as far as I know the debate over LKMs never definitively resolved itself.  A system was put in place where LKMs could declare their license using a MODULE_LICENSE macro.  Licenses that are not GPL-compatible “taint” the kernel.  Many Linux developers will not assist with tainted kernels.  I doubt we would do something similar with WordPress.  Many WP developers already refuse to help with proprietary themes.  Adding some API doesn’t help clarify anything.  Unfortunately, the only thing that would is a lawsuit that goes the distance.

So, where do I stand as one of the primary copyright holders of WordPress?  I’d like to see the PHP parts of themes retain the GPL.  Aside from preserving the spirit of WordPress, respecting the open source ecosystem in which it thrives, and avoiding questionable legal ground, retaining the GPL is practical. As Drew Blas notes, the theme that sparked this debate copies WP code.  Most themes copy WP code.  Unlike the argument that all themes are derivative by nature, there is little debate that themes that copy code should retain the GPL.  Going out of your way to create a theme that does not borrow a single line of code from the WP community is wasted effort.  As attested by several theme makers who license under the GPL, the license has no affect on business. Why generate ill will by using a proprietary license?  What value is there in that?  Unlike LKMs, WP themes do not have to deal with hardware NDAs and DRM, closed source third-party code, or any of the other legal hassles that sometimes force an LKM to be closed source.  Themes live in the world of the fully open source web stack.  Since you are still free to license the CSS and images in your themes as you see fit, challenging the WP community over the license of the PHP code seems like bad business.

Bug Trackers and Professional Networking

While looking through my contact list today, I realized that many of those contacts were initially made on the WordPress bug tracker. Regular contributors to WordPress hang out there to perform the daily chores of testing, fixing, and designing. It’s a good place to get a feel for someone’s skills and style. Unlike other forums open source projects use to communicate, the noise is low and the work really stands out. The folks who consistently contribute to the bug tracker keep popping up in my feed reader and reminding me of the great work they do. When we have dollars to spend on people, these folks are on my mind. The tracker is probably my most valuable resource when it comes to professional networking with the people who do the work that matters to me.

Contributing to open source as a means of showing off your skills and making a name for yourself is nothing new, of course. My realization here is the central role the bug tracker plays in how I make and develop professional relationships within the WP community. Mailing lists, forums, and IRC channels are useful venues, but the bug tracker is where the folks who do the grunt work and get things done go.

What’s the professional water cooler for your project? Anyone else gather around the bug tracker?