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.

2.8 Plugin Compatibility

Some plugins are causing grief for those upgrading to 2.8.

  • HyperDB needs to be updated to the latest version, otherwise tags won’t save.
  • DB Cache also prevents tags from being saved. I haven’t seen an update for it yet.
  • Plugins that load old versions of jQuery for all admin pages will break all kinds of stuff.  Plugins should use the version of jQuery that ships with WP.  If a plugin must use a particular version of jQuery, that version should be queued only for the plugin’s own pages.
  • Themes that call get_categories() from functions.php before the init action fires will fail.  2.8.1 will workaround this, but ideally these themes should update so that they can handle custom taxonomies properly.

Auto Upgrading to Nightly Builds

WP’s automatic upgrade can be used to automatically upgrade to betas and nightly builds for the development branch or the latest stable branch.  To get onto a development upgrade path you must first make a small change to wp-includes/version.php.

The current release of WP is 2.8.  If you peek in the version.php file, you will see this:

$wp_version = '2.8';

If you would like to try out the latest development builds for the upcoming 2.8.1 release, change that line to this:

$wp_version = '2.8.1-dev';

“dev” can be any string. The presence of a suffix on the version tells the automatic upgrade to put you on the upgrade path for 2.8.1 development releases. You will be able to automatically upgrade to each nightly, beta, and RC build for 2.8.1. Once the final 2.8.1 release comes out, automatic upgrade will upgrade you to that official release and put you back on the stable release path. To get back on the 2.8 development branch upgrade path after the release of 2.8.1, you would have to change your version to “2.8.2-dev”.

If you are feeling really experimental, you can get on the 2.9 development path by setting the version to “2.9-dev”. Unlike the 2.8 development path which contains only fixes to high-impact bugs, the 2.9 path is where new feature development is happening. You probably want the 2.9 path only if you are a developer.

Update: Peter wrote a plugin that makes this easier.

WordPress Bits

2.7.1 is out, improving upon a solid 2.7 release.

The next version of the iPhone app is almost out and features comment moderation.

2.8 is well underway.  So far there have been lots of script loading and DB performance improvements.  The first cut of the theme installer is in, and the redesign of the Widgets admin UI is beginning.  Custom tag taxonomies now have some built-in admin UI,  and proper timezone and DST support is available if you are running PHP 5.

WordPress 2.7.1 Beta 1

2.7.1, the first 2.7 maintenance release, is almost ready.  So far, 66 tickets are fixed in 2.7.1.  There are another 50 tickets open against the 2.7.1 milestone, but most of those will be moved to 2.7.2 or 2.8.  If there are tickets in that list you would really like to see fixed in 2.7.1, drop a comment.

To automatically upgrade from 2.7 to 2.7.1 Beta 1, change the version in your wp-includes/version.php file from 2.7 to 2.7.1-beta and then visit Tools->Upgrade.  Otherwise, download the beta package and install manually.

WordPress 2.7

Finally, at last, it’s here.  And now, on to 2.8.  There were several areas that we didn’t have time to re-design for 2.7.  2.8 will focus on making the media and widgets UI as good as the rest of WP.  There will be a few new features as well.  Theme browsing and one-click theme install is a likely one.  After a short rest to recover from 2.7, we’ll start brainstorming new features and put the results on the 2.8 codex page.

We’ll likely do the usual .1 release in a month to address any bugs that slipped through the 2.7 beta testing cycle.

A lot of people contributed to 2.7, but I’d like to give a few thank yous in particular.

Jane for the UX, the wire frames, and for all of the help with managing this release.  Matt for the great visual design.  DD32 for the upgrade and install work, file system abstraction, and all of the bug fixing.  Jacob for the HTTP API and all of that phpdoc.  Aaron for quick edit. Austin for the many bug fixes and for getting the flash uploader working with Flash 10. Mike for the dashboard. Peter, Mark, and Andrew for being kick ass lead devs who put in a lot of thought, love,  and hours.  And Matt for bringing all of these great people together.

Hear that 2.7 a Comin'

As announced on the wordpress.com blog, 2.7 is coming to wordpress.com tomorrow.  Actually, 2.7 has been running on wordpress.com for awhile, just not the exciting new admin UI.  Here’s a peek at what the admin will look like on wordpress.com.

WordPress.com 2.7 Preview

The final release of 2.7 won’t be here until next week. There is still a lot of coordination and management type stuff to do before we’re ready to release.

2.7 Beta 1

We’ve been working our asses off and finally have a beta to share.  Download, test, and enjoy the pretty visuals.  The word most people use when first seeing it is “sexy”.   This is a great design, and I’m very pleased with how it has turned out.  When the visuals are complete and the new icons are in, 2.7 will be a very good looking release.

Try this exercise.  Load up the Write Post page in 2.6 and in 2.7.   Compare the location of the title field between the two.  Notice the vertical distance.  That’s one of my favorite 2.7 features.