There’s an aspect to WordPress that most newcomers either don’t notice or don’t care about and that’s the licensing model - GPL. Many developers fear that this licensing model enables what they think of as theft of their work, when in reality it is not. This article will hopefully get you more interested in WordPress’s license (GPL) and it’s implications.

What is GPL

Short for GNU Public license (written by Richard Stallman), GPL (version 2) is the license WordPress is released under. It grants end users (both people and organisations) the rights to:

  • run the software in any way they like
  • inspect and study the software
  • modify the software
  • redistribute the original or modified software

This means GPL is a free software license, which many confuse with being free from a monetary aspect. This is not the case, however. Free here simply means you have the freedom to do with it whatever you like - it does not refer to how you’ve obtained it or how much it should cost, which is why the list above is sometimes referred to as the four freedoms.

There’s a gotcha many don’t realize (and is important here on Codeable as well): GPL only applies to work that is distributed. This means when you do work for a client on a custom, 1-off theme, they are not required to comply with GPL.

Wikipedia has a good article on GPL if you’re interested in learning more.

What is (and isn’t) derivative work

As per Wikipedia, derivative work is an expressive creation that includes major copyright-protected elements of an original, previously created first work.

There’s no ambiguity when it comes to the PHP code of WordPress plugins and themes being derivative works of WordPress, which means they must be licensed under GPL. Visual elements and fronted functionality (Javascript) could be considered separately, under a more restrictive license (called split-licensing, more on that at the end of this article).

That’s primarily because a theme won’t functionally work if you take WordPress out of the picture, but it could visually work when applied to another CMS or as a standalone solution. Matt Mullenweg explains that while that may be the case, it’s always encouraged that the whole package is 100% GPL even if the creative/artwork part could be licensed otherwise - it’s ethically wrong to rely on a free software and restrict usage on some parts at the same time.

Think of it like this: If WordPress (or any other content management system) didn’t exist in the first place, we’d have to pay thousands upon thousands of dollars for developers to build custom systems for every single website. They are already in high demand (expert developers, that is) as it is, so I’m sure you’ll agree when I say that Open Source (and its licenses) move the tech world forward.

Lastly, an external service that connects to WordPress (via JSON or XML-RPC) is not considered derivative work, though - they can most often function without it just fine.

If you’d like to learn more about derivative work and WordPress, Richard Best released a great, in-depth article about it a couple of months ago.

What is being sold then?

Most developers are reluctant to distribute their code (premium plugins in particular) because they feel threatened by the fact that every client is legally able to re-distribute (and re-sell) their plugins and themes. This is why most developers resort to two solutions:

  • split licensing (more on that shortly)
  • support and update licensing

When you buy a premium plugin, you usually get a license key that you enter in the plugin options screen. This is how the developer knows you’ve purchased their plugin from them and that you are eligible for support and updates when needed/available. This kind of licensing is usually time-based, meaning that you get support and updates for a certain period, usually a year (there are plugins that do it on a monthly basis). They don’t stop working when the license expires - you’re just not eligible for support and updates after that.

And truth be told, updates are a very important aspect of any plugin since security vulnerabilities are discovered constantly and if you don’t update your plugins, you are at risk of being attacked (hacked). In most countries you are legally responsible for your website (and what it does) so the risks of running an insecure plugin are very real. And big too - Sucuri Security discovered malware that infected more than 100,000 WordPress sites due to use of an outdated Revolution Slider plugin (sold on ThemeForest).

While you may be able to obtain and use a copy of a plugin (or theme) through channels other than the official developer’s website, it might do you more harm than good in the long run.

If you’re a developer, on the other hand, make sure you explain the benefits of paying for a plugin on your website. Or better yet, explain the risks of not doing so. Fear is a stronger emotion than desire.

On split licenses

WordPress (or rather GPL) does require your derivative work to be GPL licensed, but, as I explained earlier, only PHP and HTML is considered to be derivative, which is why some authors decide to release the work under split (dual) licenses; Javascript, CSS and images are released under a more restrictive license which prevents the user to re-distribute it or only use it on one website.

This sparked a lot of controversy over the years, especially since Envato (the company behind ThemeForest) used this model quite extensively. Some of the authors there were even banned from speaking at WordCamps because the WordPress Foundation (and its founder Matt Mullenweg) encourages WordPress plugins to be 100% GPL-compliant, not just parts of them.


This isn't a comprehensive guide to WordPress GPL but hopefully I've given you enough food for thought to investigate further if you're interested in the topic. I'm by no means an expert on the matter, so if you have any suggestions or remarks, feel free to leave a comment below.Quality: The Codeable Differene

  • texelate

    Great article, I find GPL confuses people, myself included. IANAL but I think you’d need a contract to say that it’s work for hire as in US, UK, etc the developer owns the copyright by default. So by default you’d be licensing to the client and any changes you make (including themes) would be infected by GPL – and you’d have to publish the source.

    If I’m right, when using GPL server-side you should have a work for hire contract. Of course, this is no doubt one if those laws that everyone breaks. Plus you lose copyright on the work.

    I don’t like GPL, the idea behind it is good but they need to be clearer on what constitutes distribution.

    GPL is a terrible license for front end code but people choose it because they just see it as open source. LGPL or MPL are much better if you want all changes to be open source. I will always ask the dev for an exception before using front end GPL.

  • Pingback: URL()

  • Pingback: Durban City()

  • Pingback: Canada web hosting()

  • Pingback: Shaker Bottle()

  • Pingback: dentist profession()

  • Pingback: Anonymous()

  • Pingback: ancient greece tools()

  • Kevin Christopher Foster

    There’s no ambiguity when it comes to the PHP code of WordPress plugins and themes being derivative works of WordPress

    This simply isn’t true. A simple search will show you that there is tons of ambiguity and confusion on this. Even wordpress admits this is a “Legal Grey Area”.