Been hanging out with a few WordPress.org hackers — Scott, Nacin, and Otto — the last few days in a BBQ-fueled haze of hacking to make plugin directory better. There are over 19,000 plugins listed and they’re really the heart and soul of WordPress for many people, so they deserve a little tender loving care. Here’s a quick before and after snapshot you can zoom in on to see a visual overview of some of the changes:

Our first focus was around improving the discussion and support around plugins.

You’ll now notice that threads about a plugin are pulled directly into a “support” tab on the plugin page — each plugin has its own forum. We’ve made authors much more prominent and with bigger Gravatars and better placement, so you can get a sense of who made the plugin you’re using. And finally to show how active and well-supported a plugin is, you can see  ”16 of 75 support threads in the last two weeks have been resolved.” Finally, if you’re logged in you get access to the new “favorites” feature that lets you mark the plugins you use the most so you can share them on your profile page and find them quickly later. We soft-launched favorites a few days ago and there have already been 2,000 saved!

If you’re a plugin author, we’ve started with a short threshold (2 weeks) for the resolved stats so it’s easy to catch up and stay on top of it. (It’ll eventually go to two months.) You also now have the ability to set stickies on your plugin forum to put FAQs or important information at the top, and of course any person you put as a committer on the plugin will have moderation access. People on the forum tag will see your custom header and links to the other resources attached to your plugin.

We’ve tightened up the styling a bit on the forums and plugin pages, though still some cleanups to do there. Some older improvements you might have missed, but are still useful for users and developers alike:

• “Plugin headers” or those cool graphics you see at the top of plugin pages have really taken off, there are over 1,600 active now.
• You can now subscribe to get an email whenever a commit is made to a plugin repository even if it isn’t yours. There is no better way to follow the development of your favorite plugins. There’s nothing like the smell of fresh changesets in the morning.
• Behind the scenes, we’ve dramatically ramped up proactive scanning of the entire repository to help authors fix security and other problems they might not even know about yet. The quality level of the repo has gone way, way up.

All of this will continue to evolve as we get feedback and see usage, but we’re happy to have been able to make some key improvements in just a few days while hanging out in Memphis. (This is why WordCamps usually have BBQ — it imparts magical coding powers.)

This has been an exciting year for WordPress. We’ve grown to power 14.7% of the top million websites in the world, up from 8.5%, and the latest data show 22 out of every 100 new active domains in the US are running WordPress.

We also conducted our first ever user and developer survey, which got over 18,000 responses from all over the world:

We found a few interesting tidbits from the survey responses already, including that 6,800 self-employed respondents were responsible for over 170,000 sites personally, and charged a median hourly rate of $50. In tough economic times, it’s heartening to see Open Source creating so many jobs. (If each site took only 3 hours to make, that’s $29.5M of work at the average hourly rate.)

I talk about this data, and much more, in my State of the Word address which you can watch here:

We know there’s more good stuff hidden in there and we’re open sourcing and releasing the raw information behind it. If you’re a researcher and would like to dig into the anonymized survey data yourself, you can grab it here. (Careful, it’s a 9MB CSV.)

There has never been a better time to be part of the WordPress community, and I want to thank each and every one of you for making it such a wonderful place to be. Now it’s time to get back to work, there’s still 85.3% of the web that needs help.

If WordPress were a country, our Bill of Rights would be the GPL because it protects our core freedoms. We’ve always done our best to keep WordPress.org clean and only promote things that are completely compatible and legal with WordPress’s license. There have been some questions in the community about whether the GPL applies to themes like we’ve always assumed. To help clarify this point, I reached out to the Software Freedom Law Center, the world’s preeminent experts on the GPL, which spent time with WordPress’s code, community, and provided us with an official legal opinion. One sentence summary: PHP in WordPress themes must be GPL, artwork and CSS may be but are not required.

Matt,

You asked the Software Freedom Law Center to clarify the status of themes as derivative works of WordPress, a content management software package written in PHP and licensed under version 2 of the GNU General Public License.

We examined release candidate 1 of WordPress 2.8, which you provided to us at http://wordpress.org/wordpress-2.8-RC1.tar.gz. The “classic” and “default” themes included in that release candidate comprise various PHP and CSS files along with an optional directory of images. The PHP files contain a mix of HTML markup and PHP calls to
WordPress functions. There is some programmatic logic in the PHP code, including loops and conditionals.

When WordPress is started, it executes various routines that prepare information for use by themes. In normal use, control is then transferred via PHP’s include() function to HTML and PHP templates found in theme package files. The PHP code in those template files relies on the earlier-prepared information to fill the templates for serving to the client.

On the basis of that version of WordPress, and considering those themes as if they had been added to WordPress by a third party, it is our opinion that the themes presented, and any that are substantially similar, contain elements that are derivative works of the WordPress software as well as elements that are potentially separate works. Specifically, the CSS files and material contained in the images directory of the “default” theme are works separate from the WordPress code. On the other hand, the PHP and HTML code that is intermingled with and operated on by PHP the code derives from the WordPress code.

In the WordPress themes, CSS files and images exist purely as data to be served by a web server. WordPress itself ignores these files[1]. The CSS and image files are simply read by the server as data and delivered verbatim to the user, avoiding the WordPress instance altogether. The CSS and images could easily be used with a range of HTML documents and read and displayed by a variety of software having no relation to WordPress. As such, these files are separate works from the WordPress code itself.

The PHP elements, taken together, are clearly derivative of WordPress code. The template is loaded via the include() function. Its contents are combined with the WordPress code in memory to be processed by PHP along with (and completely indistinguishable from) the rest of WordPress. The PHP code consists largely of calls to WordPress functions and sparse, minimal logic to control which WordPress functions are accessed and how many times they will be called. They are derivative of WordPress because every part of them is determined by the content of the WordPress functions they call. As works of authorship, they are designed only to be combined with WordPress into a larger work.

HTML elements are intermingled with PHP in the two themes presented. These snippets of HTML interspersed with PHP throughout the theme PHP files together form a work whose form is highly dependent on the PHP and thus derivative of it.

In conclusion, the WordPress themes supplied contain elements that are derivative of WordPress’s copyrighted code. These themes, being collections of distinct works (images, CSS files, PHP files), need not be GPL-licensed as a whole. Rather, the PHP files are subject to the requirements of the GPL while the images and CSS are not. Third-party developers of such themes may apply restrictive copyrights to these elements if they wish.

Finally, we note that it might be possible to design a valid WordPress theme that avoids the factors that subject it to WordPress’s copyright, but such a theme would have to forgo almost all the WordPress functionality that makes the software useful.

Sincerely,
James Vasile
Software Freedom Law Center

[1] There is one exception. WordPress does reads CSS and image files to create previews of templates for the template selection portion of the administrative interface. Even in that case, though, nothing in those files calls any WordPress functions, is treated as a command by PHP, or alters any other WordPress data structure. These files are read as data and used to create an image and display a miniaturized version of a webpage to the user.

Even though graphics and CSS aren’t required to be GPL legally, the lack thereof is pretty limiting. Can you imagine WordPress without any CSS or javascript? So as before, we will only promote and host things on WordPress.org that are 100% GPL or compatible. To celebrate a few folks creating 100% GPL themes and providing support and other services around them, we have a new page listing GPL commercially supported themes.

If WordPress were a country, our Bill of Rights would be the GPL because it protects our core freedoms. We’ve always done our best to keep WordPress.org clean and only promote things that are completely compatible and legal with WordPress’ license. There have been some questions in the community about whether the GPL applies to themes like we’ve always assumed. To help clarify this point, I reached out to the Software Freedom Law Center, the world’s preëminent experts on the GPL, which spent time with WordPress’ code, community, and provided us with an official legal opinion. One sentence summary: PHP in WordPress themes must be GPL, artwork and CSS may be but are not required.

Matt,

You asked the Software Freedom Law Center to clarify the status of themes as derivative works of WordPress, a content management software package written in PHP and licensed under version 2 of the GNU General Public License.

We examined release candidate 1 of WordPress 2.8, which you provided to us at http://wordpress.org/wordpress-2.8-RC1.tar.gz. The “classic” and “default” themes included in that release candidate comprise various PHP and CSS files along with an optional directory of images. The PHP files contain a mix of HTML markup and PHP calls to
WordPress functions. There is some programmatic logic in the PHP code, including loops and conditionals.

When WordPress is started, it executes various routines that prepare information for use by themes. In normal use, control is then transferred via PHP’s include() function to HTML and PHP templates found in theme package files. The PHP code in those template files relies on the earlier-prepared information to fill the templates for serving to the client.

On the basis of that version of WordPress, and considering those themes as if they had been added to WordPress by a third party, it is our opinion that the themes presented, and any that are substantially similar, contain elements that are derivative works of the WordPress software as well as elements that are potentially separate works. Specifically, the CSS files and material contained in the images directory of the “default” theme are works separate from the WordPress code. On the other hand, the PHP and HTML code that is intermingled with and operated on by PHP the code derives from the WordPress code.

In the WordPress themes, CSS files and images exist purely as data to be served by a web server. WordPress itself ignores these files[1]. The CSS and image files are simply read by the server as data and delivered verbatim to the user, avoiding the WordPress instance altogether. The CSS and images could easily be used with a range of HTML documents and read and displayed by a variety of software having no relation to WordPress. As such, these files are separate works from the WordPress code itself.

The PHP elements, taken together, are clearly derivative of WordPress code. The template is loaded via the include() function. Its contents are combined with the WordPress code in memory to be processed by PHP along with (and completely indistinguishable from) the rest of WordPress. The PHP code consists largely of calls to WordPress functions and sparse, minimal logic to control which WordPress functions are accessed and how many times they will be called. They are derivative of WordPress because every part of them is determined by the content of the WordPress functions they call. As works of authorship, they are designed only to be combined with WordPress into a larger work.

HTML elements are intermingled with PHP in the two themes presented. These snippets of HTML interspersed with PHP throughout the theme PHP files together form a work whose form is highly dependent on the PHP and thus derivative of it.

In conclusion, the WordPress themes supplied contain elements that are derivative of WordPress’s copyrighted code. These themes, being collections of distinct works (images, CSS files, PHP files), need not be GPL-licensed as a whole. Rather, the PHP files are subject to the requirements of the GPL while the images and CSS are not. Third-party developers of such themes may apply restrictive copyrights to these elements if they wish.

Finally, we note that it might be possible to design a valid WordPress theme that avoids the factors that subject it to WordPress’s copyright, but such a theme would have to forgo almost all the WordPress functionality that makes the software useful.

Sincerely,
James Vasile
Software Freedom Law Center

[1] There is one exception. WordPress does reads CSS and image files to create previews of templates for the template selection portion of the administrative interface. Even in that case, though, nothing in those files calls any WordPress functions, is treated as a command by PHP, or alters any other WordPress data structure. These files are read as data and used to create an image and display a miniaturized version of a webpage to the user.

Even though graphics and CSS aren’t required to be GPL legally, the lack thereof is pretty limiting. Can you imagine WordPress without any CSS or javascript? So as before, we will only promote and host things on WordPress.org that are 100% GPL or compatible. To celebrate a few folks creating 100% GPL themes and providing support and other services around them, we have a new page listing GPL commercially supported themes.