I suspect many of us, myself included, are now suffering from Black Friday to Cyber Monday fatigue. So I’ll keep this brief.
For a very limited time, I’m offering full access to The 5-Step Legal Plan for Online Course Creators for the madly discounted price of $29. That’s a whopping 66% off the normal price. The course helps you to protect your course content, avoid being sued, comply with important laws, and keep what you earn in your pocket, in under 90 minutes!
This includes walking you through quick and automated creation of your own copyright statement, disclaimer, terms of use, and privacy statement.
Oh, and you’ll get all 6 of our ebooks too, which cover protecting your course content, using others’ content safely, licensing content to get promotion, mastering your email marketing, having a privacy statement, and shielding yourself from lawsuits.
This deal will never be repeated again, so be quick. There’s never been a better time or place for course creators to get their legal house in order.
(The timer on the sales page is a real timer, not one of those poxy, misleading timers that restart when you do a browser refresh. I should really write a blog post about those, as in some countries they can violate consumer protection laws.)
“Make sure you get the legal stuff right with your online course.” “Huh?”, the course creator responds. “What do I need to know, and why?”
It’s all too easy for course creators to come up with and validate a great idea, create their course, get on with their marketing, and whack their course up on a course platform, without giving much if any thought to the legal stuff. Unfortunately, not getting the legal stuff right – getting the legal stuff wrong – can have very negative consequences. With that in mind, and to help you start thinking about the things you need to know, I’ve whipped up “17 practical legal steps to help you create great course content, protect yourself, and keep your money”.
It’s free, and you can find it on Law of Course (just scroll to the bottom). Hope you find it useful.
Let me introduce to Online Courses and Legal Stuff
Over time I’ve written quite a bit about legal issues associated with the use of WordPress. I’m still interested in the topic but am taking a further pause from it to focus on legal issues associated with online course creation. Borrowing from the name for this site, I’m calling my new site Online Courses and Legal Stuff.
Now, many WordPress users are also interested in creating online courses, or building themes and plugins that support online courses. For this reason, I’m expecting to be writing about WordPress from time to time on Online Courses and Legal Stuff and, as such, it seems relevant to announce Online Courses and Legal Stuff here, on WP and Legal Stuff.
Come on over
If you’re interested in the legal issues associated with online course creation, come on over to Online Courses and Legal Stuff. As you’ll see, I’ve designed the homepage as a landing page.
And if you’re interested in online course creation and would like me to explore particular issues in one or more blog posts, feel free to let me know via the contact form here on WP and Legal Stuff.
Anyway, yesterday I received an interesting question through the Ask me a question page of this site. The question was this (I’ve removed some names to make the example more generic):
“Let’s say a code project has been released under the GPL for years. The original author of the project (let’s call the author Charlie) or his or her company (let’s call it CharlieCo) wants to take it under a proprietary licence. Is Charlie or CharlieCo allowed to do this, given that the original work was released under the GPL (and has been licensed under the GPL for ages) and given that the original author has accepted contributions under that licence?”
When asked this question, most lawyers practising in this field can be expected to say things like: “There aren’t enough facts to give you an answer” or “what do you mean by ‘take it under a proprietary licence’?” or “tell me more…”. This is because we need to know:
whether Charlie or CharlieCo owns the original code;
whether contributors assigned/transferred their copyright in their contributions to Charlie or CarlieCo (with Charlie or CharlieCo becoming the owner and then freely deciding to license those contributions under the GPL) or, as is the case with contributions to WordPress, the contributors retained the copyright but released it to the project under the GPL; and
whether Charlie or CharlieCo will distribute the code in its latest form.
The answers to these questions will determine whether the GPL permits what Charlie or CharlieCo may wish to do.
For the purpose of answering the question put to me, I’m going to chart out 3 different permutations to these questions, in three different fact scenarios. I suspect Scenario 2 is the scenario the person who asked the question had in mind, but it may help some people to chart out the different scenarios to get a better understanding of relevant aspects of the GPL.
The three scenarios
Scenario 1
In this scenario:
Charlie owned (and still owns) the copyright in the original code;
contributions to the code by third party developers were released to the project under the GPL but without any assignment or transfer of copyright ownership (i.e., the normal WordPress approach); and
Charlie will adapt the combined codebase for a different and internal project, but will not distribute the adapted code.
On these facts, Charlie can do what’s proposed consistently with the GPL. In other words, Charlie will not be breaching the GPL. This is because the GPL’s ‘license your modifications under the GPL’ requirement is only triggered upon distribution of the codebase. In this scenario as I’ve described it, there is no such distribution.
Scenario 2
Scenario 2 is the same as Scenario 1 but there will be distribution of code:
Charlie owned (and still owns) the copyright in the original code;
contributions to the code by third party developers were released to the project under the GPL but without any assignment or transfer of copyright ownership (i.e., the normal WordPress approach); and
Charlie will adapt the combined codebase for another project and sell that adapted combined codebase under a proprietary licence.
In this scenario, there would be a clear breach of the GPL. This is because Charlie is distributing the adapted combined codebase but is not licensing it under the GPL. There are actually at least two breaches: first, presumably Charlie will have removed the GPL licence statements from the original combined and GPL-licensed codebase (this alone is a breach); and second, Charlie is not licensing the adapted combined codebase under the GPL, that is, Charlie is not licensing Charlie’s own contributions to the combined codebase under the GPL (the pre-existing code components were already GPL-licensed).
Scenario 3
Scenario 3 is the same as Scenario 2, but Charlie owns all the code:
Charlie owned (and still owns) the copyright in the original code;
the copyright in contributions to the code by third party developers was transferred to Charlie; and
Charlie will adapt the combined codebase for another project and sell that adapted combined codebase under a proprietary licence.
This is an interesting scenario. It wouldn’t happen in the ‘WordPress core’ space (by which I mean the downloadable WordPress CMS) because, as noted above, contributors to WordPress core retain the copyright in their own contributions but release them under the GPL. However, it could happen in other open source contexts.
The short answer is this: if Charlie owns the copyright in all the code in the combined codebase (i.e., both Charlie’s own contributions and the contributions of others because those others transferred copyright ownership to Charlie), then Charlie can license the combined codebase as s/he pleases. As the copyright owner, Charlie can license the combined codebase under the GPL, or under a proprietary licence, or both.
This may sound counter-intuitive to some people but, from a copyright perspective, it’s not. A copyright owner can choose to license copyright code or other content s/he owns in whatever way s/he likes, and s/he can do that under multiple different licences if s/he likes. An exception to this is where a copyright owner grants an exclusive licence that precludes other forms of licensing, but that is not the case with the GPL. The GPL is not an exclusive licence. So, in this scenario, Charlie can license as s/he pleases.
Parting comment
As noted above, I suspect the person who asked this question had Scenario 2 in mind. In that scenario as I’ve described it, there would be clear violations of the GPL.
(Thanks to Kristina V for the Freedom image, available on Unsplash)
“There’s quite a big debate going on at the moment about Unsplash’s new license. See: https://wptavern.com/unsplash-updates-its-license-raises-gpl-compatibility-concerns
It would be great to a get a lawyer’s input on whether the new license is GPL compatible or not. Is it possible for individual photos to be GPL while having a restriction on the collection as a whole?”
The short answer is that the new Unsplash licence imposes a prohibition on a certain kind of use of the licensed images that the GPL would not impose, but it shouldn’t matter because the GPL doesn’t require images bundled in a distributed theme folder to be GPL-licensed and nor should this be required for themes submitted to the WordPress.org theme repository’. There is, however, a potentially important respect in which I suggest the new Unsplash licence needs to be clarified to create greater certainty for the developers of products, like themes, that contain the images as discrete files, so those developers can be confident that the end users of their products obtain the rights they need. If the new Unsplash licence is clarified as I suggest in this article, then I think Unsplash images should be able to be used for themes submitted to the WordPress.org repository.
The rest of this article sets out my reasoning for these conclusions.
The new Unsplash licence
The new licence says this:
“License
All photos published on Unsplash can be used for free. You can use them for commercial and noncommercial purposes. You do not need to ask permission from or provide credit to the photographer or Unsplash, although it is appreciated when possible.
More precisely, Unsplash grants you a nonexclusive copyright license to download, copy, modify, distribute, perform, and use photos from Unsplash for free, including for commercial purposes, without permission from or attributing the photographer or Unsplash. This license does not include the right to compile photos from Unsplash to replicate a similar or competing service.”
Discussion
A number of points can be made in relation to the new Unsplash licence.
Prior submissions to Unsplash under CC0: The vast majority of photos on Unsplash (i.e., photos submitted prior to the licensing change) were (I believe) submitted to Unsplash on the basis of CC0 (early versions of Unsplash’s terms and conditions were slightly different but I’m not going to worry about that for the purposes of this article). Prior to the licensing change, the terms and conditions said this:
“6. License granted by User
Notwithstanding any other provision herein, please be aware that by submitting, uploading, or otherwise making available Pictures to the Website, you agree to make, and are hereby making, the Pictures available to the Company and all Users under the terms of Creative Commons Zero, which means you permanently and irrevocably waive, abandon, and surrender your copyrights in and to the Pictures. Please review the terms of Creative Commons Zero, which are incorporated into this Section 6 by reference.”
Consistently with this clause, Unsplash said people could use the images under CC0:
“All photos published on Unsplash are licensed under Creative Commons Zero which means you can copy, modify, distribute and use the photos for free, including commercial purposes, without asking permission from or providing attribution to the photographer or Unsplash.”
CC0 is primarily a public domain dedication. What this means is that, in countries where it’s possible to waive or relinquish your copyright in a work, the copyright essentially falls away with the result that the photos are in the ‘public domain’. To be in the ‘public domain’, in legal terms, means there’s no intellectual property right-related restriction on the work’s use. If the waiving of copyright isn’t effective, CC0 ‘falls back’ to a very broad and permissive licence (that, simply put, lets you do whatever you want with the work).
Using photos downloaded from Unsplash prior to the licensing change: Anyone who obtained a photo from Unsplash under CC0 can continue to use it as they wish (assuming the person who first submitted it to Unsplash was the true owner or was otherwise permitted to submit it under CC0 on behalf of the true owner) and without restriction because the Unsplash licensing change is not retrospective and does not alter the freedoms that those who downloaded the photos enjoyed when they downloaded them. Unsplash’s prior FAQs recognised this (my italics):
“Can I delete a photo once uploaded?
Yes. Login to your account and go to the Manage Photos tab under Account Settings. Find the photo you want to delete and click ‘Delete photo’.
However, due to the nature of the license, once a photo is released under CC0, the license is permanent and non-revocable, which means that your photo can continue to be used by the public (though it won’t be available on the Unsplash website). For more read the Creative Commons FAQ on the CC0 license.“
Images uploaded to Unsplash after the licensing change are not released or licensed under CC0: The WP Tavern article says “Luke Chesser, co-founder of Unsplash, explained on Twitter that individual photos are still CC0-licensed and therefor GPL compatible”. As far as I can see from the Twitter page the article links to, Luke did not say this. Rather, and as the WP Tavern notes, he said:
“The Unsplash license doesn’t violate GPL and can still be used in WordPress themes. There are no restrictions on the individual photos.”
Whilst photos submitted to Unsplash prior to the licensing change were submitted under CC0, and therefore available to all who downloaded them before the licensing change without restriction under CC0, from the date of the licensing change the owner of the photo who submits the photo does not relinquish copyright or grant the ‘fall-back’ license under CC0. There is no longer any mention of CC0 in the Unsplash terms and conditions, its separate licensing page or the help questions. The position now is that the person who submits the photo retains his or her copyright in the photo and grants Unsplash a very broad licence (including the right to sub-license). You can see this in the opening to clause 6 and in clause 6.B of the terms and conditions:
“YOU OWN ALL OF YOUR USER CONTENT, INCLUDING ANY PHOTOS THAT YOU UPLOAD TO THE SITE.
…
Limited License to Us. You grant us a worldwide, non-exclusive, royalty-free license (with the right to sublicense) to host, store, transfer, display, adapt, perform, reproduce, modify, translate, and distribute your User Content (in whole or in part) in any media formats and through any media channels (now known or hereafter developed). You understand that we will not pay you for any use of your Photos and that your Photos will be made available to the public for their use without providing you attribution or compensation.”
What Unsplash itself does now is sub-license users’ photos under the terms of its own and very broad licence, as set out at the beginning of this article.
The vast majority of people have nothing to worry about: The Unsplash licence is not quite as broad as the freedoms a person obtains under CC0, given the prohibition in the Unsplash licence on compiling photos to replicate a similar or competing service, but it is still very broad and in most cases will give users everything they need. As far as I can tell, Unsplash is only intending to clamp down on competing services. The vast, vast, vast majority of Unsplash users ought to have nothing to worry about. (This doesn’t mean they can be certain they are not infringing someone else’s copyright because it’s always possible for someone to upload a photo to Unsplash without the right to do so but that was the case before the licensing change and is the case with Creative Commons-licensed images too.)
But is the Unsplash licence really broad enough for distributed products? In my view, with its new licence Unsplash has intended to allow people to bundle up images from Unsplash in their own products, whether for free or commercial distribution, just as they could before. A question and answer on the site supports this view:
“Can I use Unsplash photos as part of a product to sell?
Yes, you can use Unsplash photos as part of a product you sell. For example, using an Unsplash photo on a website that sells a product or service is fine. What we advocate against is selling an Unsplash photographer’s photo without adding to it creatively, through editing or other methods.”
However, do their own licence terms support this? As I say, I think Unsplash intends them to, but in my view they could – and should – be clearer. Remember that this is what the licence says:
“All photos published on Unsplash can be used for free. You can use them for commercial and noncommercial purposes. You do not need to ask permission from or provide credit to the photographer or Unsplash, although it is appreciated when possible.
More precisely, Unsplash grants you a nonexclusive copyright license to download, copy, modify, distribute, perform, and use photos from Unsplash for free, including for commercial purposes, without permission from or attributing the photographer or Unsplash. This license does not include the right to compile photos from Unsplash to replicate a similar or competing service.”
The issue I see is that the licence appears to be granted to the person who accesses the image file from Unsplash. The licence doesn’t actually say anything about the same rights being granted to anyone who comes into possession of the image via the person who downloaded the image or other means, e.g., through downloading a product, like a theme, that contains the image as a discrete file, and the Unsplash licence that users receive does not include a right for them to sub-license on the same terms.
I suspect the authors of the Unsplash licence have sought to replicate the freedoms of CC0 (except for the competition point) but I suggest to Unsplash that they clarify the issue I’m raising here by amending the licence to read something like this:
“All photos published on Unsplash can be used for free. Except as stated below, you and every person who comes into possession of them can use them for commercial and noncommercial purposes. There is no need to ask for permission from or provide credit to the photographer or Unsplash, although credit is appreciated when possible.
More precisely, Unsplash grants you and every person who comes into possession of the photos a nonexclusive copyright license to download, copy, modify, distribute, perform, and use photos from Unsplash for free, including for commercial purposes, without permission from or attributing the photographer or Unsplash. This license does not include the right to compile photos from Unsplash to replicate a similar or competing service.”
These changes are intended to ensure that downstream recipients of the photos receive the same licence from Unsplash. Both the GPL and the Creative Commons licences are structured in this way. Without these changes, distributors of products like website themes may be concerned that the end users of their products will not receive the rights they need to use the photos for their own purposes. Those end users could, of course, go to Unsplash and re-download the photos themselves, and Unsplash is unlikely ever to take issue with an end user’s use of a photo in this kind of situation, but theme developers and others may sleep better at night knowing that they and their end users have the rights they need.
(I’m not providing legal advice here to Unsplash or anyone else. My standard disclaimer applies and I note there is more that could be said in the Unsplash licence on the kinds of topics addressed in the Creative Commons licences.)
Copyright owners can dual-license: Incidentally, the licensing change also means that the owner of a photo can post it to Unsplash and, because he or she is retaining the copyright, license the same photo under different terms elsewhere. Unsplash does not purport to restrict the true owner from doing this (and nor should it).
“In its opinion on WordPress themes and the GPL, the Software Freedom Law Center appears to have treated image files (among others) as independent works that are, to paraphrase GPL v2, merely aggregated with the software on a volume of storage or distribution medium; for this reason, they do not need to be licensed under the GPL if their owners/contributors prefer not to.
If they are separate, independent files (they are really a form of data), one might argue that they are beyond the rationale and scope of what I consider to be the Free Software Foundation’s GPL-compatibility test (on which I think the theme review team relies) because they would not need to be part of a “derivative work” based on either the WordPress core’s or a theme’s software. Rather, they would be (or could be in the right conditions) part of a compilation that would comprise the derivative work, the image files and any other independent copyright files. The significance of this is that, if they are not part of a derivative work, then they are not caught by the GPL’s viral/propagation requirement and GPL-compatibility is not required of them. To put it another way, if someone were to make a derivative work of the GPL’d software in a theme file on WordPress.org, the ‘downstream GPL licensing of derivative works’ requirement would not apply to the images (unless they’d been separately and expressly licensed under the GPL in their own right). They could be included in the new theme files under their original licences (assuming those licences were broad enough to allow re-use by others).”
This is why I say the GPL is red herring in terms of what the GPL itself requires. (I still think the new Unsplash licence needs to be clarified though along the lines discussed above.)
The second GPL question – relevant to submission of themes to WordPress.org: Unfortunately (from the perspective of theme developers who use Unsplash images), my ‘red herring’ conclusion above is not the end of the story. There is a remaining and significant point that arises from the WordPress.org Theme Handbook. The Handbook says (my italics):
“If you wish to submit your creation to the free theme repository on WordPress.org, it must be 100% GPL compliant, including CSS and image files. Because the freedoms spelled out in the GPL are at the heart of WordPress, we encourage developers to distribute their themes with a 100% GPL-compatible license.”
As I explained in Theme reviews, CC0, model releases and GPL-compatibility, this statement should be treated as a policy call by the WordPress.org theme review team because, so far as including separate images within a WordPress theme folder is concerned, the GPL does not require ‘100% GPL compliance / compatibility’. In that article, I argued the case for allowing Creative Commons Attribution (CC-BY) and Creative Commons Attribution ShareAlike (CC-BY-SA) licensed images in themes submitted to the repository (because users would still receive all the rights they need which I think is what is important). If the new Unsplash licence is clarified in the manner suggested above, the same argument will apply to photos from Unsplash under that new licence although the argument will be stronger because the freedoms under the Unsplash licence will be broader.
Turning now to what, for some, will be a key point, in my view – if Unsplash clarifies its licence as suggested above – it would make no sense for the theme review team to reject a theme merely on the basis that it uses a photo from Unsplash that was downloaded under the terms of the new licence. To insist on that would be to insist on a level of ‘GPL purity’ that the GPL itself does not require and that, to my mind at least, would unreasonably restrict the ability of WordPress developers to use the awesome images available from Unsplash in themes submitted to the repository.
If Unsplash clarifies its licence as suggested above, thenI suggest the time will come for the WordPress.org Theme Handbook to recognise the legitimacy of using photos from Unsplash, as well as CC-BY and CC-BY-SA licensed images, in themes submitted to the WordPress.org theme repository, with accompanying guidance as to why that’s legitimate and what, in the case of CC-BY and CC-BY-SA licensed images, submitting developers need to be aware of.
(Thanks to Jan Joseph Ybanez for the fish image, available on Unsplash.com, and thanks to Unsplash for providing the world with such an awesome service.)
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
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.
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 <https://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
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: https://www.gnu.org/licenses/gpl-2.0.html
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.
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.
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:
{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: https://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: https://www.genericons.com
Image used in screenshot.png: A photo by Austin Schmid (https://unsplash.com/schmidy/), licensed under Creative Commons Zero(https://creativecommons.org/publicdomain/zero/1.0/)
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:
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: https://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: https://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 <https://www.gnu.org/licenses/>.
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
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, https://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: https://www.genericons.com
Image used in screenshot.png: A photo by Austin Schmid (https://unsplash.com/schmidy/), licensed under Creative Commons Zero(https://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
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.
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.
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.
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.
Sorry but the 100 free copies have gone.
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
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.)
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.)
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.
It’s all too easy for course creators to come up with and validate a great idea, create their course, get on with their marketing, and whack their course up on a course platform, without giving much if any thought to the legal stuff. Unfortunately, not getting the legal stuff right – getting the legal stuff wrong – can have very negative consequences. With that in mind, and to help you start thinking about the things you need to know, I’ve whipped up “17 practical legal steps to help you create great course content, protect yourself, and keep your money”.
