GPL, Licensing
comments 8

The GPL and assumptions of automatic inheritance

If you’re in a hurry, you can scream down to the bottom of the page where you’ll find, well, the bottom line.

Here’s the thing

There’s a smallish matter relating to the interpretation and application of the GPL that it might help to clear up. It concerns the topic of the GPL and inheritance. References in this post to the GPL are to version 2 of the GPL.

What we read on the web

When reading various articles on WordPress and the GPL, as well as articles on the GPL in other contexts (such as the Drupal context), it is fairly common to find references to ‘inheritance’, to the effect that ‘a derivative work inherits the GPL’. Here are some examples I’ve come across on the web:

  • “a derivative work inherits the benefits of the GPL”;
  • “[d]erivatives of WordPress code inherit the GPL license”;
  • “[i]f a plugin or theme makes a call to any WP function then that plugin or theme technically falls under GPL. Which pretty much means, any distributing theme or plugin inherits the the GPL regardless if it’s being sold or freely released”;
  • “if you make a derivative work of GPL licensed code, your derivative will also be licensed under the GPL”;
  • “[a]ccording to the GPL, code written to interface directly with Drupal (like modules, PHP code in themes, etc.) is ‘derivative work’ and automatically inherits Drupal’s GPL license”;
  • “GPL requires that any derivative work you release or distribute should be licensed under GPL as well. So while you may have the copyright to do anything you like, your derivative work automatically inherits the GPL license so others are free to use, modify, and redistribute your code in any way they choose”;
  • “[a]ny logic (PHP code, etc) built on top of WordPress automatically inherits the GPL, as it relies on WordPress. :)”; and
  • “the reason why plugins are GPL is because they hook into the core WordPress hooks and filters and functions…; by linking core WordPress GPL code, they inherit some of the, what’s called the virality of the GNU public licence”.

Many of these statements seem to assume or imply that a derivative work automatically inherits the GPL while others state explicitly that inheritance is automatic. Whilst these statements are understandable, strictly speaking they are not correct.

What the GPL says

The GPL is a copyright licence and, in essence, it works like this:

  • you can do whatever you like with the licensed program;
  • that includes making a work based on the licensed program (i.e., a derivative work);
  • but any derivative work that you distribute needs to be licensed at no charge to all third parties under the GPL.

The actual wording that the GPL uses is this:

“2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
b) 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.
… .”

Difference between downstream licensing of the original Program and subsequent licensing of a derivative work by its creator

The GPL does not say anything about the entirety of a derivative work automatically inheriting the GPL, and for good reason. A copyright licence between A and B cannot have the effect of actually licensing a derivative work by B under the same (or any other) licence. That is something that B does, not A. What the copyright licence between A and B does – what the GPL does – is require/oblige B to license distributed derivative works under the same licence, i.e., the GPL. Version 2 of the GPL says the licensee “must cause” any distributed derivative work “to be licensed… under the terms of this License”.

Now, it’s important to note that section 6 of the GPL says this:

“6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients’ exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.”

What I’ve said above is not inconsistent with section 6 of the GPL. What section 6 is saying is that the original licensor is granting a licence over its Program not only to immediate recipients/licensees, but also to anyone who subsequently obtains a copy of the Program or a derivative work based on the Program. This is how the freedoms in the GPL are spread through multiple chains of recipients (the same thing occurs under the ShareAlike variants of the Creative Commons licences). If any downstream recipient makes a derivative work and distributes it, then that recipient is likewise obliged to license the derivative work to everyone under the GPL and, if s/he doesn’t, s/he is infringing the upstream copyright licensors’ copyright.

Note here that a derivative work consists of property owned by the original licensor(s) (let’s call them A) plus new and separate property over the new original parts of the derivative work that are created by B. The derivative work is a distinct copyright work in its own right but B doesn’t obtain property rights that are greater than B’s own contribution. As a US court put it, “[t]he aspects of a derivative work added by the derivative author are that author’s property, but the element drawn from the pre-existing work remains on grant from the owner of the pre-existing work” (Stewart v Abend 495 U.S. 207, 223 (1990)).

There are, therefore, at least two property right components comprising the derivative work. Upstream licensors can grant a licence over the component they own. However, where someone else makes a derivative work with permission (as is the case under the GPL), there is a new separate component owned by the creator of the derivative work. The upstream licensors do not own that new component and, therefore, they cannot license it. This is why a subsequent act of licensing by the person that creates the derivative work is necessary. Everyone already has the permission of the upstream licensors in relation to the upstream licensors’ component because those licensors have already applied the GPL to their copyright work(s), but that alone is not sufficient to license the derivative work as a whole. The GPL ensures that the requirement to license falls upon the creator/owner of the derivative work, but only that creator/owner can actually license the new component that s/he owns.

Because that was a bit of a legal mouthful, I thought it might help to provide a diagram:gpl_diagram-4

Implications

The absence of automatic downstream licensing of the derivative work in its entirety (distinct from the automatic downstream licensing of the original GPL’d work) — the requirement for GPL licensees to actually do something — is important for two reasons.

  • First, people who wish to comply with the GPL but assume that inheritance of the GPL is automatic may not actually do what is required, when distributing their derivative works,  to comply with the GPL. To comply, they need to retain the original notices that came with the Program as they received it and, as the GPL puts it, “cause the modified files to carry prominent notices stating that you changed the files and the date of any change” and “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” (clause 2(a) and (b)).
  • Second, if a distributed derivative work does not include a notice stating that it is licensed under the GPL (either within the program itself or in a readme file or perhaps at the point of release on a website), whether accidentally or deliberately, then the derivative work is not actually licensed under the GPL. If it’s truly a derivative work then it should be, but it isn’t.

In this kind of situation, the person who has made and distributed the derivative work has breached the GPL’s requirements. This has the effect of terminating the licence that the GPL granted to that person, with the consequence that the act of distributing the derivative work is an infringement of copyright.

You can imagine this happening fairly easily in a case where a theme or plugin, for whatever reason, is truly a derivative work and is not distributed via either the WordPress.org theme or plugin repositories or a commercial theme or plugin repository that has similar standards to those of WordPress.org. The distributing developer may not be aware of the GPL’s notice requirements or may choose, for whatever reason, to ignore them.

(There won’t be any problem for themes and plugins hosted on WordPress.org. In the case of themes, the Theme Review Handbook makes it clear that themes must be 100% GPL licensed. Similarly, the plugin submission process requires a plugin’s zip file to include a completed readme.txt file that adheres to the WordPress plugin readme file standard; that standard requires the readme file to state that the plugin is licensed under the GPLv2 or later.)

Things can get messy where a derivative work should be GPL’d but isn’t. People who should be able to use the derivative work under the terms of the GPL are not actually GPL licensed and, therefore, don’t have the legal certainty to do so. To ensure that the derivative work is properly licensed under the GPL, the distributing party needs to be asked to license it with the requisite notice and he or she must actually do so for the derivative work to the GPL-licensed.
DearDeveloper

Sometimes the distributing party will do exactly that; indeed, in some cases non-compliance with the GPL may have been entirely innocent. But in other cases the distributing party may disagree that the GPL needs to be applied (given, for example, legal uncertainty as to application of the GPL at the margins) or believe that it needs to be applied but refuse to do so for commercial or other reasons (I’m not suggesting this is commonplace). If, for whatever reason, he or she refuses to do so, and someone wants to force the issue, pressure would need to be added to the mix, either through community involvement or court proceedings.

Bottom line

The bottom line is this: GPL inheritance – the obligation to license distributed derivative works with the GPL – is not automatic. Downstream licensing is required but to put it in place the distributing derivative author has to do something, namely, include a notice with the distributed derivative work stating that the work is licensed under the GPL (as described in more detail above).

8 Comments

  1. Pingback: Tackling the Issue of WordPress Derivative Works

  2. Pingback: This Week in WordPress: NUX Team Announced, and Polyphasic Sleep - WPMU DEV

  3. Pingback: Weekly WordPress News: A Better Planet Updated, Matt Interviews, WPHunt & More

Leave a Reply

Your email address will not be published. Required fields are marked *