Latest Posts

learn-how-to-license-my-themes-and-plugins-with-the-gpl

How to apply the GPL to your themes and plugins (and avoid getting in the shi*)

Introduction

Jamie’s story


Hi. I’m Jamie. I’m a developer and I make stuff for WordPress. I create themes and plugins for it, ranging from free releases on WordPress.org, to custom work for clients to products I sell on various marketplaces. I’m also thinking of selling my products independently from my own site. I get it that WordPress itself is licensed under the GPL and I get it that this means that at least some of what I create needs to be licensed under the GPL. Sometimes I also use other people’s GPL-licensed code in my themes and plugins and, at the moment, I’m forking a GPL-licensed plugin in the WordPress.org plugin repository to take it in a new direction. I reckon I understand the basics of the GPL but, to be honest, I’m not always clear about how to apply it to my releases and I’m not always sure whether I’m complying with it properly when using other people’s GPL-licensed code. I’m also aware that there’s a bunch of additional rules on WordPress.org that I need to comply with when I want to add a theme or plugin to the theme or plugin repository but, again, I’m not always sure that I’m doing what I need to. I don’t want to be accused of stealing other people’s code or of being a pirate, “me hearties”, and I don’t want my themes or plugins to be rejected when I submit them to WordPress.org. I wish this stuff could be easier! 

“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

Copyright-law

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

GPL-one-page-summary-in-ebook

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

The Creative Commons-style ‘human readable’ summary

GPL-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:

The WordoMattic Plugin – a plugin for WordPress that enables you to convert images in your posts to word-based images.

Copyright (c) 2016, WordoMattic Inc.

The WordoMattic Plugin is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 2 of the License or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>

You can contact us at info@wordomattic.com

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

themehandbook

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.

In 2009 Matt Mullenweg sought a legal opinion from the Software Freedom Law Center (SFLC) on the application of the GPL to themes. You can find it in his post of 2 July 2009, Themes are GPL, too. Matt summarised the SFLC opinion in one sentence: “PHP in WordPress themes must be GPL, artwork and CSS may be but are not required.”

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:

/*
Theme Name: Twenty Sixteen
Theme URI: https://wordpress.org/themes/twentysixteen/
Author: the WordPress team
Author URI: https://wordpress.org/

Description: Twenty Sixteen is a modernized take on an ever-popular WordPress layout — the horizontal masthead with an optional right sidebar that works perfectly for blogs and websites. It has custom color options with beautiful default color schemes, a harmonious fluid grid using a mobile-first approach, and impeccable polish in every detail. Twenty Sixteen will make your WordPress look beautiful everywhere.

Version: 1.3

License: GNU General Public License v2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html

Tags: one-column, two-columns, right-sidebar, accessibility-ready, custom-background, custom-colors, custom-header, custom-menu, editor-style, featured-images, flexible-header, microformats, post-formats, rtl-language-support, sticky-post, threaded-comments, translation-ready, blog

Text Domain: twentysixteen

This theme, like WordPress, is licensed under the GPL. Use it to make something cool, have fun, and share what you’ve learned with others.
*/ 

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:

/*
Plugin Name: WordPress.org Plugin
Plugin URI: https://developer.wordpress.org/plugins/the-basics/
Description: Basic WordPress Plugin Header Comment
Version: 20160911
Author: WordPress.org
Author URI: https://developer.wordpress.org/
License: GPL2
License URI: https://www.gnu.org/licenses/gpl-2.0.html
Text Domain: wporg
Domain Path: /languages
*/

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:

<?php
/*
Plugin Name: WordPress.org Plugin
Plugin URI: https://developer.wordpress.org/plugins/the-basics/
Description: Basic WordPress Plugin Header Comment
Version: 20160911
Author: WordPress.org
Author URI: https://developer.wordpress.org/
Text Domain: wporg
Domain Path: /languages
License: GPL2

{Plugin Name} is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 2 of the License, or any later version.

{Plugin Name} is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with {Plugin Name}. If not, see {License URI}.
*/

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:

=== Twenty Sixteen ===
Contributors: the WordPress team
Requires at least: WordPress 4.4
Tested up to: WordPress 4.5
Version: 1.3
License: GPLv2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Tags: one-column, two-columns, right-sidebar, accessibility-ready, custom-background, custom-colors, custom-header, custom-menu, editor-style, featured-images, flexible-header, microformats, post-formats, rtl-language-support, sticky-post, threaded-comments, translation-ready, blog

== Description ==
Twenty Sixteen is a modernized take on an ever-popular WordPress layout — the horizontal masthead with an optional right sidebar that works perfectly for blogs and websites. It has custom color options with beautiful default color schemes, a harmonious fluid grid using a mobile-first approach, and impeccable polish in every detail. Twenty Sixteen will make your WordPress look beautiful everywhere.

* Mobile-first, Responsive Layout
* Custom Colors
* Custom Header
* Social Links
* Post Formats
* The GPL v2.0 or later license. 🙂 Use it to make something cool.

For more information about Twenty Sixteen please go to https://codex.wordpress.org/Twenty_Sixteen.

== Installation ==

1. In your admin panel, go to Appearance -> Themes and click the ‘Add New’ button.
2. Type in Twenty Sixteen in the search form and press the ‘Enter’ key on your keyboard.
3. Click on the ‘Activate’ button to use your new theme right away.
4. Go to https://codex.wordpress.org/Twenty_Sixteen for a guide on how to customize this theme.
5. Navigate to Appearance > Customize in your admin panel and customize to taste.

== Copyright ==

Twenty Sixteen WordPress Theme, Copyright 2014-2015 WordPress.org
Twenty Sixteen is distributed under the terms of the GNU GPL

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

Twenty Sixteen Theme bundles the following third-party resources:

HTML5 Shiv v3.7.0, Copyright 2014 Alexander Farkas
Licenses: MIT/GPL2
Source: https://github.com/aFarkas/html5shiv

Genericons icon font, Copyright 2013-2015 Automattic.com
License: GNU GPL, Version 2 (or later)
Source: http://www.genericons.com

Image used in screenshot.png: A photo by Austin Schmid (https://unsplash.com/schmidy/), licensed under Creative Commons Zero(http://creativecommons.org/publicdomain/zero/1.0/)

== Changelog ==

= 1.3 =
* Released: August 16, 2016

https://codex.wordpress.org/Twenty_Sixteen_Theme_Changelog#Version_1.3

= 1.2 =
* Released: April 12, 2016

https://codex.wordpress.org/Twenty_Sixteen_Theme_Changelog#Version_1.2

= 1.1 =
* Released: January 6, 2016

https://codex.wordpress.org/Twenty_Sixteen_Theme_Changelog#Version_1.1

= 1.0 =
* Released: December 8, 2015

Initial release

== Notes ==

Only the default and dark color schemes are accessibility ready.

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:

=== Your Plugin Name ===
Contributors: your_wp_user_name
Donate link: http://your-donation-link.com/
Tags: your_tags
Requires at least: 3.0
Tested up to: 3.8
Stable tag: 1.0.0
License: GPLv2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Short description

== Description ==
Long description

== Installation ==
* Upload plugin files to your plugins folder, or install using WordPress built-in Add New Plugin installer;
* Activate the plugin;
* Navigate to Plugin Settings and fill settings.

== Frequently Asked Questions ==

= What is the plugin license? =

* This plugin is released under a GPL license.

== Screenshots ==
1. Image 01.
2. Image 02.

== Changelog ==

= 1.0 =
* Notes of the version.
== Upgrade Notice ==

= 1.0 =
* Initial Version.

== License ==
This file is part of Your Plugin Name.

Your Plugin Name is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 2 of the License or (at your option) any later version.

Your Plugin Name is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

Get a copy of the GNU General Public License in <http://www.gnu.org/licenses/>.

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

thankyou

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

Before getting into this topic, I note that sometimes people say the GPL doesn’t require ‘attribution’. In saying that they might be thinking of Creative Commons licensing-style attribution but it’s not correct to say the GPL doesn’t require attribution. The GPL does require a kind of attribution and it takes the form of retaining copyright notices that name the owners of the copyright in the original code and the requirement that you note, when modifying their files, that you’ve modified them.

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:

* Based on https://github.com/Automattic/theme-components/, (C) 2015-2016 Automattic, Inc., [GPLv2 or later](https://www.gnu.org/licenses/gpl-2.0.html)

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

* Awesome Theme is based on Components. Components, (C) 2015-2016 Automattic, Inc., is available at https://github.com/Automattic/theme-components/ and is licensed under the GPL, version 2 or later (https://www.gnu.org/licenses/gpl-2.0.html).

(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:

Ginger WordPress Theme incorporates code from Fred WordPress Theme, Copyright 2012 Joe Smith. Fred WordPress Theme is distributed under the terms of the GNU GPL, version 2, http://www.gnu.org/licenses/gpl-2.0.html

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):

== Copyright ==

Twenty Sixteen WordPress Theme, Copyright 2014-2015 WordPress.org
Twenty Sixteen is distributed under the terms of the GNU GPL

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

Twenty Sixteen Theme bundles the following third-party resources:

HTML5 Shiv v3.7.0, Copyright 2014 Alexander Farkas
Licenses: MIT/GPL2
Source: https://github.com/aFarkas/html5shiv

Genericons icon font, Copyright 2013-2015 Automattic.com
License: GNU GPL, Version 2 (or later)
Source: http://www.genericons.com

Image used in screenshot.png: A photo by Austin Schmid (https://unsplash.com/schmidy/), licensed under Creative Commons Zero(http://creativecommons.org/publicdomain/zero/1.0/)

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

grass

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

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.
clarity

“I’d rather see [an] attorney’s attention spent … on clarity and brevity”

WordPress, Wix and the GPL

The Wix controversy, if I can call it that, has stirred up quite a bit of emotion in the WordPress and wider tech and open source communities. I’ve given my thoughts on what I see as the main issues in my previous post “Some thoughts on the Wix mobile app story (updated)”.

In reading a wide range of comments on the various news and blog articles on this story, it strikes me that many people don’t understand the GPL, either due to its complexity at the margins (and I assure you that, at the margins, it can bamboozle lawyers too) or, in some cases, because they haven’t read it.

Then, in reading further through various comments, one comment on the WP Tavern story stood out to me. Lisa League wrote:

“Spending time, money, and attention on court diverts it to attorneys instead of that valuable time money, and attention spent on software.

… this is where I’d rather see attorney’s attention spent – on clarity and brevity where possible in defining the license terms. Not in court enforcing them.

On education, so that the many communities who use and contribute to OSS projects using GPL or various “MIT” licenses are clear on how to do so correctly.

Maybe too idealistic to hope for, but then these kinds of situations would be less likely to happen intentionally or inadvertently. Without opponents you can’t play the sport, but you also can’t play well if everyone’s trying to play the same game by a different set of rules. Or without knowing the rules.”

This struck a chord with me given that I’ve rambled on about the GPL in all manner of contexts. So, in this post, and to answer Lisa’s comment, I’m going to:

  • try to meet Lisa’s suggestion as to clarity and brevity;
  • give away a bunch of copies of my ebook on WordPress and the GPL; and
  • post some audio tracks of chapters of the ebook.

Clarity and brevity

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 (actually, I hope they’re both human-readable, but you’ll get my drift). Here are the two summaries.

The sequential summary

GPL-one-page-summary-in-ebook

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

The Creative Commons-style ‘human readable’ summary

GPL-human-readable-summary

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

A Practical Guide to WordPress and the GPL

I’ve compiled a range of my thoughts on WordPress and the GPL in my ebook “A Practical Guide to WordPress and the GPL“. Because WordPress and GPL issues are once again so topical, I’ve decided to give away 100 copies of it to the first 100 people who complete the form below.

If you’d like a copy, just enter your email address below. The ebook will be sent to the first 100 people who do so.

  • This will add you to my email list but I promise not to send you crud and you can unsubscribe whenever you like. 🙂

Oh, and Lisa, if you’d like it, you can have the full Business Package. Just send me a note via my contact form and I’ll send it to you.

Some audio

When I created the ebook, I also had an audio version prepared. Perhaps somewhat optimistically, I thought people might actually listen to audio files on this stuff. Anyway, for those who are actually interested in doing that (but without paying for the audio book package), I’ve included the audio files from a few chapters. (By the way, I’m not the narrator. I paid for someone else to do that.)

Chapter 1: Introduction: conception, birth and forking



Chapter 2. Understanding the GPL licensing of WordPress



Chapter 3. Common GPL-related questions



Chapter 9: The GPL and trademarks



Hope this helps.

deer-for-wix-post

Some thoughts on the Wix mobile app story (updated)

The story

Perhaps not surprisingly, Matt’s recent post “The Wix Mobile App, a WordPress Joint” caught my eye. Indeed, it caught both eyes. I’ve read through his post and I’ve read the Wix CEO Avishai Abrahami’s prompt reply, “Dear Matt Mullenweg: an open letter from Wix.com’s CEO Avishai Abrahami” as well as a Wix engineer’s reply in “How I Found Myself Accused of Stealing Code from WordPress”.

The key points, it seems to me, are these:

  • Matt has said that “Wix copied WordPress without attribution, credit, or following the license. The custom icons, the class names, even the bugs. You can see the forked repositories on GitHub complete with original commits from Alex and Maxime, two developers on Automattic’s mobile team.”
  • Matt has also said:

“This explicitly contravenes the GPL, which requires attribution and a corresponding GPL license on whatever you release publicly built on top of GPL code. The GPL is what has allowed WordPress to flourish, and that let us create this code. Your app’s editor is built with stolen code, so your whole app is now in violation of the license.”

  • In his reply, Mr Abrahami says:

“Next you talk about the Wix App being stolen from WordPress. There are more than 3 million lines of code in the Wix application, notably the hotels/blogs/chat/ecommerce/scheduling/booking is all our code.

Yes, we did use the WordPress open source library for a minor part of the application (that is the concept of open source right?), and everything we improved there or modified, we submitted back as open source, see here in this link – you should check it out, pretty cool way of using it on mobile native, I really think you guys can use it with your app (and it is open source, so you are welcome to use it for free). And, by the way, the part that we used was in fact developed by another and modified by you.”

Main issues

There is, it seems to me, a range of issues. I think the main ones (but not the only ones) are these:

1. Has Wix published on or in relation to its mobile app an appropriate copyright notice and disclaimer of warranty, kept intact all the notices that refer to the GPL and to the absence of any warranty, and included a copy of the GPL (or at least a link to it) along with the app?

2. Has Wix created a derivative work of WordPress code and, if so, what is that derivative work? Is it the React Native WordPress Rich Text Editor or the whole Wix mobile app?

3. If so, when releasing the relevant derivative work, has Wix released it under the GPL as the GPL would require and, if not, what are the consequences?

I’ll give my preliminary thoughts on each of them.

But first… Before getting into these thoughts, I want to say that I’m looking at this from a legal perspective. Yes, I prefer WordPress over Wix, but I’m writing this because, at least for a lawyer, it raises an interesting set of issues. I’m not interested in vilifying anyone and I don’t intend to do so.

Inclusion of appropriate copyright notice and disclaimer of warranty and copy of or link to GPL

I’ve downloaded the Wix mobile app onto my iPhone and taken a look at the listing page on the Apple app store and the app’s various pages. As far as I can see, there’s no reference to the app including WordPress code, no copyright notice to that effect, no disclaimer of warranty in relation to that code and no copy of or link to the GPL (by contrast, the WordPress mobile app links to the source code in the relevant Github repository which also contains the GPL licensing statement and a copy of the GPL).

Whilst Wix has taken some steps to comply with these requirements in its own Github repository, I think we need to appreciate that Github is only one form of distribution and it’s not the form that most users of the mobile app would experience. Distribution of the app itself, which I assume embodies the relevant WordPress code, is a separate distribution. For this reason, to my mind, partial compliance with the GPL’s requirements on Github (in relation to inclusion of appropriate copyright notices etc) is no answer. In my view, to comply with the GPL, Wix needs to meet the requirements I’m discussing here – and which Matt is concerned about – in the distribution of its mobile app. As far as I can see, it hasn’t done so. If that is right, it is not complying with the GPL.

Derivative work

I can’t profess to know all the factual detail in relation to how the Wix mobile app works so am reluctant to nail my colours to the mast on the derivative work question. With that caveat in mind, I’d say that the ‘React Native WordPress Rich Text Editor’ in Wix’s Github repository does seem to be a derivative work of the WordPress Rich Text Editor. As far as I can tell, Wix has more or less conceded that point.

The harder question is whether the Wix mobile app is also a derivative work. Neither I nor, I suspect, any lawyer would want to give a firm view on that in the abstract, that is, without knowing how the app is architected, how the WordPress code is used, the volume of Wix’s original code, whether it’s separable from the WordPress code, and so on. Some will know the answers to those factual questions. I don’t. I wouldn’t want to hazard a guess on that in the abstract. Even with a full factual understanding, depending on the factual landscape different lawyers may have different views on this issue given the paucity of case law on the key provisions of the GPL. I think we need to appreciate that this is one of the harder and more controversial aspects of the GPL when applied in practice.

Now, I suspect some will say:

“But look at clause 2(b) of GPL2. It says: ‘You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License’. It is clear that the Wix mobile app contains at least a part of WordPress GPL’d code and, therefore, needs to be licensed as a whole under the GPL.”

The potential problem with this position is that it overlooks these words of the GPL, also in clause 2:

“These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

In addition, 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 this License.”

You might think the words, “[b]ut when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License”, apply here. However, is the “whole” here “a work based on the [WordPress program]”? To be honest, factually, I don’t know, and I suspect different lawyers might return different answers on this question (see, for example, GPLv3 myth#2: You can’t mix GPL software with other software). Automattic seems to think the answer is yes. Maybe it’s right. As I say, though, I don’t know. I just don’t have enough information.

And let’s not forget the Software Freedom Law Center’s opinion on the GPL and WordPress themes. If I create a WordPress theme, comprising not only the standard PHP files but also a range of other assets (different stylesheets, javascript, fonts, images, etc), does the whole theme file need to be licensed under the GPL? Is the overall theme “a whole which is a work based on the Program”? Well, no, not according to the Software Freedom Law Center. They’ve said only the PHP and integrated HTML are derivative of WordPress.

So, as you can see, this broader derivative/collective work issue is not straight-forward. The deeper you venture into the rabbit hole, the darker it gets.

GPL licensing

From this point, when I refer to the derivative work, I’m only referring to the React Native WordPress Rich Text Editor, not the entire Wix mobile app.

If, as I suspect, the React Native WordPress Rich Text Editor is a derivative work of the WordPress Rich Text Editor, then Wix was obliged, when distributing it, to license it under the GPL. However, and despite some of the old GPL licensing being retained in the WordPress files, the relevant Wix Github repo says that the code in the repo is licensed under the MIT licence (I know the relevant statement also says “please consider the licenses of the dependencies separately” but that doesn’t exactly foster clarity).

Now, if the entirety of the code in that repo is a derivative work, then it all needs to be distributed under the GPL.

This is where, in some people’s minds, the question of GPL compatibility comes in. They think it’s OK if a so-called GPL-compatible licence is used for a work that is derivative of GPL-licensed code. This is a problem, and it’s a problem that one even sees, to some extent, in the WordPress.org theme and plugin guidelines (a point I can explain in more detail if anyone likes). This is why it’s a problem: to the extent that a work/program is truly a derivative work of pre-existing GPL-licensed code, that derivative work must be licensed under the GPL 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. The GPL does not allow you to license a derivative of a GPL-licensed work under a GPL-compatible licence. MIT code can be absorbed into a GPL work but a derivative of GPL’d code cannot be licensed under the MIT licence.

Conclusions

Whilst Wix appears to have been open-source minded in relation to the React Native WordPress Rich Text Editor in terms of its MIT-licensing on Github, I think it should have applied the GPL, not the MIT licence. If Wix were to agree then, as long as the new code contributions were original or GPL-compatible, this particular issue would be capable of an easy fix (distribute the repo code under the GPL). The more significant issue, I suspect, is how it approaches the distribution of its mobile apps via the app stores. If my analysis is correct (and if anyone disagrees feel free to say), Wix will need to do more to comply with the GPL so as to rectify what, at present, seems to be copyright infringement caused by non-compliance with the GPL.

As to the broader issue of the licensing of the Wix mobile app as a whole, as I’ve indicated, that’s a factual-legal swamp into which I don’t propose to tread any more than I already have.

(Thanks to Ming Jun Tan for the featured image I’ve used in this post, released on Unsplash.com under CC0.)

Update, 2 November 2016

This post was first published on 31 October 2016. On 1 November (where I live at least) Wix updated the licence in its wix/react-native-wordpress-editor Github repo to the GPL.

website-optimized

Commercial theme suppliers selling themselves short…

The backstory

This isn’t a legal article. It’s more about marketing. Let me tell the backstory.

I’ve been looking around for a particular type of WordPress theme for a specific purpose. It’s a niche kind of site and there aren’t many solid contenders. I’ve found one contender on ThemeForest and another on a commercial theme supplier’s own website. I’ve found it difficult to choose between them, despite their significant difference in price, because they both have their pros and cons.

But the main reason I’ve not chosen one over the other yet is because neither supplier is doing a sufficient job of marketing their product. I can see how your themes look and try out your demos, sure, and one of you has some moderately good documentation that’s accessible without purchasing the theme, but neither of you show enough detail as to what’s under the hood. In particular, you’re not showing potential customers the level of customisation available through the customizer or other theme options. Unlike some of your competitors who (in my view) have inferior offerings, you’re not showing screenshots of the customisation options available or otherwise describing them in sufficient detail. In addition, I don’t know whether your home page template files are widgetised and, because neither of you seems to be using a Visual Composer or Divi-style content block/modular approach, I can’t ascertain how easy it would be to customise the home page to my liking and requirements. Yes, I can make my own home page and make it look more or less how I want (e.g., by creating a new page template with widgetised areas or by using shortcodes or by using a page layout plugin) but if your home page templates already do the heavy lifting I don’t want to do that. So I need to know.

I can ask each of you questions via online forms (and I have) but, I suggest, I really shouldn’t have to do that and having to do so just delays and potentially frustrates a decision to purchase. Indeed, for both of your products, I’ve almost said “bugger it, I’ll go somewhere else”. The only reason I haven’t is due to the niche and quality nature of your offerings.

Giving customers what they need

I reckon potential customers should be able to look at what you’ve said online and determine, without a need for undue pondering, whether your product has what they need. I would probably have purchased one of your products over the weekend if you’d said enough in your marketing collateral to give me sufficient confidence, but neither of you have. If either of you had viable competitors that did provide this information, I would have opted for them.

Now, I’m only one person. I get that. So a missed sale to me is probably insignificant in the scheme of things. But what if I was the kind of person to start ranting online in a manner that named you (I’m not) or what if others have the same experience as me? In either case that could mean thousands or possibly tens of thousands of dollars of lost sales, even though your products seem to be well designed and probably what we’re after.

In the increasingly competitive commercial themes market these oversights seem, shall we say, less than prudent. I’m sure both the suppliers I’m looking at have invested substantial time and resources into their products but they’re letting themselves down with their execution.

Some great examples

If you’re not sure whether you’re giving customers what they need and keeping up with the competition, take a look at some theme shops that do it right. For a couple of great examples, take a look at Array Themes‘ documentation (e.g., the Baseline Help File) or Elmastudio‘s documentation (e.g., the Zuki documentation). Both companies have rightly invested substantial time and effort into their documentation and it makes a difference. When I purchased Zuki for this site, I remember being confident – from the documentation – that the theme did what I wanted. And I’ve purchased from Array Themes too. Both Array Themes and Elmastudio produce beautiful themes but they go the extra mile and produce great documentation as well. I wish the theme shops I’ve been looking at had done the same.

(Thanks to Lee Campbell for the photo used for this post, available on Unsplash. To avoid doubt, the website in the photo is not one of the ones I’ve been looking at.)

Scraping

Content scraper plugins, contract and copyright

The story

I thought I’d introduce this post by telling a story. It’s a story about Jim, an everyday guy who has a website for which he wants more content. Jim already works hard on his site, adding new posts frequently, but he wants more content to drive more traffic to his site and to help monetise his site. He can’t do it all alone. Jim finds a bunch of sites with interesting and relevant content that he thinks would be perfect for his own site. These sites don’t generate web feeds of any flavour so Jim does a trawl of WordPress plugins and finds a commercially available plugin in a well-known plugins marketplace that does exactly what he wants. All he has to do is:

  • install the plugin;
  • create a post or page in his site and click a new icon in the editor which opens a pop-up window that asks for a URL and a CSS selector;
  • get the URL of the page on another site that has the content he wants and enter that URL into the URL field;
  • find the class or ID of the content he wants on the page of the other website and enter it into the CSS selector field; and
  • publish his post or page.

Now, when someone goes to this new post or page on Jim’s website, it will display the selected content from the other website. Jim is obtaining substantial amounts of content from the other website and is loving it.

“Awesome!”, Jim says to himself, “now I can add all manner of rich and informative content to my website”. And that’s what he does, adding more content from a range of pages on the other website as well as from other websites.

Jim does this for a while. The traffic to his site increases immensely, he’s able to sell more products and he’s feeling pretty chuffed… until the day arrives when he receives an angry-sounding email from one of the third party site owners, making some noise about their terms of use and telling him to stop stealing their content.

“Hey, it’s a free world”, Jim thinks, “and they’ve published the same content into the public domain anyway”, so he ignores the email. A couple of weeks later he receives a rather more angry-sounding letter from the third party site owner’s lawyers. It says Jim is breaching contract, breaching copyright and that their client will take Jim to court if he doesn’t remove the content immediately.

Should Jim take this seriously? Short answer: yes.

The law

This sort of thing happens fairly frequently in the online world. Some people who do it, let’s call them “scrapers”, know full well that they may be skating on thin ice, whereas others are oblivious to the legal context. In Jim’s case, the legal context is this:

  • the terms of use on the third party website expressly prohibit scraping and other forms of copying of the site’s content;
  • even if Jim wasn’t aware of those terms initially, the site owner has brought them to his attention and he has continued to scrape anyway; and
  • Jim has reproduced substantial amounts of copyright content from the other website for his own purposes and without permission.

Under the laws of many countries, Jim’s behaviour would see him breaching contract (i.e., the other website’s terms of use) and, in all likelihood, breaching copyright. In other words, the lawyers could well be right. The third party site owner could seek and would probably obtain an injunction from the courts ordering Jim to stop reproducing the content. The site owner might also seek and obtain an award of damages from Jim.

Moral of the story

The moral of this story, then, is that if you’re thinking about installing a scraping plugin and scraping content from other people’s sites without permission, you might want to think again. Not all instances of scraping will land you in the hot seat but many of them will and the fact that you’re taking content that has already been published elsewhere will usually be irrelevant.

Pen-on-book-optimised2

Selling themes yourself and on ThemeForest but with inconsistent licensing

With apologies for the radio silence for the last 5-6 months (for a while there life was just too hectic), I’m finally getting around to revving up WP and Legal Stuff again.

This post will be pretty brief but addresses a phenomenon I’ve seen from time to time across the WordPress theme shop community.

Here’s the scenario: you find a WordPress theme you really like on a theme shop’s website but, when you look at the licensing for the theme, it either limits what you can do with the theme or it’s a confusing conglomeration of terms that appear to have been plucked from an array of different sites and mashed together in the hope it’ll fly. Perhaps I’m in the minority, but I’ve deliberately not bought themes from theme shops like this because the lack of attention to clear licensing doesn’t give me much confidence in the overall soundness of the business,  its attention to detail and its customer centricity (or lack of it).

But lo and behold, later you discover that this very same theme shop is selling its themes on ThemeForest and (to its credit) has selected the 100% GPL option!

For theme purchasers keen on liberal licensing that doesn’t purport to restrict their usage of the themes they purchase, this ought to mean they’ll opt for purchasing from ThemeForest over purchasing from the theme shop’s own site. But hang on. This means ThemeForest will earn a commission from a theme sale that it wouldn’t have earned had the theme been purchased from the theme shop’s own site.

So what does all this mean? Well, it means two things. First, theme shops that do this either don’t understand licensing very well (or have used a lawyer who doesn’t understand it very well) or don’t really care about it. In either case, they don’t make the effort to make the licensing of their themes on their own sites and on ThemeForest consistent. That’s potentially confusing, if not irritating, for purchasing customers (or at least those who care about the licences that govern the use of the themes they purchase). Second, theme shops that do this potentially shoot themselves in the foot, from a revenue perspective, because in many cases they’ll get less if the theme is sold on ThemeForest instead of being sold on their own site.

You might think this sort of thing wouldn’t happen in the real world of commercial theme development but, I assure you, it does. I don’t want to call out any particular theme shop, so I won’t, but this really does happen out in the wild.

If you’re a theme shop that’s not sure whether your own licensing is consistent with the licensing you select on ThemeForest, feel free to get in touch and I’ll do my best to let you know (confidentially of course).

(Thanks to Thomas Martinsen for the photo I’ve used for this post, released on Unsplash under CC0.)

Coding2

Discouraging public redistribution of commercial themes and plugins – poll results

Background

Back on 4 August of this year, I published a post called Theme and plugin shops – Discouraging public redistribution – User poll.  The poll that was included in the post sought people’s views on the reselling of commercial themes and plugins. It did this because people’s views on this issue are relevant to the inclusion of a contractual mechanism I’d proposed for theme/plugin shop terms of use. The contractual mechanism I’d proposed would seek to discourage purchasers of a commercial theme or plugin from making the theme or plugin available on a website for download by others (whether for free or a charge), even when the theme or plugin is 100% GPL-licensed.

The proposed term would say that, if a customer decides to make your commercial theme or plugin available on a website for download by others, you may exercise a right to deactivate their access keys (if that’s how you’ve set things up) and to terminate their access to support and updates. I explained why, in my view, this sort of clause is not contrary to the freedoms conferred by the GPL:

“Is this contrary to the rights they have under the GPL? I think not. This approach doesn’t stop them from distributing the theme or plugin, as they originally obtained it, on a website. But it does say this to them: ‘if you decide to exercise your GPL rights in that way, as you’re entitled to do under the GPL, you run the risk of losing your contractual right to support and updates under these separate terms of use’. This is a commercially-oriented mechanism that is distinct from, and doesn’t prevent the exercise of, one’s freedoms under the GPL. It does say ‘you can’t have it both ways, folks’, but the GPL rights are left intact. Only the separate, commercial support arrangements are affected. There may be those who would cry foul, but – legally – I don’t think their cries would be well-founded.

After I wrote this, I did a search on the web to see whether I could find other businesses doing something similar to what I’m proposing. Lo and behold, it seems that Red Hat did this a few years ago. See GPL expert gives Red Hat the all-clear.”

Poll results

I closed the poll today. In the intervening period, 121 people had taken the poll. Here’s a graphical depiction of the results (thanks to the wonders of Gravity Forms and its Polls Add-On):

Poll-results

Majority consider redistribution of commercial themes or plugins on a public website to be unethical

A majority of those who took the poll – 76 of the 121 people – think the practice of purchasing or otherwise obtaining a commercial theme or plugin and then either reselling it on a public website or giving it away on a public website, is unethical, regardless of whether it’s permissible under the GPL. A further 10 people don’t know whether it’s unethical but don’t like it. The remaining 35 didn’t have a problem with it if the GPL is complied with.

Widespread support for inclusion of proposed term

Each person that took the poll was asked to assume he or she is a purchaser of commercial themes or plugins. Each person was then asked whether he or she would support a commercial theme or plugin business including the kind of term I’ve mentioned in its terms of use. (As a reminder, the term gives the business the power to terminate support and access to updates if the customer were to openly redistribute the commercial theme or plugin on a public website, either for a price or no charge.)

An overwhelming number of those who took the poll – 101 out of 121 – supported the inclusion of such a clause, as they selected this option:

“Yes, I would support that as I understand the business is trying to protect its investment and it poses no threat to my use of the themes or plugins.”

Of the remainder, 17 did not support the inclusion of such a clause even if the GPL freedoms remained intact, and 3 didn’t know or care.

Views of theme and plugin businesses on the idea of including the suggested clause

Of the 121 people who took the poll, 67 were from a business that develops commercial themes or plugins or were thinking of becoming one. These people were asked some additional questions.

The first additional question they were asked was whether they like the idea of including the suggested clause in their terms of use (in answering this, they were told to assume they wouldn’t be criticised for including the term). 47 of the 67 said they like the idea of the proposed term. 13 didn’t like the idea of this term and the remaining 7 didn’t know or didn’t care.

The second additional question they were asked, on the assumption that they would include the proposed term in their terms of use, was whether they’d be concerned that vocal stakeholders in the WordPress community might openly criticise them for not complying with the ‘spirit’ of the GPL (even if the term doesn’t actually remove any GPL freedom). 26 of the 67 answered yes (they would be or are concerned), 17 answered no (not concerned) and the remaining 4 didn’t know or care.

Comments

General conclusions

To the extent that one can draw general conclusions from this poll (and admittedly the sample is not exactly huge), they would appear to be that:

  • a significant majority of people either think that the practice of purchasing or otherwise obtaining a commercial theme or plugin and then either reselling it on a public website or giving it away on a public website is unethical or they don’t know whether it’s unethical but still don’t like it;
  • there is widespread support for the inclusion of a term in theme and plugin shops’ terms of use that would entitle the theme or plugin shop to deactivate a customer’s access key (if that’s how they’ve set things up) and to terminate their access to support and updates;
  • a significant majority (more than two thirds) of people from businesses that develop commercial themes or plugins (or who are thinking of becoming one) like the idea of the proposed term; and
  • a bit over a third of those from businesses that develop commercial themes or plugins or are thinking of becoming one would be concerned about being openly criticised by vocal stakeholders in the WordPress community if they were to include such a term (even if the term doesn’t actually remove any GPL freedom).

Businesses should be able to protect themselves in legitimate ways without fear of attack

In my view, it’s unfortunate that the third of people mentioned in the last bullet point would be concerned about being criticised by vocal stakeholders in the WordPress community if they were to include such a term, because – for reasons already given – in my view such a term would not be contrary to the GPL.

I think it’s undeniable that the development of robust commercial themes and plugins supports rather than detracts from the growth of the WordPress ecosystem. Just look at Automattic’s acquisition of WooCommerce as an example or the power that Gravity Forms brings to WordPress as another. Businesses that depend on and support the WordPress ecosystem should be able to protect their legitimate commercial interests without fear of verbal attack from those who cling to misconceptions of what the GPL does or doesn’t allow.

Bear in mind here, too, that the GPL is not an open source licence created for WordPress. Rather, it is simply the open source licence that governed the use of B2/cafelog when Matt and others forked it to become WordPress. WordPress users don’t have any monopoly over what the GPL does or should mean or allow.

The wording of the proposed term

The WordPress theme/plugin shop terms of use that you can build online if you purchase the business package of A Practical Guide to WordPress and the GPL will provide you with terms that, among other things:

  • explain the GPL licensing of the themes or plugins;
  • accommodate the use in themes or plugins of public domain assets (such as images) or assets that have been licensed by another under a Creative Commons licence (such as photos);
  • refer customers to a human-readable summary of the GPL for more information;
  • contain an explanation of the redistribution that the GPL allows but together with information on the investment that the business has made in developing its themes or plugins and the adverse consequences (for the business, its staff and in some cases their families) that open redistribution could bring;
  • explain a customer’s access to support and updates; and
  • regulate a customer’s use of its access key, login and right to support and updates.

It is the last item in this list that contains a right for the business to deactivate a customer’s access keys (if that’s how the business has set things up) and to terminate the customer’s access to support and updates if the customer decides to make a purchased commercial theme or plugin available on a website for download by others. The suggested clause (which may need tweaking in certain cases to reflect how a business has set things up) is as follows (I’ve italicised the key part relevant to this discussion):

Access key, login and right to support personal to you

Your access key, your support login and your right to support are personal to you. You are not permitted to share any of them with, or transfer any of them to, anyone else without our prior written approval (which we may refuse at our discretion) and you are not permitted to republish support answers on any other website or medium. If you do any of these things, we may deactivate your access key and terminate your right to support and updates, with or without notice. You agree that we may also exercise these powers if we have reason to believe you are requesting support for sites that do not fall within your support entitlements or if you are making our Products available on another website for others to download, with or without charge. (This does not defeat your rights under the GPL. We are simply saying that if you decide to exercise your GPL rights in that way, you will lose your right under these terms of use to access support and updates from us.) If we believe the security of your access key or login has been compromised, we may suspend your rights of access while we investigate. If you believe your login has been compromised, please let us know as soon as possible.

No legal advice

I hope this helps. Needless to say, I’m not providing legal advice to anyone in suggesting this kind of clause. It is for each business to make its own decision on the inclusion of such a clause, with its own legal advice if required.

Happy developing!

Dog

Step-by-step guide to attributing Creative Commons-licensed images

BobWP reader seeks step-by-step guide

A while back I wrote a piece that first appeared on BobWP called Using Creative Commons images on your site with confidence (I republished it here too). Recently a reader of BobWP asked a question about the detailed mechanics of finding a Creative Commons-licensed image and applying an attribution statement to one’s use of it. He was trying to use images found through Google image and Flickr searches but wasn’t sure exactly how to go about attributing the image and was looking for a step-by-step guide.

In response, I wrote a brief step-by-step guide in the comments on Bob’s site. Because that guide might come in useful for others, I thought I’d post it here on WP and Legal Stuff too.

Key steps

1. Search an image repository that has Creative Commons-licensed images

Find an image and ensure it is licensed under a Creative Commons licence. Flickr is a good source and I’ll use that as an example from now on. Do an initial search for the topic or subject you’re interested in by using the search form on the Flickr homepage:

Flickr-homepage

2. Refine your search results

When you do a search, it will reveal all images that match your search terms, regardless of whether the images are licensed for re-use. This means you have to refine your search. To do that, on the results screen, click on the dropdown menu called “Any license”:

Flickr-licence-dropdown

(The dropdown name “Any licence” is not very clear as some images are not licensed at all). You want to select either “All creative commons” or one of the three options below it. Which one you select depends on what sort of licensing rights you need. If you want to use an image commercially, you’ll need to select “Commercial use allowed” (and so on for the other options).

3. Select an image

Once you’ve done that, you’ll see a list of images that is confined to Creative Commons licensed images. Click on one you like. When you do, you’ll be taken to that image and you’ll see the licence that has been applied to it. Here’s an example:

CC-licence

4. Identify which licence applies

To figure out which particular licence applies, click on the “Some rights reserved” link and open it in a new tab (some people will know what the icons beside “Some rights reserved” represent, but many won’t, which is why I’m suggesting opening the link in a new tab). In this case, you’ll see that the licence is a Creative Commons Attribution-ShareAlike 2.0 Generic licence:

CC-BY-SA-2-Generic

If you look to the left of the page on Flickr (further above) you’ll see that the author is someone called Celine.

5. Use the image in your site

Use the image you’ve selected in your site as you wish (consistently with the terms of the applicable Creative Commons licence).

6. Add attribution statement

Within the editing window, add your attribution statement either below the image or, for example, at the end of the post or page. To create the HTML for the attribution statement, you can use this kind of format (the code is on the left and on the right you can see how it’s rendered):

Code-snippet

Note that I’ve linked “Celine” (the owner of the photo) to the page on Flickr that contains the photo I’m using and that I’ve linked “Creative Commons Attribution-ShareAlike 2.0 Generic licence” to the Creative Commons page that contains that licence (which I accessed in step 4 above).

If you want to copy and paste that code so as to just swap out the bits relevant to the image you’re using, you can find it here on GitHub.

(Note that you don’t have to use my suggested wording, with the “Thanks to” component. I just do that to show some gratitude. I gave other examples in the original post mentioned above.)

That’s it!

That’s it. If anything is unclear, let me know. This gets easier and faster the more you do it.

Something for the future

By the way, I’ve half built and in the future will publish a tool that grabs some inputs from someone wanting to create an attribution statement and then spits out the HTML code for the attribution statement. Maybe that’ll make life easier. Hope so.

(Thanks to Celine for her dog image, licensed under a Creative Commons Attribution-ShareAlike 2.0 Generic licence. I have cropped the image. My cropped version above is likewise licensed under a Creative Commons Attribution-ShareAlike 2.0 Generic licence.)

A-Practical-Guide-to-WordPress-and-the-GPL

A Practical Guide to WordPress and the GPL – now available – 30% introductory discount

Finally…

I’m pleased to be able to say that A Practical Guide to WordPress and the GPL is now out in the wild. You can find it right here.

Outline

Here’s a quick outline of the chapters:

1. Introduction: conception, birth and forking

2. Understanding the GPL licensing of WordPress

3. Common GPL-related questions

4. WordPress themes, the GPL and the conundrum of derivative works

5. The GPL and assumptions of automatic inheritance

6. Theme reviews, CC0, model releases and GPL-compatibility

7. Selling ThemeForest themes outside of ThemeForest

8. Reselling commercial plugins

9. The GPL and trademarks

10. Theme and plugin shop terms of use versus GPL freedoms

A-Practical-Guide-on-desk

Packages

Three different packages, or editions, are on offer:

1. The business package

If you’re into the business of developing WordPress themes or plugins (or both), you might want this package. You’ll get:

  • the ebook (PDF) of A Practical Guide to WordPress and the GPL;
  • a professionally narrated audio book, enabling you to listen to the book when you’re on the go (narrated by Steve Chase); and
  • access to a terms of use builder through which you can build draft online terms of use for your WordPress commercial themes or plugins shop, with open and honest GPL licensing as well as protections for your business.

2. The book and audio book package

With this package, you’ll get:

  • the ebook (PDF) of A Practical Guide to WordPress and the GPL; as well as
  • the professionally narrated audio book, enabling you to listen to the book when you’re on the go (narrated by Steve Chase).

3. The book package

If you’re just after the ebook of A Practical Guide to WordPress and the GPL, this package is for you. You’ll get a PDF of the ebook that you can read or dip into at your leisure.

Introductory discount

For a limited time, you can get 30% off each of these packages. To get the discount, just tweet the book’s promo page or like it on Facebook, using the buttons on the promo page (you’ll find them directly under the three package offerings). Doing that will reveal an offer code which you input at the point of purchase. Easy. The discounts will be available for around a week.

Terms of use builder

If you’d like to see a video demonstration of the terms of use builder (you get access to this with the business package), you’ll find that on the promo page too. Hell, I might as well embed it here too:

Questions

If you have any questions, feel free to ask. Otherwise, why not go and check out the book’s promo page. Thanks.

First-aid-kit-and-key

A human readable summary of the GPL?

In my ebook (A Practical Guide to WordPress and the GPL) which will be out within the next 6-8 hours, I’ve included a one page summary of the GPL which I hope will make it easy for people to understand the core concepts of the GPL. That summary outlines the position in relation to copying and distribution, fees, modifications/derivative works, distributing non-source forms, termination, and downstream licensing:

GPL-one-page-summary-in-ebook

This particular summary follows the flow of the clauses in the GPL and that’s why it flows through the subject headings I’ve just mentioned. One consequence of this common approach to summarising legal documents is that the discussion of a single topic may contain a summary of both a person’s rights and a person’s obligations. For example, the discussion of modifications / derivative works says:

“You may modify the Program or any part of it and distribute the modifications or new work as long as modified files contain notices regarding the existence and date of changes and any work that you distribute or publish that contains or is derived from the Program or any part of it is licensed as a whole at no charge to all third parties under the GPL.”

As you can see, this paragraph says “you are free to do A but if you do you also need to do X”. Rights and obligations. This approach is repeated, where relevant, for each subject.

Last night, in response to some comments on one of my posts by a couple of people, I wondered whether there was a different and perhaps even simpler way to summarise the GPL. I was also thinking about this because the terms of use that my WordPress theme/plugin shop terms of use builder will generate (available as part of my ebook business package) will summarise the GPL and also link to a human readable summary of the GPL for customers that want to read more.

Now, in my normal day job, I’ve done a huge amount of work on open licensing of government copyright works and that has involved very close examination and implementation of the Creative Commons licences. Not surprisingly, then, my mind immediately gravitated towards the ‘human readable deeds’ that Creative Commons produces for its licences. Those deeds take a slightly different approach to summarising the legal terms of the licence. Instead of addressing licence content on a subject by subject basis, which would include rights and potentially obligations per subject, they take a “you can do A, B and C, as long as you do X, Y and Z” approach. In other words, they state all freedoms and then list the obligations. For some people, this may be easier to follow.

With that in mind, last night I whipped up a GPL human readable summary, modelled on the approach taken by Creative Commons. This is what it looks like:

GPL-human-readable-summary

What do you reckon?

(Thanks to Felix E. Guerrero for the First Aid Kit and Key image, which he has licensed under a Creative Commons Attribution-ShareAlike 2.0 Generic licence.)