Introduction

“I wish this stuff could be easier!”

Have you ever found yourself saying or thinking this or otherwise cursing the ins and outs of applying the GPL to your themes or plugins? Have you ever been worried that, perhaps, you’re not doing what the GPL requires or that you’ve overlooked a WordPress.org requirement? From a wide range of stories and comments I’ve seen around the web, I think Jamie’s story is one that rings true for many. So, if you’ve answered yes to one of these questions, you’re far from being alone and this post is for you.

“How do I apply and comply with the GPL correctly?”

If you feel this way, it’s not surprising. Indeed, if you’re only just getting into open source or releasing your first theme or plugin, I’d say it’s to be expected. I say that because not only do you need to understand a legally-oriented copyright licence but, if you wish to make your products available on WordPress.org, you also need to get to grips with the WordPress.org theme and plugin guidelines. And if you want to make free versions available on WordPress.org and commercial versions available elsewhere, you need to understand what is and isn’t allowed.

The key question you may ask is: “how do I apply and comply with the GPL correctly, from the perspective of what the GPL requires and, where relevant, from the perspective of what WordPress.org requires?” In this post I’m going to try to answer that question in detail. The goal is to provide a comprehensive resource for those who ask this very question. The post:

• sets the scene with a quick primer on copyright and licensing;
• provides some basic context on copyright and licensing statements;
• summarises the key requirements of the GPL;
• explains how to apply the GPL, looking at the Free Software Foundation’s recommendations, what often happens in practice, suggested approaches and requirements on WordPress.org for both themes and plugins, and the importance of not forgetting to retain pre-existing copyright notices and to acknowledge other sources to the extent required; and
• discusses the question of free 100% GPL licensing and commercial split licensing.

Sample licensing text is provided throughout the post to help you hit the ground running. I’ve also built a GPL Engine that you can use to generate legally sound content for:

• your style.css, readme and licence files for your theme folder; or
• your plugin file header, readme and licence files for your plugin folder.

If you want to jump straight to the GPL Engine, it’s at the end of the post.

A quick primer on copyright and licensing

Before getting stuck into the practical stuff, I think it helps to understand some basics about copyright and licensing. Sure, many people understand the basics, but there are probably just as many who don’t. I’ll keep it brief.

Copyright is an intellectual property right created by the laws of a given country that confers, on the copyright owner, exclusive rights to do certain things with an original work (such as a book or an audio recording). The exclusive rights include copying the work and modifying the work. If a person does something that interferes with the copyright owner’s exclusive rights, that person infringes copyright unless he or she has a defence that is recognised by the governing law.

In most countries software qualifies as a kind of copyright work. International copyright treaties usually use the term “computer program” and state that computer programs are to be protected as literary works. (International copyright treaties lay down minimum requirements that contracting countries are required to reflect in their national laws.)

Software licences, whether open source or proprietary, exist to enable people to do things with software that they would not otherwise be entitled to do given the copyright owner’s exclusive rights. Open source licences, in particular, exist to enable anyone who obtains a copy of the licensed software to use, copy, modify and distribute the software as long as they comply with the licence’s requirements. The GPL is one of the most well known and widely used open source software licences and it’s the licence under which WordPress itself is licensed.

Copyright and licensing statements for open source software

Copyright and licensing statements for open source software generally comprise:

• a statement of copyright ownership; and
• a description of the licence that applies to the software.

They appear in the same place but I’ll consider them separately here to explain a couple of points.

The copyright notice

When applying an open source software licence, it is common practice to add the year the software was completed and the name of the copyright owner(s), in the following format:

Copyright (c), [name(s) of copyright owners]

Description of the applicable licence

The description of the licence that applies to the software either sets out the full terms of the licence or refers to the applicable licence and links to the full text of the licence (to some extent the preferable approach may depend on the particular open source licence in question). The description may also contain statements that exclude warranties and liabilities. (You’ll see examples later in this post.)

A quick recap on the GPL’s freedoms and requirements

Because this post is all about applying the GPL, it may also help to provide a quick recap on the GPL’s freedoms and requirements.

In a previous post, “A human readable summary of the GPL?“, I set out two summaries of the GPL. One of them follows the sequence of the GPL itself and the other takes more of a Creative Commons ‘human readable summary’ approach. Here are the two summaries.

The sequential summary

Here’s a PDF of this page if you’d like it.

The Creative Commons-style ‘human readable’ summary

Here’s a PDF of this summary if you’d like it.

With all that context behind us, we can now move on to address the main topic which is how to apply the GPL.

How to apply the GPL

Free Software Foundation’s recommendations

The Free Software Foundation (FSF) is a non-profit with a worldwide mission to promote computer user freedom. It’s also the publisher of the GPL.

On the topic of applying the GPL, the FSF recommends that notices be attached “to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the ‘copyright’ line and a pointer to where the full notice is found”, along these lines:

What often happens in practice

This suggested approach is commonly not followed in the sense that commonly the notices are added to a single or primary file, or a small number of files, as opposed to all files. This is due, no doubt, to the large number of distinct files that often comprise a single software package and the nuisance factor in adding the notices to each file.

Where this approach is taken and a single file that doesn’t contain the copyright and licensing statement is separated from the rest, there’s a risk that a user of the code won’t know:

• where it came from;
• who owns the copyright; and
• what permissions he or she has.

I doubt, however, that this is much of a practical problem in the WordPress space.

Suggested approaches and requirements on WordPress.org

Introduction

If you wish to have a theme or plugin listed in the WordPress.org theme or plugin repository, paying attention to the approaches to licensing and complying with the requirements for licensing set out on WordPress.org is important. In the case of themes, for example, missing copyright and licensing information has been cited as one of the most common reasons for non-acceptance of a theme into the repository (see, e.g., Carolina Nymark’s post of 29 September 2016 Incomplete theme submissions).

I now turn to look at the requirements for both themes and plugins. For each, I set out the WordPress.org requirements and then provide examples of the form in which those requirements can be and are commonly met.

Themes

Requirements

The Theme Handbook includes the following licensing requirements:

Licensing

Be 100% GPL and/or 100% GPL-compatible licensed.

Declare copyright and license explicitly. Use the license and license uri header slugs to style.css.

Declare licenses of any resources included such as fonts or images.

All code and design should be your own or legally yours. Cloning of designs is not acceptable.

Be careful of GPL-compatibility

As to the first item, you can’t read the words “and/or 100% GPL-compatible licensed” too literally. On the prevailing view in the WordPress community, in most cases a theme cannot be 100% licensed under a GPL-compatible licence. The prevailing view is that the GPL itself has to apply to at least some of it. This is because a theme’s PHP files are generally considered to be derivative of WordPress code and need, therefore, to be licensed under the GPL.

Even if you don’t agree with this, if you’re using files from themes that themselves have been released under the GPL, such as Underscores, and are creating a derivative work, the GPL requires you to release your derivative work under the GPL when you distribute it.

The GPL-compatibility point is usually only relevant to other assets in a WordPress theme that are not themselves already licensed under the GPL and are not derivative of GPL-licensed code. Under the Theme Handbook requirements, those other assets need to be licensed under the GPL or a licence that is compatible with the GPL if the theme is going into the theme repository. This is a matter of WordPress.org policy.

Add licensing information to your style.css file

As to the second item (“Declare copyright and license explicitly. Use the license and license uri header slugs to style.css”), what it’s saying is: use license and license URI header slugs in your style.css file to state the copyright and licensing of your theme. This is a requirement for acceptance of a theme into the WordPress.org repository and is something the theme check plugin (used for the preliminary vetting of themes submitted to WordPress.org) seems to look for.

Declaring the licensing of third party resources

Note that the third item (“Declare licenses of any resources included such as fonts or images”) doesn’t state expressly that you should put this information in your style.css file (as opposed to, for example, putting it in a readme file). I have seen several themes that do use third party resources but, instead of declaring them in the style.css file, they cover them in a readme file. I suggest it’s preferable that they be covered in both places (I discuss readme files and acknowledging third party resources in more detail below).  If your style.css file only covers your own licensing when you have, in fact, based your theme on another theme or used third party assets, then the style.css file could give an incomplete or misleading picture of the make-up and licensing of your overall theme. The GPL Engine I’ve built puts this information into both the style.css file and the readme file.

Form

Here’s an example of a compliant style.css file. It’s the first part of the style.css file for the Twenty Sixteen theme:

As an aside, it’s not uncommon to find commercial themes including the licensing information in a separate license or readme file and not in the style.css file (licence and readme files are discussed further below). From a GPL perspective, that’s fine, but if you’re submitting a theme to the WordPress.org repository you should include the information in the style.css file.

Plugins

Requirements

At the date of writing, the Detailed Plugin Guidelines on WordPress.org (which were updated on 3 November 2016) stated:

1. Plugins must be compatible with the GNU General Public License v2, or any later version, to be hosted on WordPress.org.

Though any GPL-compatible license is acceptable, using the same license as WordPress — “GPLv2 or later” — is recommended. All code, data, and images — anything stored in the directory — must comply with the GPL (any version, two or later), regardless of their creator. Included third-party libraries must also be compatible. For a specific list of compatible licenses, please read the GPL-Compatible license list on gnu.org.

I truly don’t mean to be pedantic but these paragraphs could lead people into error. To the extent that a plugin is truly a derivative work of pre-existing GPL-licensed code (e.g., another GPL-licensed plugin), that derivative work must be licensed under the GPL itself upon distribution. If you purport to license a true derivative of a GPL-licensed work under a different licence, you’ll be breaching the GPL (which means your right to use the GPL-licensed code will end and you’ll be infringing copyright). The GPL does not allow you to license a derivative of a GPL-licensed work under a GPL-compatible licence. As with a similar statement relating to themes (see above), from a legal perspective, the reference to GPL compatibility should only be read as referring to elements of the plugin that are not already GPL-licensed and elements that are not derived from GPL-licensed code (in some cases that might be everything in the plugin but in others it won’t be). Those elements can be licensed under a GPL-compatible licence and, under the Plugin Guidelines, need to be.

Form

As noted in the Plugin Handbook on WordPress.org:

At its simplest, a WordPress plugin is a PHP file with a WordPress plugin header comment. It’s recommended that you create a directory to hold your plugin. Only one file in the plugin’s folder should have the header comment.

The Handbook states that, “[a]t a minimum, a header comment must contain the Plugin Name, but several pieces can – and usually should – be included”. Those additional pieces are Plugin URI, Description, Version, Author, Author URI, License, License URI, Text Domain and Domain Path. Our focus here is on the License and License URI.

The Handbook gives this example of a valid header comment:

As you can see, the header contains a brief reference to GPL2 and a link to the full licence. It doesn’t replicate the exclusion of warranty as recommended by the Free Software Foundation but the exclusion of warranty is contained in the GPL itself and the absence of it here is not likely to pose any problem in practice.

That said, the Plugin Handbook provides further guidance on “including a software licence“, noting that “another common, and encouraged, practice is to place a license block comment near the top of your main plugin file (the same one that has the plugin header comment)”. It gives this example:

Choosing this longer form is unlikely to make much difference in practice but I suggest it’s preferable because it provides a (very) short summary of the GPL freedoms and includes the exclusion of warranties. If I were releasing WordPress products under the GPL it’s the approach I’d probably adopt but, as I say, in practice it probably makes little difference. Some developers adopt the short form approach (e.g., Elegant Themes’ Monarch plugin) while others adopt the longer form approach (e.g., Rocketgenius’s Gravity Forms).

What about readme and licence files in addition to the theme style.css file or plugin file header?

Themes

As at the date of writing this post, the Theme Review Handbook included (in its Review > Recommended > Documentation section) a list of recommendations for documentation. That list includes the statement:

A readme.txt file can be included.

Whilst this is stated as a recommendation, it is common practice to include a readme.txt file and it seems that inclusion of a readme.txt file is one of the things the theme check plugin looks for.

Developers often include licensing information in the readme file, as well as other information relevant to the theme. At least in relation to themes for the WordPress.org theme repository, this has become something of a community norm.

Set out below is an example readme.txt file, from the Twenty Sixteen theme. As you can see:

• upfront, it includes summary licensing information that’s similar to what one sees in the style.css file; and
• later on, it includes a distinct “Copyright” section that contains the standard GPL copyright and licensing statement that I mentioned earlier in this post as well as information on bundled third party resources (I discuss third party resources in more detail later on in this post).

Here it is:

Some choose to keep the licensing information in a separate license.txt or licensing.txt file. Personally I think it’s clearer to call a spade a spade and include licensing information in a license.txt or licensing.txt file (in addition to complying with other WordPress.org requirements) but a sizeable number of developers appear to put this information in the readme file. That’s not surprising as it’s something of a WordPress community norm. And to be clear, I don’t think there’s any problem with this approach because, if someone is looking for licensing information and can’t see a licensing.txt file, they’re going to read the readme file. The GPL Engine (below) follows the WordPress.org approach.

Plugins

At the date of writing, the Plugin Handbook stated:

“To make your entry in the plugin browser most useful, each plugin should have a readme file named readme.txt that adheres to the WordPress plugin readme file standard. You can use the plugin readme generator and put the result through the readme validator to check it.”

The WordPress plugin readme file standard includes slugs for ‘License’ and ‘License URI’.

To make life easier, the Plugin Handbook also provides links to various plugin ‘boilerplate starting points’ that contain readme and license files. The first two, WordPress Plugin Boilerplate and WordPress Plugin Bootstrap, both contain good readme.txt files (that have summary licensing entries) and license.txt files (that contain the full text of the GPL). They are both licensed under the GPL.

This is the template readme.txt file from the WordPress Plugin Boilerplate (with a very minor tweak I made in October 2016). As noted above, it’s distributed under the GPL so feel free to enjoy your freedoms and use it:

Don’t forget to retain pre-existing copyright notices and to attribute other sources to the extent required

So far I’ve really only been talking about including the requisite copyright and licensing statements in relation to theme and plugin contents the developer has written. I’ve mentioned the inclusion of third party assets but haven’t indicated how to acknowledge them. Developers do, of course, often use pre-existing assets in their themes and plugins, whether in the form of code files (full or partial) or other assets such as fonts or images, so this topic will often be relevant.

As noted earlier in this post:

• if you distribute a GPL-licensed program, you must publish on each copy of the program an appropriate copyright notice and disclaimer of warranty, keep intact all notices that refer to the GPL and the absence of any warranty, and give recipients a copy of the GPL along with the program; and
• if you modify GPL-licensed files, the modified files need to contain notices regarding the existence and date of changes.

Attribution when basing your theme or plugin on an existing GPL-licensed theme or plugin

If you’re basing your theme or plugin on an existing GPL-licensed theme or plugin, you will in all likelihood be creating a derivative work. Let’s say, for example, that you’ve developed a theme called Awesome Theme based on Automattic’s Components. In that case, you could include this kind of statement in a ‘Credits’ or ‘Acknowledgements’ or ‘Attribution’ section in your readme.txt or license.txt file:

Or, if you want to use more of a narrative tone, you could say something like:

(The words “based on” are essentially the same as “derived from” but are, I think, plainer English and easier to understand.)

Including chunks of GPL’d code in your own theme or plugin files

If you’re including a substantial part of someone else’s GPL-licensed file in your own theme or plugin files, you should acknowledge that, preferably in the header to the relevant file or in inline non-code comments and, in any case, in a broader readme.txt or license.txt file in your theme or plugin folder. If you’ve modified that code, you should note that too. The following example is based on an example in Chip Bennett’s very useful article on WordPress.org, Proper Copyright/License Attribution for Themes:

Bundled third party resources

Chip also refers to bundling third party resources, such as script libraries, CSS frameworks, images, fonts, etc. The notion of ‘bundling’ is a good one, in my view, and it is commonly used in readme.txt and license.txt files.

‘Bundling’ is apt to describe third party resources that are used for a theme or plugin but which are not caught by the GPL licensing requirements that will often apply to (for example) the GPL-licensed PHP files (i.e., those files will often need to be licensed under the GPL because they’re derivative of pre-existing GPL-licensed code).

To explain this, it may help to recap on how the GPL deals with independent and aggregated works. Whilst derivative works of GPL-licensed programs need to be licensed under the GPL, the GPL itself makes it clear that:

• if identifiable sections of the overall work are not derived from the GPL-licensed program and can be considered independent and separate works in themselves, then the GPL does not apply to those sections when you distribute them as separate works; and
• mere aggregation of another work not based on the program with the program (or with a work based on the program) on a volume of a storage or distribution medium does not bring the other work under the scope of the GPL2.

So what do these two points mean in practical terms? They mean that not necessarily everything in your plugin or theme folder is required to be licensed under the GPL, even if the core PHP files, for example, are derivative of GPL-licensed code and do need to be GPL-licensed, and this is why you can bundle third party resources in your distribution, such as images or fonts, that have been licensed under alternative licences.

To give an example, let’s say I’ve used a base theme like Underscores for my own theme, but I’m also using a range of third party resources like images and fonts, that were not in the original Underscores distribution. Well, if those bundled resources can be considered independent or merely aggregated as mentioned above (which I suggest will usually be the case and is consistent with the SFLC opinion mentioned above), then you can use them together with the GPL’d code even if the third party owners have licensed them under a different licence.

But, and this is the key point for present purposes, you still need to comply with the copyright notice or attribution requirements of the licences that apply to those bundled resources.

The readme.txt file for the Twenty Sixteen theme provides an example of how you might go about acknowledging or attributing bundled resources. I’ve reproduced the whole copyright section (it’s licensed under the GPL of course) but you’ll find the attribution content towards the bottom):

Note that, if you wish to submit your theme or plugin to the relevant WordPress.org repository, the bundled assets still need to be licensed under either the GPL or a GPL-compatible licence. The Detailed Plugin Guidelines and the Theme Handbook both make that clear.

Free and commercial licensing — 100% GPL and split licensing

The question

The question here is: “can I 100% GPL-license a free or lite version of a theme or plugin for the WordPress.org theme or plugin repository and split-license the commercial version available elsewhere?” (A split licence is a licence that applies the GPL to some of a theme’s or plugin’s assets (e.g., PHP and HTML files) and a more restrictive licence to other assets.)

Themes

In relation to themes, the short answer is no. The position is clearly stated on the Theme Directory’s ‘Getting Started‘ page:

Themes from sites that support non-GPL (or compatible) themes or that don’t meet with the theme review guidelines will not be approved.

This means you cannot sell a commercial theme on your own site or the likes of ThemeForest under a split licence and expect the WordPress.org Theme Review Team to approve a free version that is 100% GPL-licensed. It is highly unlikely that your free version would be approved for listing in the WordPress.org repository. If it were approved because the theme reviewer didn’t notice that you’re selling a split-licensed commercial version elsewhere, you’d run the risk of the free version being taken down upon someone noticing the discrepancy.

In addition to the formal theme guidance on this point on WordPress.org, Justin Tadlock published an interesting post on the topic in 2015: Themes should be 100% GPL.

In case anyone is wondering, the legitimacy of the Theme Review Team’s stance on this issue is not affected by the opinion of the Software Freedom Law Center on the application of the GPL to themes (discussed earlier in this post). The reason why the legitimacy of the Theme Review Team’s stance on this issue is not affected by the SFLC opinion is that the Theme Review Team’s stance is a matter of policy. The Theme Review Team is not asserting that, legally, themes must be 100% GPL-licensed. Rather, they are saying that, as a matter of policy or self-regulatory rules, if you want a theme to be listed in the WordPress.org repository, your themes – free and commercial versions – need to be 100% GPL-licensed (or, in the case of elements that do not need to be GPL-licensed, compatibly licensed).

Plugins

The position in relation to plugins seems unclear. As far as I can see, the WordPress.org Plugin Team hasn’t issued guidance that prohibits submission of a GPL-licensed plugin to WordPress.org when a commercial version is available elsewhere under a more restrictive licence (such as a split licence). If members of the Plugin Team read this and have any comments, I’d love to hear them please. (Perhaps I’ll need to amend this paragraph.)

GPL Engine

In writing this post I’ve tried to provide as much practical information as possible. However, I realise that it might still be difficult for some people to bring everything together when it comes to preparing the copyright and licensing sections of their own style.css header or plugin file header and their own readme.txt files. There’s quite a bit to digest and, because there’s a mix of GPL-related and WordPress.org-related rules to bear in mind, it’d be easy to forget the detail over time. And let’s face it, some people will have little to no desire to spend much time dealing with legal minutiae when they’d rather be coding or releasing their theme or plugin.

So with that in mind I’ve built a “GPL Engine” that asks you a bunch of questions about your theme or plugin and then spits out content for:

• your style.css, readme and licence files for your theme folder; or
• your plugin file header, readme and licence files for your plugin folder.

Take it for a spin and let me know what you think in the comments.

GPL Engine – Themes  GPL Engine – Plugins

Comments

If anyone has any comments on this post that may result in its improvement, please add them below. The more the merrier. If there’s room for improvement, I’ll improve it.

Acknowledgements

Thanks to:

• Cathryn Lavery for the featured image, released on Unsplash.com under CC0;
• mkabakov / Bigstock.com for the copyright image;
• Matt Jones for the ‘Thank You’ image, released on Unsplash.com under CC0; 
• Elizabeth Lies for the green/brown field image, released on Unsplash.com under CC0; and
• wowomnom / Bigstock.com for the image used for GPL Engine.