WordPress Themes and the GPL – again?

NOTE: I originally wrote the bulk of this post circa February 2008 (In fact, I had to go re-load a 2.1 version of WordPress to find it – how very LiveJournal the admin console was back then) ” The discussion then was whether premium themes exist within the community / ecosystem of WordPress and what to do about theme theft / re-distribution.  Similar question(s) have come up again with the recent Thesis / GPL debate and the alternatives I suggest are no less timely now.

The GPL website FAQ does mostly addresses this concept, “If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins.”

Bryan at One Man’s Goal pondered the issues surrounding digital copyright leeching and the following quotes summarize the (then) prevaling opinions on this situation:

By designing on a GPL platform…when you release it to the public you are releasing it licensed to everyone not just those who pay for it. Companies like Redhat linux make their money not by charging for the linux o/s which is open source, but by charing for support and tweaking packages that are added to it. That’s why CentOS can directly clone what Redhat Enterprise is and not be touched.

The part of themes or plugins which makes them subject to the terms of the GPL is that they use WordPress code hooks to extract data from the WordPress database. While theme designers can SAY that their theme is licensed under some non-GPL model, they have no legal basis to do so. Someone profiting from reselling the work of another is ethically rotten, but in the current legal landscape is technically fair.

This issue of theme theft, re-selling (or conflicting business models and the GPL) comes up every couple months. This obviously sucks, but based on the current WordPress code structure and theme distribution model, there isn’t a lot which can be done – it is the nature of the beneficial beast that is working with open source licensing models. It caused me to think outside the box and ponder a different approach to resolve the problem at hand.

Distribute separate theme packages with split license

1. GPL-licensed files which include all references to WordPress logic
   This .zip archive would only contain the .php files which make up the theme – sidebar, header, index, comments, etc. These files would only have integration to css through the id / class names applied to div containers. A blog owner that deploys this package alone will have their content displayed in a reasonable approximation of the theme structure without any styles applied.
2. Images, javascript and css files licensed under whatever terms the designer wishes
   This second .zip file would contain all the elements required to convert that basic structure into the beautiful presentation shown in the theme screenshot / demo. After purchasing this set of files, the user would have to upload these into the theme directory – a process which has been proven simple enough for most blog owners to execute without issue.

What are the benefits?

• Separate downloads equals separate licenses
  This concept would be viable because of the difference the GPL affords non-dynamically linked plugins. As the visual elements could be used with any system they would not be subject to the terms of the GPL.
• Separating form from function
  Decoupling the business logic and presentation layer is a best practice which simplifies future development efforts. Developers already recognize the benefit of separating substance and style – html and css anyone? Automattic made a sound decision to separate blog operations (wp-admin) from custom functionality (plugins) and presentation (themes).
• Consistent with standard design processes
  Designers usually cut a photoshop file up into images and use a static .html template file to perfect the css with them. The non-gpl .zip file would represent this stage of design. The PHP code which uses WordPress hooks to dynamicize this template would become the GPL-licensed .zip file in effect.
• Developing architecture agnostic solutions
  With the graphics and css separated from WordPress specific code, your theme is now portable to other open source architectures: Joomla, Drupal or Expression Engine. Whether the premium designer does the work themselves or partners with someone else, they have diversified their potential markets. Including the static .html file(s) you built during the design phase and it could be sold as a generic css template as well.
• Multiple premium themes from one template
  If the css elements are well-designed it would be easy to create multiple themes from the same template. A fishing blog and could buy incremental series of graphics for ice fishing, fly fishing or bass fishing, or a seasonal treatment to a single outdoor painted scene.

I would suggest that the designers be nice, and implement a basic styles.css with the GPL code. Give the user a rough guideline based on sizes of the placeholders for where the graphics would go. Include a link in the comments at the top – which show up in the WordPress theme page – where they can / should download the graphics if they want the full effect of the premium design.

What are the problems?

• A challenge for premium theme galleries?
  The dozens of free WordPress theme galleries would not require any change, but any premium theme galleries would. One might argue that since they already have a different download process with credit card collection – it’s not like there is a high degree of learned behaviour to overcome so this isn’t that much of a problem.
• Asking users to do more in order to implement a design
  The majority of blog owners seem comfortable with the process of downloading to PC, unzipping into the wp-content/themes/ directory, uploading to server and activating, so adding a second download/unzip/upload is another non-issue of sorts I suspect. If this idea takes hold and all premium theme developers begin to adopt this process, eventually users learn that is the expected set of actions required to install a premium theme.
• A thief is a thief is a thief!
  Not much you can do about someone who has no moral issue with theft. Yet this con becomes a pro by the fact that you now have a legal recourse to sue Mr. Thiefy McStealerton as your original artistic works are not subject to the GPL but to the license you chose to make them available for purchase under.

I could only come up with one other option, which was to suggest that designers host the css / graphic files on their own servers and restrict who has access to them. Obviously this puts an external dependancy on blog performance which many would not like, but would give a more significant level of control as the styles.css file and images would be on your server. Perhaps this concept would work for WordPress.com users and the marketplace concept which Automattic has been hinted is coming in the near future.

In the 2 years since I originally wrote that article, the premium theme industry developed around a number of thriving businesses. Today, most of the theme developers who sell their wares do so entirely under the GPL. The symptoms causing the questions to be raised may have changed, but the important ones still remain:

1. Can (or will) developers distribute their work under multiple licenses which would respect the source code base license?
2. What do you do if someone does not respect the license that your product is distributed under?
3. How will this on-going conversation affect the open-source community surrounding WordPress?