Rdio and Spotify oEmbed Support in WordPress 3.6

In an effort to make the new Audio Post Format UI more useful, we added Rdio and Spotify to the default oEmbed providers list for WordPress 3.6. Spotify and @nicklas2k were kind enough to whip up an oEmbed endpoint for us to use. Thanks!

To celebrate, here are a couple of albums released in 2013 that I’m enjoying.

http://rd.io/x/QUtUHiJ05Hg/

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.