Latest Posts

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

WordPress themes, the GPL and the conundrum of derivative works

Now, I know what some readers may be thinking – ‘not another post on the GPL/theme debate’ – but I could hardly write a blog on WP and legal stuff without considering the issue and I hope there’s a point or two in here that at least some people won’t have read before. And no, I don’t try to assert that there’s a single definitive answer.

Meet ‘theme’

In the beginning (of WordPress that is) there was no separate theming system as we know it today. Rather, the theming system that we now know and love was added in version 1.5 (“Strayhorn”), in February 2005, and has been enhanced numerous times since then.

Today, the humble theme – responsible for the layout, look and feel of a site – is a key and swappable component of virtually every WordPress installation and, as most WordPress users know, for those who don’t wish to develop their own theme there is a dazzling array of readily available themes to choose from.

A handful of Genesis themes at StudioPress

A handful of Genesis themes at StudioPress

Evolution of commercial themes and their licensing

As WordPress became more and more popular and as people began to see and leverage its value, it was inevitable that new business models would emerge. One such business model was the development and sale of premium/commercial themes.

Turning to the topic of licensing (and putting what the GPL may require to one side for now), the owners of such businesses could license their themes:

  • in their entirety under the GPL;
  • partly under the GPL and partly under an alternative licence; or
  • in their entirety under an alternative licence.

Early adopters of full GPL model

In the early days, commercial themes were not licensed under the GPL. That began to change in 2008 when Brian Gardner adopted the full GPL model for his Revolution themes (a good number of which I purchased). I distinctly remember his change in approach. It was a big deal at the time.

Brian Gardner's Revolution themes site, which would later evolve into StudioPress

Brian Gardner’s Revolution themes site, which would later evolve into StudioPress

Many others followed suit, including well-known commercial theme providers like WooThemes, GraphPaperPress and Elegant Themes. At the date of writing this post, the commercial section in the WordPress.org themes directory listed 69 commercial theme providers (a number which does not seem to include all of them) who provide themes that are fully-licensed under the GPL.

Controversy and “GPL non-compliant” models

Not all commercial theme providers applied the GPL to their themes. Some applied their own proprietary licences. This ultimately resulted in an eruption of controversy in certain parts of the WordPress community as to the application of the GPL to WordPress themes. Perhaps the most publicised and memorable instance of this was DIY Themes’ initial proprietary licensing of its Thesis theme. The developer of Thesis disagreed strongly that the GPL required Thesis to be GPL-licensed while Matt Mullenweg and others argued strongly (yet, for the most part, calmly) that the GPL required just that. Fight

The title of a post on TheNextWeb sums up just how heated the debate became: “WordPress and Thesis Go to Battle: Mullenweg May Sue”. Matt even tweeted that he would buy people a GPL’d premium theme instead of their buying Thesis. Chris Pearson and Matt debated the issue on Mixergy, with Mixergy’s owner Andrew Warner doing his best to play the role of mediator. The video of that debate is still available today (the day I write this at least) on TheNextWeb at the link above. Listening to it reveals deeply held views as to which position was correct. Matt’s earlier (and consistently held) positions can also be heard in a video on this topic on WordPress.tv: Matt Mullenweg: WordPress and the GPL.

On an expansive view of the GPL, which of the three models are considered to be GPL-compliant?

I’ve mentioned three possible licensing models above. Listening to the Pearson/Mullenweg debate might make you think there is only one option: that a WordPress theme, when distributed, needs to be licensed in its entirety under the GPL or will be non-compliant with the GPL conditions applying to WordPress itself. But even on what some would say is an expansive view of the GPL’s requirements, that doesn’t seem to be the case. Enter the Software Freedom Law Center.

Software Freedom Law Center opinion

In 2009 Matt sought a legal opinion on the GPL/theme issue from the Software Freedom Law Center (SFLC). 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.”

For me, the essence of the opinion is found in these two paragraphs:

“On the basis of that version of WordPress, and considering those themes [that is, the classic and default themes] as if they had been added to WordPress by a third party, it is our opinion that the themes presented, and any that are substantially similar, contain elements that are derivative works of the WordPress software as well as elements that are potentially separate works. Specifically, the CSS files and material contained in the images directory of the “default” theme are works separate from the WordPress code. On the other hand, the PHP and HTML code that is intermingled with and operated on by PHP the code [sic] derives from the WordPress code.

In conclusion, the WordPress themes supplied contain elements that are derivative of WordPress’s copyrighted code. These themes, being collections of distinct works (images, CSS files, PHP files), need not be GPL-licensed as a whole. Rather, the PHP files are subject to the requirements of the GPL while the images and CSS are not. Third-party developers of such themes may apply restrictive copyrights to these elements if they wish.”

So, if one accepts the SFLC opinion, there are two GPL-compliant licensing models for distributed WordPress themes:

  • licensing a theme in its entirety under the GPL; or
  • applying a “split licence” to the theme (under this licence, the PHP code and integrated HTML are covered by the GPL with the rest of the author-created components (such as the CSS and images) being covered by alternative and usually proprietary terms).

The corollary is that commercial themes that are licensed on an alternative basis are GPL non-compliant.

(The split licensing model is the approach that has been adopted for the vast majority of WordPress themes on ThemeForest (which, for most practical purposes, usually limits use of the theme to one site), despite the fact that it’s now possible for a ThemeForest theme author to apply the GPL to a theme in its entirety. It has also been adopted by a number of other commercial theme providers.)

The million dollar question

But the million dollar question remains: was the SFLC’s conclusion regarding application of the GPL to WordPress themes correct?  How did the SFLC come to the conclusion it did and is it necessarily correct that a premium theme must be at least split-licensed? This is a significant question as it seems that, for many, the SFLC opinion has become something akin to ‘GPL/theme gospel’.

The SFLC’s opinion has been written in fairly approachable and succinct terms that make it easy to read. The cost of such brevity is that it does not address key aspects of applicable copyright law in any detail. Rather, a particular version of applicable law appears to be assumed. This has not been lost on certain sections of the WordPress community. There have been some vocal disagreements with the SFLC opinion.

In discussing this broad question, I’m going to try to unpack things a little so as to put the debate in what I consider to be its correct legal context.

Cart before horse

If we stand back for a moment from the SFLC opinion and consider the debate more broadly, we can see that many discussions and views as to why WordPress themes need to be GPL-licensed (either completely or in part) have launched straight into the question of whether a theme is “derivative of WordPress” or “derived from WordPress” and why, technically, that is believed to be so, without any real discussion of the applicable copyright law and what it means in legal terms for something to be a derivative work (or, in other words, what the legal test for a derivative work is). This, with respect, is to put the cart before the horse. The discussion can become technical, philosophical and/or emotional but without proper appreciation and application of the governing legal principles.

Correct approach

To analyse the situation correctly, I think one needs to identify the relevant area of law, explain the applicable aspects of that law and how they relate to the terms of the GPL, and then apply that law and the terms of the GPL to the issue in question. (Please note that I’m not saying that the SFLC didn’t do this. Their opinion will, in all likelihood, be the output of a longer and more involved analysis behind the scenes.)

Relevant area of lawCopyright-law

The relevant area of law is copyright law. Some have argued that the GPL is (also) contractual but that is unlikely to be the case, at least in common law jurisdictions (see, for example, P Jones The GPL is a License, not a Contract, 3 December 2003; Software Freedom Law Center Guide to GPL Compliance, 2nd Edition, 31 October 2014, pp. 16-17).

So, we’re focusing now on questions of copyright. WordPress, as an overall software program consisting of a set of files (including in my view its default themes which come bundled with it), is a copyright work, either as a complete set of code or as a compilation of component files. The owners of the copyright are numerous.  Ownership does not lie with a single person or entity. It lies with its contributors. (The WordPress Core Contributor Handbook states that, “[a]s a contributor, you retain the copyright to your code, however by submitting it to trac you are releasing it under the GPLv2”.)

Simple summary of applicable aspects of copyright law

It is because WordPress is a copyright work that people need permission to copy it or modify it or distribute it. In many if not most legal systems, these acts are restricted acts that can only be exercised by the copyright owner(s) unless permission is granted allowing these acts to occur (or unless there is a statutory defence to infringement). This is where the GPL comes in. It is the means by which all the component parts of the WordPress software can be licensed under a common licence that allows copying, modification and distribution. In other words, the GPL is the means of granting permission for acts which would otherwise by prohibited as a matter of copyright law.

On a copyright analysis, it is vitally important to appreciate that the freedoms granted by the GPL are only required by people building something that will work as part of, with, or on top of WordPress (such as a theme or plugin) when, in copyright law terms, they are doing a restricted act. The most relevant restricted acts are copying the licensed program or a substantial part of it, modifying it (i.e., creating a derivative work) and distributing it. If a person’s actions do not constitute a restricted act, the person is not constrained by copyright and – significantly – is not bound by the terms of the GPL that require downstream GPL licensing upon distribution or publication of a work that “contains or is derived from the Program or any part of it”.

Copyright-related issues

It follows that the broad copyright-related issues that arise when a person develops a WordPress theme for distribution are (or at least include) these:

1. Does the creation and distribution of the particular WordPress theme involve what copyright law would characterise (by reference to the copyright and GPL’d WordPress software) as one or more restricted acts?

2. If the answer is no, the copyright analysis ceases. But if the answer is yes, is there any defence to what would be an actionable copyright infringement where the theme is developed and distributed without permission from the copyright owners?

3. If the creation and distribution of the WordPress theme does involve a restricted act and there is no defence, permission to undertake the relevant act(s) is required. This, in turn, requires adherence to the GPL and that, in turn, raises the question as to what the GPL requires, in the particular circumstances, as to downstream licensing.

WordPress theme development and restricted acts

As noted above, in many if not most legal systems, restricted acts include copying a substantial part of a work or making a derivative work (a work based on the original work). In the context of WordPress themes and the GPL, most of the argument usually centres on whether a derivative work has been made. This is because the GPL share-alike requirements turn (for the most part) on the existence of a distributed modification/derivative work. (We can put mere copying (of all or a part) of WordPress, without distribution, to one side as the GPL expressly allows this without limitation.)

The derivative work question
Derivatives
Before I get into the guts of this issue, I should note that there is a preliminary question as to whether the GPL’s downstream licensing obligation only applies to “derivative works” in orthodox legal terms as opposed to potentially broader wording in the GPL itself. If a broader test applies, the propagation requirements of the GPL would kick in more easily (making it easier to argue that themes are caught by the GPL), but many commentators consider it reasonably clear (and I tend to agree) that the GPL’s authors were focusing on derivative works in orthodox legal terms. (For a far more erudite discussion of this point, see L Determann’s Dangerous Liaisons – Software Combinations as Derivative Works? – Distribution, Installation, and Execution of Linked Programs under Copyright Law, Commercial Licenses, and the GPL (2006) 21 Berkeley Tech LJ 1421. See also L Rosen Open Source Licensing: Software Freedoms and Intellectual Property Law (2004), chapter 6, page 120.)

If we turn now to the SFLC opinion, how does it deal with the derivative work question? It states in strong terms that at least the PHP components of a theme “are derivative of WordPress” but the analysis appears to be based primarily on a technical linking/interdependence or communication analysis, on the assumption that that is the accepted legal test in this context. This is the point that lies at the heart of the debate, as the legal correctness of this approach to ascertaining whether there is a derivative work (i.e., as a matter of copyright law) is not universally accepted. It has, for example, been strongly debated in both the US and the UK (see, for example, L Rosen’s 2003 article When is one program a “derivative work” of another? and A Katz’s 2007 article GPL – The Linking Debate (available to members of The Society for Computers and Law)).

Those who argue that the above approach doesn’t reflect current (US) copyright law note the statutory definition of “derivative work” and what some courts have said must exist for a work to be derivative of another. 17 USC 106(2) defines “derivative work” as:

“‘derivative work’ is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship, is a ‘derivative work’.”

Commentators have observed that “courts have determined that to be derivative, a computer program must be substantially similar and in some form include a portion of the copyrighted work” (M Valimaki’s GNU General Public License and the Distribution of Derivative Works [2005] JILT 6 (2005) at para 3.1).

This “test for derivative work” issue is perhaps the most complex and controversial aspect of the GPL in practice. Developers, affected businesses, their lawyers and interested academics all have and are entitled to their opinions, but there are almost as many opinions as there are theme shops because a range of different arguments can be made (see and compare, for example, Valimaki (cited above), T Gue’s Triggering Infection: Distribution and Derivative Works under the GNU General Public License (2012) (1) Journal of Law, Technology & Policy 95, C Bennett’s WordPress Themes, GPL, and Copyright Case Law post from 2010, and P Enrique’s 2014 piece WordPress is GPL, must your plugin be as well?).

Who is right?

So who is right? Well, I like the words of Van Lindberg in his book Intellectual Property and Open Source: A Practical Guide to Protecting Code (O’Reilly, 2008), a book that Professor Lawrence Lessig has described as “clear, correct and deep”. Van Lindberg says this (I like the honesty of the bit I’ve emphasised):

“… there is a persistent issue that won’t go away – whether linking programs together creates a derivative work. If linking creates a derivative work, the GPL applies to the linked program; otherwise, the GPL doesn’t apply.

In legal practice, this arises as a common concern of clients just getting into open source. This questions is usually phrased as either, ‘Can I load and use a GPL-licensed library without applying the GPL to my application?’ or, ‘Do I have to apply the GPL to my plug-in for a particular program if that program is licensed under the GPL?’

I won’t keep you in suspense; the short answer is that we don’t know. For a longer, perhaps more satisfying answer you can skip to the end of the chapter [where he expresses some opinions], but this is a very complicated question.”

Gue makes a similar comment:

“Commentators diverge widely as to whether dynamic linking creates a derivative work. The inconsistency is so great that one commentator has lamented that ‘there appear to be no definitive answers to the question of what constitutes a derivative work under the GPL, not even from the holders of the license in question.’”

The reason we don’t truly know the answer is that the courts haven’t decided a case that is squarely on point (there are potentially analogous cases, of course, but – as far as I’m aware – no GPL or similar case directly on point).  It is only the courts (in the absence of legislative intervention) that can finally determine the matter. Courts might apply what some might say are orthodox notions of what it means for something to be a derivative work or they might incrementally (some might say dangerously) develop the law on this point but we just don’t know. And even if the courts of one country made a definitive ruling on the point, courts in other countries – where other lawsuits might be commenced – could decide differently. As a result, uncertainty remains.

Don’t assume equivalence

I should make another point, and that is that not all themes (or plugins) are made equal. So far as themes are concerned, we might need to consider different kinds of scenarios, such as:

  • a Thesis-style scenario where, apparently, lines of code were copied directly from WordPress (something I can’t personally confirm);
  • another scenario where someone takes the latest default theme bundled with WordPress (which must be under the GPL) and then modifies it and distributes it; and
  • a more complicated scenario where there is no copying of the GPL’d WordPress code at all (assuming, in practical terms, that that’s possible).

The legal conclusions across these three scenarios could be different. I think we need to recognise that.

To what extent does it really matter?

All the above said, and whilst having reasonable certainty as to the application of the GPL to premium themes is desirable, I suggest that, for practical purposes, it is not by itself decisive as to whether a theme owner may wish to GPL-license (or at least GPL split-license) its theme. In other words, the relevant considerations are not only legal ones. Let me explain.

The core WordPress team confers practical benefits on the providers of full-GPL’d premium themes (e.g., promotional blog posts and a listing in the commercial section of the themes repository) while (at least historically) showing a perhaps surprising level of ‘displeasure’, shall we say, not only towards those who do not release premium themes under a GPL licence at all but also (at one time) to those who only apply a split licence (despite this being consistent with the SFLC opinion). Admittedly some years ago now, that displeasure took the form of, for example, online criticism and rejection of ThemeForest members from a WordCamp (see J Caputo’s Automatically Blackballed and Un-Blackballed).

I think the GPL/theme debate has reached the stage where it’s fair to say that a significant proportion of the WordPress community now frowns upon premium theme providers who either don’t GPL-license at all or (probably to a lesser extent) split-license their themes. That mightn’t be good for business and that, for some, may be the bottom line. For some people, this frowning may be caused by a particular view of what the GPL requires but for others – and I think this is a particularly important point – it may be caused by a recognition of the enormous opportunities that WordPress makes possible and the open source spirit and generosity that pervades much of the WordPress community. I think we’ve reached the stage where, for some people, this is more about a community norm than it is about a strict reading of the GPL (not to mention the tedium of listening to more and more competing GPL arguments when, ultimately, only a court can decide).

The counter-argument to my point above, that not applying the GPL could be bad for business, is that GPL-licensing will encourage on-selling of themes by those who didn’t design them to the detriment of the theme designers. This counter-argument doesn’t appear to carry much weight. It’s true that such activity does occur but, generally, on-sellers cannot provide the support and upgrades that the premium theme developers provide. That is often what people pay for. This is a point that Matt has made repeatedly. At least in my own experience as a purchaser of many premium themes and plugins, I think he’s right.

One last thing…

The GPL/WordPress theme debate has fueled all sorts of comment, discussion and, at times, acrimony. After much of the 2009/2010 debate had aired, Mark Jaquith (a lead WordPress developer) stepped in on 17 July 2010 with Why WordPress Themes are Derivative of WordPress, a post that, at least from a technical perspective, sounded compelling. It certainly made me think and probably resulted in the loss of further brain cells as I tried to assimilate his helpful and well-crafted words into the morass of competing arguments. Mark’s firm view was that themes were derivative of WordPress:

“It is the position of the WordPress core developers that themes cannot be considered wholly original creations even when they don’t copy large sections of code in from WordPress. Theme code necessarily derives from WordPress and thus must be licensed under the GPL if it is distributed.”

I almost fell of my seat, then, when I discovered Enrique’s January 2014 piece WordPress is GPL, must your plugin be as well? In this post, Enrique strongly contests the view that plugins must be GPL’d as well. The only comment  made on the post appears to have been made by Mark Jaquith himself. Assuming the comment is genuine, this is what he said:

“Very well argued. My thinking on this matter has evolved since I wrote my post, 3+ years ago. The thing about the GPL is that it is a legal hack. For it to work, it relies on legal concepts like what constitutes a derivative work. And while some plugins could unambiguously be derivative works, I no longer think they must necessarily be so, and I suspect the majority would not be considered derivative works (by a US court, at least). Same goes with themes with the caveat that themes are more likely to contain code lifted from WordPress, so they might veer towards derivation more often than plugins do.”

I was surprised to read this and it doesn’t mean the issue has gone away but, to me, it speaks of pure honesty and integrity. It recognises that not all themes are created equal. And it recognises the important role that the courts have to play. That’s all I have to say.

The legal risk of continuing to email someone who unsubscribes from your email list

Let’s set the scene

In all likelihood, and for good reason, WordPress is the most popular blogging tool/CMS for those who wish to engage in online content marketing with a view to building an email subscriber list and sharing valuable content with those who have subscribed. These days, there are countless integrations between WordPress and email campaign providers like MailChimp and Aweber, it’s easy to enable social sharing, membership sites can be built with WordPress fairly easily, it’s easy to enable digital downloads, the list goes on.

For this reason, many WordPress users will be collecting email addresses, sending email newsletters and campaigns, and so on.

I turn now to Pat Flynn’s superb Ask Pat podcast, a spin-off of his Smart Passive Income blog and podcast. I do that because it was an episode of his podcast that gave me the idea for this post (thanks Pat). For those who don’t know, in his Ask Pat podcast, Pat takes recorded questions from members of his audience and answers them in the podcast.

In episode #212, John (a member of Pat’s audience) asked about following up with individuals who unsubscribe from your email list or podcast. Understandably Pat explained his view that, when people unsubscribe, that means they don’t want to receive any more emails and so to follow up with them with another email doesn’t make sense. I couldn’t agree more with Pat’s view. It’s just not a civilised thing to do. But some people do it nevertheless.

The risk those people run

In many countries, there’s another potential reason, a legal reason, not to do this. The potential reason is that continuing to email someone who has unsubscribed could result in your breaching anti-spam laws. That, in turn, could result in the unsubscribed getting stroppy with you (they might even bad-mouth you about legislative non-compliance on Twitter or Facebook) or complaining to whatever agency or authority enforces your anti-spam laws.

The-law

Not every country in the world will have anti-spam laws but a good number do. See, for example, this list on Wikipedia and this list maintained by MailChimp. In many if not most countries, the focus is on unsolicited commercial electronic messages or unsolicited direct marketing (e.g., New Zealand, Australia, United States, United Kingdom, Canada). In some countries, the primary purpose of the message needs to be commercial (e.g., the United States’ CAN SPAM Act; on this point see the Federal Trade Commission’s CAN-SPAM Act: A Compliance Guide for Business). In others (such as Australia, Canada and New Zealand) it suffices if a purpose (i.e., one of the purposes) is commercial. Messages can be commercial in nature, for example, when they are offering, advertising or promoting goods or services. This would include, for example, emails that promote the sale of ebooks, online courses, commercial themes and plugins, or WordPress consulting services.

Some countries have adopted an opt-out approach to their anti-spam laws, under which a business can send commercial messages unless the recipient informs the sender that it no longer wishes to receive them (United States). Others have adopted an opt-in approach, under which commercial emails can only be sent to people who have consented to receiving them (which in many countries can be actual or implied/inferred) (e.g., Canada, Australia, New Zealand, United Kingdom, other European Member States).

Now, here’s the important point: when a person unsubscribes from your email list, that person will be opting out or withdrawing consent previously given. To continue sending commercial emails to that person would amount to your sending unsolicited commercial messages which, in turn, would likely result in your acting unlawfully.

For example:

  • section 5(a)(4) of the US CAN SPAM Act 2003 states that ‘if an email recipient makes a request using an unsubscribe mechanism not to receive some or any commercial electronic mail messages from a sender, then it is unlawful for the sender to initiate the transmission to the recipient, more than 10 business days after the receipt of such request, of a commercial electronic mail message that falls within the scope of the request’;
  • under section 9(2) of New Zealand’s Unsolicited Electronic Messages Act 2007, ‘if a recipient uses an unsubscribe facility…, the recipient’s consent to receiving a commercial electronic message from the sender is deemed to have been withdrawn with effect from the day that is 5 working days after the day on which the unsubscribe facility was used’; and
  • under section 11(3) of Canada’s Anti-Spam Law, a person who sends a commercial electronic message must ensure that effect is given to an unsubscribe indication ‘without delay, and in any event no later than 10 business days after the indication has been sent, without any further action being required on the part of the person who so indicated’.

So there you have it. In many countries Pat’s sense or what’s right and wrong is entirely consistent with, and is buttressed by, legal prohibitions on sending unsolicited commercial messages, or spam for short.

Trademark image

Using the WordPress trademarks for your business, product or service

Introduction

If you’re a budding WordPress developer, designer or entrepreneur, you may be whipping up a creative storm and readying it for release. It might be a theme shop, a Gravity Forms-quality plugin, a WordPress-tailored hosting environment, a WordPress support agency or an app-making platform. The product or service is nearing release and you’re amping to “get it out there”. You love WordPress and you want to sing its praises from the rooftops, including in some way in the naming, description or marketing of your product or service. What better way to access your target audience than by using “WordPress” and its associated marks left, right and centre. Right?

Well, before you go using the WordPress name and logo in your naming and marketing, you might want to note that Automattic Inc and (more significantly now) the WordPress Foundation have a bunch of trademarks. Make sure you stay on the right side of the line of what’s permitted and what’s not. To help you understand all this, I’ll explain what a trademark is, Automattic’s and the WordPress Foundation’s WordPress trademarks, the enforcement of trademark rights, Automattic’s transfer of certain trademarks to the WordPress Foundation and key aspects of the Foundation’s Trademark Policy.

What is a trademark?

A trademark is, in essence, a brand or logo. Trademarks enable businesses to distinguish their products and services and to create a distinctive and hopefully memorable brand that customers associate with those products and services.

Thanks to John Eckman for sharing this photo under a CC BY-SA 2.0 Generic licence.

Thanks to John Eckman for sharing this photo under a CC BY-SA 2.0 Generic licence.

Trademarks can include, for example, words, logos, colours and shapes or a combination of these things. Although registration is not mandatory, it has several advantages. As the United States Patent and Trademark Office explains, these advantages include “notice to the public of the registrant’s claim of ownership of the mark, legal presumption of ownership nationwide, and exclusive right to use the mark on or in connection with the goods/services listed in the registration”. In many countries, having a registered trademark for your product or service usually provides you with greater or more readily enforceable rights than you might otherwise have for your product or service. Trademarks can be valuable business assets.

Automattic Inc’s WordPress trademarks

Thanks to Scott Beale for sharing this photo under a CC BY-NC-ND 2.0 licence.

Thanks to Scott Beale for sharing this photo under a CC BY-NC-ND 2.0 Generic licence.

Automattic Inc was formed in 2005 (you can find the Delaware corporation’s details by searching on “Automattic” at https://delecorp.delaware.gov/tin/GINameSearch.jsp). Over the years, Automattic has registered (or sought registration for) at least the following WordPress-related trademarks (it has also applied to register trademarks for the likes of JETPACK and CODE POET but I don’t list them here):

  • WORDPRESS, as a word, in relation to “[d]ownloadable software program for use in design and managing content on a website” (serial number 78826938, filed on 1 March 2006 and registered on 23 January 2007);
  • WORDPRESS, as a standard character mark, in relation to “[d]ownloadable software program for use in design and managing content on a website” (serial number 78826734, filed on 1 March 2006 and registered on 23 January 2007);
  • W WORDPRESS, the current word mark/logo consisting of the stylised W and WordPress, in relation to “[d]ownloadable software program for use in design and managing content on a website” (serial number 78826938, filed on 1 March 2006 and registered on 23 January 2007); and
  • W, the stylised W word mark/logo, in relation to “computer software for use in design and managing content on a website and enabling internet publishing” (serial number 85023661, filed on 26 April 2010 and registered on 5 July 2011);
  • JETPACK WORDPRESS.COM (serial number 86233988, filed for registration on 27 March 2014; according to TESS (see below), this one was abandoned in October 2014).

(You can find the United States Patent and Trademark Office’s records of the trademark filings at the United States Patent and Trademark Office’s Trademark Electronic Search System (TESS).)

Enforcement of rights

In the early days of WordPress, it was fairly common for WordPress advocates and budding WordPress entrepreneurs to use the name “WordPress” in their domain names, site names and even business names, regardless of this being inconsistent with Automattic’s rights in the name.

Automattic sought to put a stop to that fairly early on, as it was perfectly entitled to do. For example, a blog post by Andy Wibbels in October 2006 records the text of an email that an employee of Automattic Inc is said to have sent to a site owner that was using “WordPress” in its domain name and product without permission. Automattic is said to have asked the recipient to stop using its trademark to market the recipient’s services and to have asked how long it would take the recipient to change the name of its site and product (see WordPress is a Registered Trademark of Automattic, Inc).

More recently WPTavern’s Jeff Chandler has also explained, in a helpful post on the subject in which he reproduces an email exchange with someone who unwittingly used “WordPress” in its domain name, that he “usually send[s] out a friendly email to anyone violating the trademark as it’s best to deal with it early versus having that domain be established” (see Friendly Reminder About The WordPress Domain Trademark, 20 July 2013).

Transfer of WordPress trademarks to the WordPress Foundation

Thanks to Eva Blue for sharing this photo under a CC BY 2.0 Generic licence.

Thanks to Eva Blue for sharing this photo under a CC BY 2.0 Generic licence.

On 9 September 2010, Matt Mullenweg announced that Automattic had transferred the WordPress trademark to the WordPress Foundation, “the non-profit dedicated to promoting and ensuring access to WordPress and related open source projects in perpetuity”.  As Matt noted on his blog, this meant that the most central piece of WordPress’s identity had become fully independent from any company.

This was, as Matt noted, a pretty dig deal, as Automattic – a commercial organisation – had donated one of its most valuable assets and ceded control of it to a non-profit organisation.

Why did Automattic do this? This wasn’t, after all, the approach that most commercial enterprises would take to a valuable business asset. The answer to why Automattic did it is this: it was in the best interests of the wider WordPress community. This is how Matt put it:

“Automattic might not always be under my influence, so from the beginning I envisioned a structure where for-profit, non-profit, and not-just-for-profit could coexist and balance each other out. It’s important for me to know that WordPress will be protected and that the brand will continue to be a beacon of open source freedom regardless of whether any company is as benevolent as Automattic has been thus far.”

(For earlier encouragement for Automattic to do this, see F Branckaute’s Automattic, Inc: The Time To Return WordPress To The Community Has Come, 13 July 2007) . I don’t know whether that encouragement was relevant to Automattic’s decision.)

Cool, so I can use the WordPress trademark right?

Steady on… not so fast. If you want to use a WordPress trademark you’ll need to make sure you comply with the WordPress Foundation’s Trademark Policy. The key points to note are these:

  • You need to obtain permission from the WordPress Foundation to use the WordPress or WordCamp name or logo as part of any project, product, service, domain or company name (the Policy explains the circumstances in which the Foundation will grant permission).
  • Do not use WordPress or WordCamp as part of a top-level domain name. (If you look at the separate Domains policy, you’ll see that the primary concern is with top-level domains. That page states that “‘WordPress’ in subdomains is fine, like wordpress.example.com”. It should follow, I would have thought, that using “wordpress” in a subfolder, e.g., example.com/wordpress, is equally fine.)
  • The Policy allows you to use the WordCamp name and logo in the following situations: you are using the logo on the official site for a WordCamp that has been approved by WordCamp Central or you are using a graphic provided by a WordCamp to promote the event or the fact that you are attending, speaking, volunteering, or sponsoring the event.
  • All other WordPress-related businesses or projects can use the WordPress name and logo to refer to and explain their services, but they cannot use them as part of a product, project, service, domain, or company name and they cannot use them in any way that suggests an affiliation with or endorsement by the WordPress Foundation or the WordPress open source project. This is an important distinction to grasp. The WordPress Foundation is saying that, whilst you cannot use WordPress as part of a business / product / service name, you can use it to describe the business / product / service. The Policy provides these helpful examples:

“For example, a consulting company can describe its business as ‘123 Web Services, offering WordPress consulting for small businesses,’ but cannot call its business ‘The WordPress Consulting Company.’ Similarly, a business related to WordPress themes can describe itself as ‘XYZ Themes, the world’s best WordPress themes,’ but cannot call itself ‘The WordPress Theme Portal.'”

  • Similarly, it’s OK to use the WordPress or WordCamp logo as part of a page that describes your products or services, but it is not OK to use it as part of your company or product logo or branding itself.
  • The abbreviation “WP” is not covered by the WordPress trademarks, meaning people may use as they see fit. (This is why you’ll see WP being used in so many different ways across the WordPress ecosystem, e.g., WPTavern, WPMU DEV, WP Engine, WP Elevation, Wpshower, WP Valet, WP and Legal Stuff, and so forth. The same can be said for the word “Press”, e.g., StudioPress, WerkPress, TablePress, Marketing Press, AppPresser and so on.)
  • When in doubt, contact the WordPress Foundation (or a trademark lawyer) for clarification (something which, perhaps, some of the companies listed on Open Corporates with “WordPress” in their name should have done or may wish to do).

Just one other thing. When you are allowed to and wish to use a WordPress logo, make sure you use the right one. You can find them at wordpress.org.

The GPL and the story of WPScan and Vane

The debate

By now, many in the WordPress community will have heard about the WPScan/GPL debate. Personally I was a bit late to the party on this one but, thanks to a tweet from ManageWP this morning, I’ve now read a bit about it.

I’m not expressing a legal conclusion

Now, I don’t want to wade into this specific debate and try to express a legal view on what’s right and wrong here because I don’t know the facts well enough. Instead, I’m just going to state a few propositions that I believe reflect copyright law (in many countries) and the requirements of the GPL. I leave open how they might apply to this situation and, to be clear, I’m not providing any legal advice to anyone that reads this post. My usual disclaimer applies (I know that sounds a bit OTT but I’m just exercising a lawyer’s caution).

The propositions

So, without further ado, here are those propositions I mentioned:

Sole copyright owner can do what she wants:  A person (or company), lets call her A, that owns all copyright in a new work (such as a software program) is entitled to release that work under whatever licence or licences she chooses. (The words “all copyright in a new work” are important, as we’ll see below.)

Multiple licensing is OK: A may license this work (one in which she owns all the copyright) under the GPL or under a proprietary licence or both. Applying the GPL to the work does not prevent A from subsequently licensing the work under a different licence. This is because she is the owner and because she has not, by licensing it earlier under the GPL, granted an exclusive licence which would otherwise prevent her from licensing it to others by alternative means. As the sole owner of the copyright work, she has the exclusive right to do ‘restricted acts’ (acts such as copying, adapting and distributing the work, and licensing others to do these things) as she pleases.

Recipients of GPL’d version get the GPL freedoms:  At the same time, anyone who obtains the work under the GPL is entitled to exercise the freedoms that the GPL confers in relation to the GPL’d version. The existence of a different licence over another version (regardless of whether the content is the same) is irrelevant.

A continues development as owner, not licensee:  When A, the owner, continues development on her own work that she has GPL licensed, she is not making a derivative work of someone else’s copyright work. If she was, she would be obliged to obey the GPL’s downstream licensing requirements. But she is not. She is adapting her own work. Let’s look at the language of version 2 of the GPL. The (in)famous clause 2(b) says 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:

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

This is an obligation cast on licensees by the licensor, A. The “You” in this clause refers to licensees, not the licensor (A).

But if A’s work is a derivative work of a GPL’d work, the GPL licensing requirements kick in on distribution: However, things can get trickier than this. If the work in question is actually a derivative work of someone else’s, or other people’s, GPL’d work, A (in this discussion) would be a licensee. She needs a licence to make that derivative work. The GPL authorises this but on the clear condition that her derivative work, when distributed or published, contains the GPL licence statements and is licensed for use by others under the GPL. Now, to the extent that she develops her own original code, she is the owner of that code, but the derivative work actually consists of two copyright components: the original GPL’d work (or part of it) and the new code. A does not obtain property rights in the derivative work that are greater than her own contribution. If she doesn’t obey the GPL’s requirements, her distribution of her derivative work becomes an infringement of the original owner’s copyright.

What if A’s solely owned GPL’d work is contributed to by developers who license their contributions under the GPL?  What about the scenario where A’s work, when initially licensed under the GPL, contained only A’s code (and couldn’t be said, for argument’s sake, to be a derivative work) but is subsequently contributed to by other community members (let’s call them B, C and D) who, because they’re contributing to GPL’d code, license their contributions under the GPL. Assuming that these contributions qualify for copyright, the resulting work is now a collection of different property rights. No longer can A be said to be the sole owner of the resulting work. At this point, A’s ability to license the resulting work under whatever licence she chooses, when she distributes or publishes the resulting work, falls away. It falls away because, as she is now a co-contributer (even if the primary one), she is bound by the obligations cast on her under the GPL by B, C and D in their position as licensors. Going back to the wording of clause 2(b), she is now a “You” and, as a result, 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”. The “Program” here is B’s contribution. And C’s contribution. And D’s contribution. The ‘resulting work’ I mentioned above now contains the Programs of B, C and D (or, perhaps in some cases, parts of them). A can still license her original work (i.e., without B, C and D’s contributions) under any licence she chooses, but the same does not apply to the resulting work that contains B, C and D’s contributions.

What if A’s solely owned GPL’d work is contributed to by developers who assign copyright? But wait, there’s another scenario. It’s the same as the previous scenario but, instead of B, C and D licensing their new original contributions under the GPL, they are required by a contribution agreement to assign any copyright in their code to A upon submission. In this scenario, A remains the owner of all copyright in the resulting work. Because she remains the sole owner, she can continue to license the resulting work under whatever licence she likes.

What if Mr X obtains GPL’d version 1 but A licenses version 2 under a proprietary licence? Now, what is the position where A licenses version 1 under the GPL, A subsequently decides to apply a proprietary licence to version 2 of the work in circumstances where she can as full copyright owner, and a developer, let’s call him Mr X, wants to copy and adapt the original GPL’d work and then sell it. Mr X is perfectly entitled to do so and it would be quite wrong (in my view, anyway, and certainly from a legal perspective) to castigate Mr X as a pariah or anything of the sort. If you play in the GPL sandpit you need to understand the sand it contains, what you’re getting into and what licensees are entitled to do when they’re in there with you. A’s act of subsequently applying a different, proprietary licence to version 2 of the work (either a version with the same content or a truly new version) does not have the effect of revoking the GPL that applied to the original work. The GPL is generally considered to be irrevocable which means that anyone who obtains a copy of a GPL’d work may exercise the freedoms that the GPL grants, subject only to complying with its conditions.

What if Mr X took a newer version licensed under a proprietary licence? If, in this same general scenario (i.e., where A owns all the copyright), Mr X took a newer version of A’s software that was only licensed under a proprietary licence, and sought to use it in a way that went beyond the permissions in that licence, Mr X would be infringing A’s copyright.

Let’s close

I think that’s enough for now. I hope it’s helpful and doesn’t ignite further flame wars. Let’s not forget that we’re all here together on this pale blue dot, a dot that has more web-related and open-sourced opportunities for us all than it did before Michel Valdrighi, Matt, Mike Little and the many others got stuck into WordPress and made it the fantastic CMS it is today.

As I’ve said above, I’m not commenting on the specific facts of the WPScan case. I don’t know the specific facts in relation to the codebase, whether it was a derivative work in the first place, who contributed how much code to it and so forth, and so can’t purport to express a legal conclusion on it. I’ll leave that to others with more information than me. Good luck (as these questions can be tough at times for everyone involved).

Understanding the GPL licensing of WordPress

(Note: I wrote this post before I learned of the WPScan debate. Nothing in this post was written with that debate in mind. I’ll leave that for the next post… .)

Licensing

As I’ve noted previously, WordPress is licensed under the GNU General Public License (GPL), version 2. The text of version 2 of the GPL has accompanied every release of WordPress since its inception, in the license.txt file included in each download. Originally, and until version 3.2 of WordPress, the license.txt file was a verbatim reproduction of the GPL, with no reference to b2 or the WordPress contributors. Matt and his co-developers had, instead, included full attribution to b2 and Michel Valdrighi in the readme.html file included with each download. For example, in the open source spirit that pervades the WordPress community and which Matt has championed from the outset, the readme.html file in version .71 of WordPress said this:

“WordPress is built from b2, which comes from Michel V. We wouldn’t be here without him, so why don’t you grab him something from his wishlist?”

Nice.

As WordPress matured, each download continued to include a license.txt file and a readme.html file but, with the release of version 3.2 of WordPress, Matt and his co-developers added to the wording of the license.txt file. From that point forward, the license.txt file has commenced with this wording (the only change in subsequent versions being the year of copyright):

“WordPress – Web publishing software

Copyright 2011 by the contributors

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 incorporates work covered by the following copyright and
permission notices:

b2 is (c) 2001, 2002 Michel Valdrighi – m@tidakada.com – https://tidakada.com

Wherever third party code has been used, credit has been given in the code’s
comments.

b2 is released under the GPL

and

WordPress – Web publishing software

Copyright 2003-2010 by the contributors

WordPress is released under the GPL”

Understanding the GPL

Freedoms

The GPL is an open-source software licence that is designed to protect four fundamental freedoms that are considered to underpin “free software”, namely, the freedom to:

  • run the software for any purpose;
  • study how the software works through access to source code and to freely adapt it;
  • redistribute copies of the software to anyone; and
  • improve the software, and redistribute those improvements to anyone.

Versions

First written by Richard Stallman and the Free Software Foundation (FSF) in 1989, the GPL has continued to evolve through successive versions. Version 2 was released in 1991 and version 3 was released in 2007. Version 3 is the latest version.

As noted above, WordPress is released under version 2 of the GPL, although the introductory section in the licence now states that “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”.  Clauses or paragraphs in the GPL are called “sections”.

Summarising the GPL

From the perspective of opening up software for use by others, the GPL was and remains a well-crafted open source licence. At the same time, it uses legally-oriented language with which many WordPress users may be unfamiliar. In addition, and unlike the Creative Commons licences for other forms of copyright works, the GPL doesn’t have a simplified “human readable deed” (as Creative Commons calls the summary of its licences). For these reasons, the true meaning and impact of the GPL might not be immediately apparent to some WordPress developers, designers and users.

To boil things down, the following box summarises key aspects of version 2 of the GPL. It doesn’t summarise all clauses. Rather, it summarises those that are most relevant to WordPress users on a day-to-day basis.

A summary of the GPL


Copying and distribution
: You may copy and distribute the program as long as you comply with some copyright notice and disclaimer requirements. Those requirements are that you publish on each copy 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. (Section 1)

Fees: You may, if you wish, charge a fee for transferring a copy of the Program and/or for warranty protection. (Section 1 as well)

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

Distributing non-source forms: You may copy and distribute the program or a work based on it in object code or executable form, on the terms of sections 1 and 2, as long as you accompany it with either:

  • the complete corresponding machine-readable source code; or
  • a written offer (valid for at least 3 years) to give any third party the source code, for a charge that is no more than the cost of distribution; or
  • information you received as to such offer (this option is allowed only for noncommercial distribution and if you received the non-source form(s) with such an offer (Section 3).

Termination: If you copy, modify, sublicense or distribute the Program other than as permitted, your rights under the GPL will terminate automatically. (Section 4)

Downstream licensing: Downstream recipients of the Program or any work based on it automatically receive a licence from the original licensor to copy, distribute and modify the Program on the terms of the GPL. As a distributing licensee, you are not allowed to impose any further restrictions on the recipients’ exercise of the rights under the GPL. (Section 6)

The GPL in a small nutshell

A super-condensed summary would be along these lines: you can copy and distribute the program, you can charge a fee for transferring the program or providing warranty protection, and you can modify the program and distribute your resulting derivative work. But, if you distribute your derivative work, you need to license it under the GPL, otherwise your licence to use the program will terminate (and you’ll be infringing copyright in the program). 

Qualifications

Whilst many parts of the GPL are abundantly clear, certain aspects are, unfortunately, more complicated than the above summary might suggest. In particular, one needs to be aware of some important qualifications as to how the requirements relating to modifications / derivative works are intended to apply. The full text of section 2 should be consulted for the detail but key points are these:

  • the intent is to control the distribution of derivative or collective works based on the Program, not to “contest your rights to work written entirely by you”;
  • if identifiable sections of the modified work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then the GPL does not apply to them when distributed as separate works;
  • however, 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 the GPL; 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 GPL]”.

As we will see in a later post, the intended meaning and scope of the modifications / derivative works provisions have been the subject of considerable debate for many, many years, including within the WordPress community. (Yep, in a later post, I’m going to wade into the topic of the GPL and commercial themes. I need to take a few deep breaths before doing so.)

GPL-related WordPress questions

GPL-questions

It’s fairly easy to summarise most key aspects of the GPL but the rubber hits the road when people come to apply it in practice. For this reason, I’ve set out below a range of GPL/WordPress questions that do or may arise in practice and have sought to answer them. Note that I’ve deliberately not addressed the question of the extent to which commercial themes may need to be licensed under the GPL (as mentioned above, that’ll be the subject of a later post). When I use a term like “GPL’d theme”, I’m saying that the theme has been licensed under the GPL.

If I modify the core WordPress software or a GPL’d theme or plugin, must I release the source code of the modified versions(s) to the public?

If you are using the modified version privately without distribution, then you do not have to release the source code of the modified version to the public. However, as the Free Software Foundation puts it, “if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program’s users, under the GPL.”

If I know that someone has developed a WordPress theme or plugin for private use, can I require that person to give me a copy of the theme or plugin?

No, the GPL does not require this.

I take a GPL’d theme or plugin from the WordPress theme or plugin repository, or I purchase a GPL’d theme or plugin from a commercial provider, and then I modify the theme or plugin for my own purposes. Am I obliged to release my modified version to others?

No, you are not obliged to release your modified version to others.

Can I sell the core WordPress software for a fee if I want to?

Yes. Doing so is consistent with the freedoms in the GPL. However, trying to do so would be pointless and unlikely to earn you any money, as everyone knows or could easily find out that WordPress is freely available at wordpress.org.

I’m a theme/plugin developer. I’ve put huge effort into writing my theme/plugin and I’m going to release it under the GPL but I want to make sure that everyone who receives my theme or plugin, even if from someone else, is obliged to pay me a licensing fee or notify me that they have it. Can I do that?

No. As the Free Software Foundation puts it, the “GPL is a free software license, and therefore it permits people to use and even redistribute the software without being required to pay anyone a fee for doing so.” Similarly, if someone receives a copy of GPL’d software, that person does not have to inform the developer that s/he has it. You are entitled to charge a fee for access to support and later versions, but this is quite different to requiring recipients to pay a licensing fee for merely using the software.

I’m a commercial theme or plugin developer. I sell my GPL’d theme or plugin online, behind a pay wall. People can only access the theme or plugin files after paying my prescribed fee. Does the GPL allow me to do this?

Yes. You are entitled to charge a fee for distributing copies of GPL’d software. Note, however, that anyone who obtains a copy is entitled to release it to anyone else, with or without charge; the GPL allows this to occur.

I’m the same commercial theme or plugin developer mentioned above, selling my GPL’d theme or plugin online behind a pay wall. As a commercial operator distributing a GPL’d program, am I obliged (e.g., if someone asks) to make my theme or plugin available to a member of the public for free?

No. However, as noted above, anyone who obtains a copy is entitled to release it to anyone else, with or without charge.

I’ve purchased some GPL’d themes or plugins from a commercial theme or plugin provider. May I sell those themes or plugins from my own website for my own benefit or publish those themes or plugins on my own website and give them away for free?

Yes, under the GPL, you may do either of these things (or both on separate sites if you were so inclined). Bear in mind, however, that some in the WordPress community are likely to frown on such activity and that you are unlikely to be able to provide (or may not wish to provide) the support that the developers/owners can provide.

I’m happy for other people to use my themes and plugins for free. Indeed, that’s why I released them under the GPL and put them in the WordPress theme or plugin repository. I would, however, like to be acknowledged as the author of the theme or plugin in cases where users share the theme plugin with others or modify the theme or plugin. Can I require that?

Yes. As the Free Software Foundation puts it, you “can certainly get credit for the work. Part of releasing a program under the GPL is writing a copyright notice in your own name (assuming you are the copyright holder). The GPL requires all copies to carry an appropriate copyright notice.”

What practical steps can I take if I believe a theme or plugin developer is violating the GPL?

Various things. You could try to raise the matter with:

  • the developer/owner in question (with a view to explaining what you consider to be a GPL violation);
  • the core developers of WordPress (to see whether they, as the principal copyright holders, are interested in getting involved); and/or
  • the wider WordPress community (with a view to evoking community support).

I suggest that raising it with the developer/owner in the first instance is preferable to going straight to the WordPress core developers or the wider community, as sometimes an individual developer/owner may not appreciate what the GPL requires in a particular situation or may have an explanation that meets your concerns. All this said, if your concern relates to not licensing a theme or plugin under the GPL, I suggest it’s important to note that the extent to which themes and plugins must be licensed under the GPL is a thorny and controversial issue (that I’ll be addressing, in relation to themes, in a later post). There is unlikely to be a single definitive answer to this question which applies to every single theme and plugin.

Automattic, open licensing and open data

The open spirit of WordPress

Everyone knows that the founders of and contributors to the WordPress software at WordPress.org wholeheartedly embrace the spirit of open source software. The GPL (the open source licence under which WordPress is licensed) sits at the centre of what they do and Matt Mullenweg, for example, speaks passionately about the GPL and champions the cause it represents (and those that defy the GPL’s requirements (or spirit) when the community thinks it applies (or should be applied) may, well, be frowned upon). Here’s an example of Matt speaking about the GPL:

From software to other creative content

Whilst copyleft has its origins in the software world, the open source software movement is now a subset of the larger world of open licensing and open data. Various licences and tools exist to enable people to share not only their software but also their creative content and other data on standardised terms that are quick and easy to put in place.

Automattic’s generosity

Not surprisingly given its founders, Automattic has always contributed back to the WordPress core and has always supported open licensing of software, consistently with its mission of democratising publishing. What may be less well-known is that Automattic also embraces open licensing of literary content. Considerable value can be locked up in such content and Automattic, consistently with its approach to a good deal of software, has unlocked quite a bit of it through applying Creative Commons licences to it. I thought it might be helpful to draw attention to this because, as Automattic puts it in its Privacy Policy, the company “spent a lot of money and time on [in this case, its privacy policy], and other people shouldn’t need to do the same”. Automattic repeats this sentiment in other content it has openly licensed for re-use.

Those not familiar with Creative Commons licensing might like to take a look at this helpful video commissioned by Creative Commons Aotearoa New Zealand. It does a great job explaining what the Creative Creatives licences are about and how they work (and it too is Creative Commons licensed so you can copy and mash it up to your heart’s content):

So what content has Automattic openly licensed and on what terms? I’m sure I’ll be missing something but here’s a starter for 10:

  • the WordPress.com Terms of Service are licensed under a Creative Commons Attribution ShareAlike 3.0 Unported licence (CC BY-SA 3.0);
  • Automattic’s Privacy Policy is licensed under a Creative Commons Attribution ShareAlike 2.5 Generic licence (CC BY-SA 2.5);
  • content on Automattic’s Transparency site is licensed under a Creative Commons Attribution-ShareAlike 4.0 International licence (CC BY-SA 4.0);
  • the Akismet Terms of Use are licensed under a Creative Commons Attribution ShareAlike licence (although whoever prepared the page forgot to specify or add a link to which version of the licence applies); and
  • Automattic is placing various legal documents into a GitHub repository which are licensed under a Creative Commons Attribution ShareAlike 3.0 Unported licence (at the date of this post, the documents comprised the Automattic Privacy Policy, the WordPress.com Terms of Service and the Legal Guidelines available at https://transparency.automattic.com/legal-guidelines/ for those seeking information about a WordPress.com user or looking to take action against a resource hosted on  the WordPress.com network).

(It’s also interesting that, to “the extent possible under law, Automattic, Inc. has waived all copyright and related or neighboring rights to the declarative code that is necessary for function calls to the Automattic APIs as well as the structure, sequence and organization of the Automattic APIs” under the Creative Commons public domain dedication tool known as CC0 (pronounced CC zero). See the WordPress.com developers guidelines for the detail. This is different to the licensing of the kinds of copyright content listed above but it’s notable nevertheless.)

What this all means

Whilst different versions of the Creative Commons Attribution ShareAlike licences have been applied to the different items of content referred to above, the key elements of this particular licence common to all versions are that it lets others copy, adapt and share the work, including for commercial purposes, as long as they credit Automattic and license their new creations under the same terms. Note that the obligation to license new creations on the same terms only applies where the person making the new creation shares that creation with others. If a licensee makes a new creation purely for personal purposes, the obligation to share alike on the same terms does not apply. In this regard the licence is like the GPL is for software.

(Incidentally, Automattic might like to make all of the licences consistent by updating the older versions to the Creative Commons Attribution-ShareAlike 4.0 International licence it uses on its Transparency site 🙂 This isn’t a big deal but the latest Creative Commons 4.0 licences are better and more user-friendly than their predecessors. Just saying. Happy to help if need be.)

Anyway, this is all great stuff on Automattic’s part. The WordPress.com terms, for example, could be a handy starting point for those setting up their own WordPress platforms running on WordPress multisite. The same can be said for Automattic’s Privacy Policy where an organisation’s handling of personal information is similar to that of Automattic. Hell, a developer has even tried to make life easier for people by releasing an Auto Terms of Service and Privacy Policy plugin that, to quote the plugin’s page in the repository:

“Puts your own information into a version of Automattic’s Terms of Service and Privacy Policy … that have been modified to exclude specifics to Automattic (like mentions of “JetPack”, “WordPress.com”, and “VIP”) and have more generic language that can apply to most any site or service provider, including single sites, subscription sites, blog networks, and others.”

Beware of cookie-cutting

Being a lawyer, I should say it’s important to appreciate that you cannot necessarily cookie cut, say, the WordPress.com Terms of Service or Automattic’s Privacy Policy and assume they’ll be fit for your own purposes. In all likelihood that will not be the case as your own operations and requirements need to be considered, your own handling and treatment of personal information must be assessed and your overall circumstances are unlikely to mirror those of Automattic. In addition, if you’re not based in the United States, the privacy laws that apply may be significantly different to those that apply to Automattic.

That said, great stuff

All that said, the fact remains that Automattic’s release of these legal documents (or “legal mumbo jumbo” as Automattic calls the Akismet Terms of Use) under a Creative Commons licence is great stuff and may, at the very least, help some people and organisations avoid or at least reduce their legal bills. That seems to have been the case for one fellow who blogged this:

“Liberally riffing off WordPress.com’s terms of service to produce similar for the J-School. Thank you Automattic for your support of Creative Commons.”

Cool.

Thanks to Thomas Hawk for sharing his photo of Automattic HQ under a Creative Commons Attribution-NonCommercial 2.0 (Generic) licence.

Legal checks when building a content-driven WordPress website

Introduction

Recently I’ve built two blogs (both running on WordPress of course). The first is this one and the second is a blog for a group of lawyers in the United Kingdom. The purpose of the second blog is to enable the lawyers to share their knowledge and thoughts on a particular area of practice with clients, potential clients and the wider legal community. As well as building the site, I also attended to the usual legal and related issues that arise with a content-driven website like a blog, just as I did for this site which is similar in many ways.

I’ve done this sort of thing many times in the past, for myself, for colleagues and for clients. Each time I do it, I run through a range of legal and related checks in my mind that ought to be covered off. I thought it might be useful to document the checks for others building similar sites. The purpose of this post, then, is to do exactly that.

The checklist covers the kinds of legal and related issues that arise for a content-drive site that:

  • runs on WordPress (or, to be fair, any other CMS);
  • is rich in original content;
  • uses third party images;
  • allows other people to add comments, posts or other material;
  • uses an email service like MailChimp for email newsletter purposes;
  • collects personal information and therefore may need a privacy policy;
  • expresses views on the law or some other topic of expertise and so should, ideally, have an appropriate disclaimer;
  • generates cookies and so may, depending on where you’re based (e.g., Europe), need to have a separate section on cookies;
  • resyndicates, in say a sidebar, headlines or more from another site’s web feed; and
  • allows others to re-use the posted content under a specified Creative Commons copyright licence.

(I don’t get into hosting issues in this post. Personally I use WPEngine for my newer sites and am happy with the uptime, speed and service I receive.)

Checklist

Here’s a quick-fire checklist. Afterwards I discuss each topic in more detail for those who’d like to go deeper:

Checklist of legal and related checks for those building content-driven WordPress sites

Textual post content

  • Do you own the copyright in the content of your proposed posts or are you otherwise permitted to reproduce it?
  • If you’re posting an article that has been published elsewhere (e.g., in a commercial publication), do you have the right to publish it on your blog?

Third party images

  • Are you entitled to use, in your posts, the images that you propose to use?
  • If you’re licensed to use them (e.g., under a Creative Commons licence), are you complying with the licence’s attribution requirements?

Comments or other user-generated content

  • Will you let others add comments or other content to your site?
  • If so, do you need to obtain a licence to re-use content posted to your site by others for purposes other than reproduction on the site itself?
  • Do you propose to moderate users’ comments/content and, if so, when? Have you considered the administrative burden that moderation can entail if you receive voluminous comment?
  • Do you need or wish to protect yourself from liability arising from material posted to your site by others that infringes third party rights?
  • If you’re seeking rights and obligations from your users, have you put a mechanism in place (e.g., a browsewrap or clickwrap mechanism) that secures their agreement?

Email services like MailChimp

  • If you’re using a service like MailChimp, does the service or the way you’ve configure it comply with the anti-spam laws (if any) that you need to comply with? (Solid services like MailChimp are great on this front.)
  • If you’re using such a service and are in Europe (for example), is personal information transferred outside the European Economic Area and, if so, is that lawful under your data protection laws?

Privacy policies

  • If your site collects or enables the provision of personal information, should you or must you have a privacy policy?

Disclaimer and exclusions of liability

  • Is it desirable to add a disclaimer and liability exclusion to your site?

Cookies

  • Does your site, or third party services you use in conjunction with it, generate cookies?
  • If so, does your country have cookie laws (such as those in Europe) that require disclosure of the use of cookies and some form of user consent to their use?
  • If so, have you complied with those laws?

Republishing another site’s web feed content

  • If you propose to republish content from another site’s web feed on your own website, have you checked whether there are governing terms of use?
  • If the site in question does not expressly grant permission to republish, have you sought permission from the site owner?

Creative Commons licensing of your content for re-use

  • Do you wish to license your post content for re-use by others?
  • If so, which of the six Creative Commons licences best serves your purposes and is there any third party content in your posts that needs to be excluded from the scope of the licence you grant?

Discussion

In the remainder of this post, I discuss the above topics in more detail. Before doing so, I should perhaps note that not every WordPress site owner will think about or be concerned about such issues (someone writing a blog about cats, for example, is unlikely to run into too much trouble). I suggest, however, that the more commercial your site is or the more important it is to you, the more important it is to take these issues into account.

Textual post content

Is the textual content of posts your own original content? Usually the answer will be yes, in which case you’ll own the copyright in it and no issue arises. But if you’re using all or a substantial part of someone else’s textual content for a post, you’ll need to make sure you have their permission to reproduce it (otherwise you could well infringe their copyright and make them unhappy).

OldTypewriterCropped
There’s also another scenario that can catch people out sometimes. That’s where you’ve written a story for another site and the terms you’ve agreed to in submitting the story include an assignment (transfer) of copyright in the story to the other site owner. If you’ve assigned copyright in your story to someone else, you can’t reproduce it on your own site unless permitted to do so by the other person, as you’ve handed over the reproduction right to them. Sometimes the terms of the arrangement will grant you a licence back but in many instances they won’t. This can be the case where you’ve written a story for a commercial publication. If you have assigned/transferred copyright, you’ll need to check whether you were granted a licence back that allows you to reproduce the story on your own site or seek permission from the other site owner. And if you’re about to post an article to another site, you might want to check if there any terms that would prevent you from publishing it on your own site. If there are, you might want to try to negotiate an alternative position with the site owner.

Third party images

It’s fairly commonplace for people to do a Google image search for an image they’d like to use in their post, save that image to their computer and then use that image in their post. Legally this is a no-no because, unless the owner of the image has licensed it for re-use (as people sometimes do, for example, on Flickr) or the image is in the public domain (being on the Internet doesn’t mean it’s in the public domain), your reproduction of it will almost certainly be an infringement of someone else’s copyright. If the owner finds out, you could find yourself on the receiving end of a stroppy email or phone call or a cease and desist letter from a lawyer. It’s much better, I suggest, to use images that are Creative Commons licensed (e.g., on Flickr; and make sure the licence in question gives you the rights you need in your circumstances and that you comply with the attribution requirements) or for which you’ve purchased a licence (from the likes of iStock, Bigstock, Shutterstock, etc) or which are in the public domain after having CC Zero applied to them (as is the case with Unsplash).

This is an example of an image from Unsplash to which CC Zero has been applied. It's now in the public domain. (It's true, I love old VWs, particularly Beetles.)

This is an example of an image from Unsplash to which CC Zero has been applied. It’s now in the public domain. (It’s true, I love old VWs, particularly Beetles.)

Comments or other user-generated content

Whether to allow comments on a site isn’t a legal issue (of course) but a decision to allow comments or other user-generated content does give rise to legal considerations.

Commentsimage

If you allow others to post content to your site, three broad issues arise:

  • whether you need to obtain a licence to re-use content posted to your site by others for purposes other than reproduction on the site itself (e.g., you might want to publish helpful comments in an ebook);
  • whether to moderate content and, if so, when; and
  • how to protect yourself from liability arising from material posted to your site that infringes third party rights.

Licence to re-use others’ content

As to the first issue, if you wish to use comment or other content posted by others for purposes other than reproduction on your site, it’s advisable to obtain a licence from them prior to their submitting the content. Otherwise they could complain later on that they never allowed you to use their content for any purpose other than the site to which they posted the content. Sometimes the risk here will be small, but better to be safe than sorry I reckon. I set out some sample provisions further below.

Moderation

Turning now to the question of moderation, you’ll want to consider whether to review and approve the content before it goes live or to let it go live without review (with or without post-publication review on your part). In either case, there is always the potential for content that infringes another person’s copyright or is defamatory of another person to be posted to your site without you recognising it. (Note that in some countries there are statutory defences to copyright infringement and defamation where another person posts copyright infringing or defamatory content to your site without your active involvement and knowledge; the defences usually apply until you know the content is infringing or defamatory, upon which you must take it down or expose yourself to the risk of legal action). Spam can also slip through, even when you use a plugin like Akismet. Personally I don’t let comments go live without reviewing them first. There’s too much spam and other crud floating around the Internet that might otherwise make it on to your site. That’s just me, of course. You may be less concerned about that sort of thing.

Legal protections

Regardless of whether and when you’ll moderate content posted by others, you may wish to include terms of use on your site, that contain legal protections for you, to which people must agree when posting content. I set some of them out shortly.

Sample clauses

The kinds of clauses that provide you with a licence for subsequent use of user-submitted content and that protect you to some extent from the consequences of infringing, defamatory or other offensive material being posted to your site are as follows (note that these sample clauses cannot insulate you from an action by the true copyright owner or a person defamed; rather, they seek to give you a right of action against the person that posted the offending content in the event that you were to be sued by the copyright owner or person defamed):

Copyright

My copyright: Unless indicated otherwise in specific posts or pages, I or my licensors own the copyright in material on WP and Legal Stuff. You may download, print and store the textual content of my posts and pages for personal or internal organisational purposes. Except where I grant you broader rights in relation to specific content, either on the site or when you ask, all other rights are reserved.

Your copyright: You retain any copyright in contributions you post to the site or send me by email, such as lengthy comments on posts and articles (by the way, these contributions will be considered non-confidential). You grant me a non-exclusive, royalty-free, transferable and irrevocable licence to copy, adapt and print your contributions and to publish them in any media and in any format, including on this website and any related website, and in any podcast, web feed, book, ebook or email newsletter.

Other people’s copyright: If your contributions to the site include all or a substantial part of another person’s copyright work (or any other third party intellectual property), you promise that you have the right to submit it to the site for publication and to grant me the licence mentioned in the previous paragraph.

Unacceptable use

You agree that you will not post or transmit to or from the site any material that is illegal, obscene, defamatory, threatening, infringing of intellectual property rights, confidential, invasive of privacy or otherwise injurious or objectionable. If you do, you agree that you’ll indemnify me against all losses, damages and costs (including legal costs) I may suffer as a result of your breaching this term.

Agreement mechanism

It’s important to include a mechanism on your site by which people will be taken to have agreed to such terms. Putting the terms in a footer.php file that displays small text at the bottom of each page is unlikely to suffice. It’s far better and safer to use either an appropriate “browsewrap” or “clickwrap” mechanism.

A browsewrap mechanism can consist of a link to the terms of use with an accompanying statement, in close proximity to the comment or post ‘submit’ button, along the lines of:

In submitting comments to this site, you will be taken to have agreed to the terms of use [“terms of use” is linked to the actual terms of use, which will open in a separate window/tab or pop-up when clicked]

The standard clickwrap mechanism is a check box that must be clicked before a comment (for example) can be submitted. Some consider this approach to be the ‘gold standard’, if you will.

Including a browsewrap mechanism for those who submit comments can be achieved in various ways. One way is to add some code to the relevant file in your theme, along the lines referred to above, to produce something like this:

Sample agreement text above submit button

If you’re allowing people to add posts to your site using a forms plugin like Gravity Forms, again, inclusion of a browsewrap mechanism is fairly simple. You can just add an appropriate field before the submit button, like this:

Agreement text in a Gravity Forms field

If you’d prefer a clickwrap mechanism for those who submit comments, various plugins exist to make this possible: I Agree, Agreeable and no doubt others. (I’ve not tested these because, in the past, I’ve usually used a browsewrap method for comments forms). If you’re allowing people to add posts to your site using a forms plugin like Gravity Forms, again, inclusion of a clickwrap mechanism is fairly simple. You can, for example:

  • include a checkbox and some appropriate text before the submit button, and set up conditional logic for the submit button so it’s only clickable when a ‘click to agree’ checkbox has been selected (you’ll find the conditional logic option for the submit button in the “Form Settings” for the form); or
  • purchase and install the Gravity Perks plugin which includes a GP Terms of Service Perk (it helpfully adds a “Terms of Service field to the available Advanced Fields”).

This is what the Gravity Perks Terms of Service Perk can produce:

GP Terms of Service Perk

(I really like the look of the Gravity Perks solution. Must grab myself a copy of that one day. The developer behind it has done some work for me in the past. Top notch.)

Email services like MailChimp

If you use a service like MailChimp, you’ll probably want to ensure it complies with your local anti-spam laws (if you have them) and that transmitting personal information to MailChimp and having MailChimp store it on its servers is consistent with your local law (this latter issue can arise in Europe given its fairly strong Data Protection Directive that is implemented in the local laws of Member States). In some countries, like mine, the focus of the anti-spam is on unsolicited commercial electronic messages. Sometimes your messages won’t be commercial but they could be if you’re promoting goods or services.

MailChimp is the service I use. I’m comfortable it complies with the anti-spam laws that apply to me and, given its focus on legal compliance, I suspect it complies or can be configured to comply with the spam laws of most countries.

If you’re in Europe (and to cut a long story short), personal data can be transferred to a US-based service (like MailChimp) if those to whom the personal data relates consent to the transfer or if the US entity receiving the data has signed up to and complies with the US-EU Safe Harbor Framework. MailChimp, for example, complies with the Framework (see clause 12 (Safe Harbor Certification) of its Privacy Policy), so there’s no problem there. In a privacy policy I drafted for the UK blog I mentioned earlier, I included this clause for completeness:

Who holds the information

We will hold the information. You can contact us via [email address].

This website is hosted by WP Engine and we use MailChimp to manage our mailing list so these services will also hold certain information on our behalf. They are based outside the European Economic Area (EEA) but comply with the US-EU Safe Harbor Framework. In supplying any personal information to us, you consent (1) to our transferring the information to these services (and therefore outside the EEA), (2) to our use of these services to store and process your information and (3) to the collecting, processing and storing of that information in accordance with the privacy policies of WP Engine and MailChimp respectively, to the extent relevant. The privacy policy of WP Engine is available at https://wpengine.com/privacy/ and the privacy policy of MailChimp is available at https://mailchimp.com/legal/privacy/.

Collection of personal information

If you collect personal information from people who use your site (e.g., their names, email addresses, physical addresses, attributes, etc) it may be either good practice (in some countries) or a legal requirement (in others) to have a privacy policy, the purpose of which is to explain to people what information you collect, how you will use it, whether you’ll transfer it to others and so forth. This enables people to make informed choices and to understand how you will handle their personal information. The privacy policy on this site illustrates what (I hope) a user-friendly privacy policy can look like and, if you like, you can auto-generate your own one based on mine through the form in the post Would you like a privacy policy like mine?

Disclaimer and exclusions of liability

If you’re writing posts on which people could rely, you may wish to include a disclaimer and exclusion of liability. In many countries, particularly common law countries like the United Kingdom, Australia and New Zealand, the primary purpose of a disclaimer is to defeat an argument by a would-be litigant, who has suffered loss through relying on what you’ve said, that it was reasonable for that person to rely on what you’ve said on your site. Defeating that argument will usually mean that the disgruntled reader will be unable to establish the tort of negligence. Essentially, readers act on what you’ve said on your site at their own risk.

This is the term I’ve used on this site:

No legal advice, disclaimer and exclusion of liability

The material on this site is for general informational purposes only. It does not take into account your specific requirements or circumstances, does not constitute legal or other advice to you or anyone else and you rely on it at your own risk. I’ll try to write helpful content but I disclaim and exclude all liability for any claim, loss, demand or damages of any kind (including for negligence) arising out of your use of the site or any information on it or any other website to which it links. You agree that I will not be liable to you for any such claim, loss, demand or damages.

Some will say this is overkill but, let’s face it, there are some litigious folk out there in some countries. Because I’m discussing legal matters on this site, I’d rather be safe than sorry.

Cookies

Cookies are small text files that are stored on your computer or mobile device when you visit or undertake certain activity on some websites (for further information about cookies,  see https://www.allaboutcookies.org.)

Many countries don’t have laws that require disclosure of cookies. The laws that apply to me don’t but I disclose the existence, nature and names of cookies as best I can anyway (within privacy policies), as I consider it good practice to do so.
London-image

By contrast, in Europe, for example, there are specific (and controversial) cookie laws. Following an amendment to the European E-Privacy Directive in 2009 and its subsequent implementation into local law by Member States, website owners in European Member States are required to:

  • provide clear and comprehensive information about any cookies they are using; and
  • obtain consent to store a cookie on a user or subscriber’s device.

There are some narrow exceptions, namely, where the use of a cookie is:

  • for the sole purpose of carrying out the transmission of a communication over an electronic communications network; or
  • where such storage or access is strictly necessary for the provision of an information society service requested by the subscriber or user.

The United Kingdom’s Information Commissioner has produced excellent guidance for UK website operators. That guidance explains the rationale for the cookie rules as follows:

“The rules in this area are essentially designed to protect the privacy of internet users – even where the information being collected about them is not directly personally identifiable. The changes to the Directive in 2009 were prompted in part by concerns about online tracking of individuals and the use of spyware. These are not rules designed to restrict the use of particular technologies as such, they are intended to prevent information being stored on people’s computers, and used to recognise them via the device they are using, without their knowledge and agreement.

WordPress site operators will often used third party services on their site that set their own cookies. In relation to these sorts of cookies, the UK’s Information Commissioner says this:

“… we would advise anyone whose website allows or uses third party cookies to make sure that they are doing everything they can to get the right information to users and that they are allowing users to make informed choices about what is stored on their device.”

The Information Commissioner recognises (rightly in my view) that this is “one of the most challenging areas in which to achieve compliance with the rules”.

How a website operator in a European Member State complies with the rules will depend on the nature of the site and the cookies used, together with any specific requirements of their local laws and regulators. You do, of course, need to know what cookies your site sets, either itself or through the use of third party services, to be able to comply. A particularly thorny issue is whether prior consent is required, i.e., whether a user needs to give active consent before a cookie is set, or whether some proximate form of implied consent will suffice, e.g., by using a pop-up that says something like:

“This site uses cookies to [improve your user experience]. By using this site you agree to these cookies being set. To find out more see our cookies policy”.

This is of huge practical significance for many site operators. In its guidance, the UK’s Information Commissioner suggests that implied consent may suffice in some cases and, significantly, in recent times the Information Commissioner has taken precisely that approach for its own website (see Changes to cookies on our website).

Cookie controlAs you can see from this screenshot, the Information Commissioner’s website informs users that the site has (already) set cookies and then gives them the option of saying they’re fine with this or to use a tool to change the settings. This is good news for those in the UK as it’d probably be mighty difficult for the average website operator to use certain third party tools, like Google Analytics, if it had to obtain informed consent before the cookies were set. It’s also useful to look at the approaches taken by European law firms. Take a look, for example, at the websites of TaylorWessing, Ashurst and Olswang.

There are many WordPress plugins that seek to enable those in European Member States to comply with the European cookie laws. In the past I’ve used Creare’s WP Cookie Banner plugin which can be configured to do a pretty good job, along the lines of the approaches linked to above.

Resyndicating content from another site’s web feed

Some people like to resyndicate/republish, on their own blogs, content from the feeds of other sites and channels. They may do so by publishing (e.g., in a sidebar) the post headlines with links to the source site or they may publish excerpts from the posts or the entire post content (with or without links back to the source). There are numerous WordPress plugins and widgets that enable you to do this. Some, like FeedWordPress, allow you to parse the feed and create posts on your own site from the content. Others just check a feed’s content when your site is loaded and display a list of headlines, without writing to your database. The real question, though, is whether this is a good idea? Well, it depends (don’t you hate it when lawyers say that).

Taking and republishing others’ feed content without their permission (i.e., without a licence) is not a good idea, as more often than not the feeds will comprise copyright content. If such permission is not obvious from terms on their site or from the feeds themselves and there is any risk of adverse action upon re-use, the safest bet is to request permission and, if granted, obtain written confirmation. Failing to do so could prompt the content owners to complain of copyright infringement.

Equally, even where a general consent to resyndicating feeds is apparent from an organisation’s site, you may need to take care that you comply with any terms accompanying that consent. To give you an example, the New Zealand Herald news site expressly “encourage[s] the use of NZ Herald RSS feeds as part of a website or weblog”.  At the same time, its RSS licence terms require, among other things, that NZ Herald’s headlines are displayed in the exact form received, are not modified without their consent and that the resyndicating website stipulate that the headlines are supplied by nzherald.co.nz.

Allowing others to re-use your posted content under a Creative Commons licence

Sometimes it may be in your interests to allow other people to republish your post content, with attribution back to you and your site as the source, so as to further promote your knowledge and brand. The Creative Commons licences provide the perfect means to do this.

Creative-Commons

Thanks to Kristina Alexanderson for sharing this photo under a Creative Commons Attribution 2.0 Generic licence.

For those not familiar with Creative Commons, here’s a short intro: Creative Commons is a non-profit organisation founded in the United States in 2001 by proponents of reduced legal restrictions on the sharing and use of copyright works. Headquartered in California, it also has affiliate organisations around the world. It aims to establish a middle way between full copyright control and the uncontrolled uses of intellectual property. To do so, it provides a range of copyright licences, freely available to the public, which allow those creating intellectual property to mark their work with the freedoms they want it to carry. As Creative Commons puts it on its website:

“Our tools give everyone … a simple, standardized way to keep their copyright while allowing certain uses of their work — a “some rights reserved” approach to copyright — which makes their creative, educational, and scientific content instantly more compatible with the full potential of the internet. The combination of our tools and our users is a vast and growing digital commons, a pool of content that can be copied, distributed, edited, remixed, and built upon, all within the boundaries of copyright law.”

There are six Creative Commons licences. The licences all confer a set of baseline rights on licensees (e.g., as to copying, use and distribution) and a set of baseline obligations and restrictions (e.g., licensees cannot sublicense the licensed work and they must not falsely attribute the work to someone else). All of the licences also contain one or more “licence elements”. There are four Creative Commons licence elements: Attribution, NonCommercial, NoDerivatives and ShareAlike. The Attribution element is common to all of the licences. The other three elements are used in different combinations across five out of the six licences. Here’s a handy video produced by the New Zealand Creative Commons affiliate (Creative Commons Aotearoa New Zealand) that explains the licences in more detail:

https://vimeo.com/ccanz/cckiwi

Before you license your content for re-use, you’ll want to consider whether doing so could conflict with your commercial or other interests and if one form of Creative Commons licence is preferable to another. For example, if you’re going to monetise your content, you may wish to choose the Creative Commons Attribution NonCommercial 4.0 International licence, which lets others remix, tweak and build upon your work non-commercially with credit to you (their new works must also be non-commercial). I’ve taken this approach before on lawyer websites. For example:

Copyright

Unless otherwise indicated, copyright in material on the Site is owned by us or our licensors.

Your re-use of copyright material on this Site

Unless otherwise indicated, copyright material on this Site is licensed under the Creative Commons Attribution-Noncommercial 4.0 International licence. In essence, you are free to copy, distribute and adapt such material for non-commercial purposes, as long as you attribute the material to us and abide by the other licence terms. To view a copy of this licence, visit https://creativecommons.org/licenses/by/4.0/. Please note that this licence does not extend to resyndication of the Site’s web feed(s) on third party websites. Such resyndication without express permission is prohibited.

Exclusions from licence

The licence above does not apply to the [name of business] logo or to photos and design elements on the Site, which may not be reproduced without our express written consent.

If you decide to go ahead and license some or all of your post content, you’ll want to make sure that you only license content or portions of content whose copyright you own or are authorised to sub-license under the chosen Creative Commons licence. For example, if you use third party stock images in your posts (from Shutterstock or the like) you’ll need to exclude them from the scope of the licence you grant as you won’t be permitted to sub-license the re-use of those images by others under a Creative Commons licence.

You can learn more about Creative Commons and its licences, and how to apply them, at the Creative Commons website. Feel free to ask about this topic if you like, as I do quite a bit of work in this area.

Summing up

So there you have it: a range of legal issues that you may wish to consider when setting up a content-driven website. Many WordPress site owners, like other site owners, don’t consider these kinds of issues. For example, those with personal blogs often won’t be aware of all the issues or want to bother with them. As I’ve suggested above, though, the more commercial your site is or the more important it is to you, the more important it is to take these issues into account. Good luck!

How to build a contract generator with WordPress and Gravity Forms

Background and introduction

I purchased a Gravity Forms developers licence back in October 2009. It was one of the best WordPress-related purchases I’ve ever made, as the forms plugin has gone from strength to strength over the years and is now so polished, with so many useful add-ons, that it can truly convert WordPress into an app machine of sorts.

In the intervening five years, I’ve put Gravity Forms to all manner of uses, including making a number of contract and licence generation tools with it. Among other things, I’ve used it to build:

  • a website terms of use, mutual confidentiality agreement and privacy policy generator (see ubuildcontracts.com);
  • a Creative Commons licence chooser that built upon the code output of the Creative Commons licence chooser by adding government-specific elements to the code to reflect guidance in the New Zealand Government Open and Accessing Licensing framework (known as NZGOAL) (I’ve since taken this licence generator down); and
  • a generator that enables one to build a fully populated instance of a Government Model Contract for Services, with additional clauses where required (this is fully functional but not publicly available).

I’ve also used it to enable blogging readers of this site to build their one privacy policies based on the one I drafted for this site.

Over the years I’ve noticed significant interest in the Gravity Forms forums on developments that would enable this sort of thing to be done. I thought it timely, therefore, and in keeping with the theme of this blog, to explain how I’ve used Gravity Forms to build these generators.

I’ve actually used six different techniques, which you could summarise as:

  • Bespoke PHP: using bespoke PHP in an underlying template file that is used to populate gaps in that underlying template (the PHP would grab field inputs from a form submission, including conditionally, and then insert the complete populated text into a post or page; the Gravity Forms guys were incredibly helpful in providing me with sample PHP statements); this is the approach I used for ubuildcontracts.com.
  • Custom add-on: using a custom Gravity Forms post templates add-on that I paid to have developed that would do the same thing but through a new backend interface that meant I didn’t need to get my novice hands dirty with php (I didn’t distribute it and I couldn’t release it as I didn’t own the new code; it’s pretty old now and I’m sure wouldn’t work with the latest Gravity Forms release).
  • Second custom add-on: using a separate Gravity Forms post templates add-on that I paid to have developed that worked in a similar way but, instead of outputting a post or page, it would call up a Word document template, populate that template by reference to inputs in a form submission and then make the completed document available by a secret download link (this add-on allowed for conditional shortcode-type outputs and worked pretty well but was a bit buggy; unfortunately, Gravity Forms moved on by several iterations and I got too busy to ask the developer to update it).
  • Post body content template: one can use the post body content template feature that is now built into Gravity Forms to produce a post (or page) into which default content is inserted together with inputs that come from field inputs in a form submission.
  • Form submission confirmation: recently I realised that the Gravity Forms crew had made it possible to use field shortcodes in a custom form submission confirmation page. I’ve used this approach for the simple privacy policy generator on this site.
  • Gravity Forms + Zapier + WebMerge: this is the most powerful and robust combination I’ve used to date and is what powers the Government Model Contract for Services builder mentioned above.

In the remainder of this post, I’m going to provide step-by-step instructions for the fourth, fifth and sixth approaches. (The first approach can be put to one side, as it’s too labour intensive to be scalable. The second and third approaches can likewise be put to one side, as they are not publicly available and, in any event, are most likely to be past their “use by” dates.) This post assumes that you have purchased, installed and activated the Gravity Forms plugin and have some familiarity with it.

Post body content template method

Introduction

A Gravity Forms form can be set up to produce a post from each form submission. The post can be set to “Draft” or “Published” and, most importantly for present purposes, the content of the post can consist of default content together with the content of user-submitted inputs in a form submission to either fill gaps in the default content or supplement that default content.

I’m going to explain all this with a sample form that takes user inputs to produce a simple privacy policy. Before doing that, though, it might help to explain a few potential use cases for this approach and to explain a constraint of this approach.

In terms of use cases, you might want to use this approach in these kinds of scenarios:

  • You’re a lawyer, web designer or other service provider that has a standard document (e.g., a standard confidentiality agreement or a standard services contract) the completion of which requires specific user inputs. Those inputs might be provided by you on a per-client or per-matter basis (you’re the one that fills in the form on your website, which could be publicly accessible or on a secured/private page; alternatively, your whole site might be private as you might use it for this specific purpose and other private purposes) or the client him or herself might enter the data into a form on your website. You’re the one that will take the content generated upon form submission but, because you don’t want the generated posts to be public, you set the post creation option to “Draft” so that only you, as site administrator, can see the post.
  • Alternatively, you want to enable people on your website to complete a form and see a contract or similar document created before their very eyes, as a post (or a page). You don’t want the world to be able to see these posts, though, so people who complete the form need to be registered users and the posts they create need to be private, accessible only by them when they are logged in. You might also want to charge users to create these documents and/or to enable your users to amend the contracts or other documents that are generated for them. This scenario is more involved than the first in that, depending on your requirements, you may need to use one or more of a membership or content permission plugin, a roles capability plugin, the Gravity Forms User Registration Add-On, the Gravity Forms PayPal Add-On (or another payment mechanism), a login redirect plugin and/or additional plugins or custom code to achieve the desired result. I won’t go into these additional requirements in this post; suffice to say, though, that it certainly is doable.

Walk-through

The following walk-through will focus on the first scenario. I’ve used a simple privacy policy for this example.

Step 1 – Create form: Create a form with the fields that will collect the information you need to complete your contract or similar document. Ensure that one of your fields is a “Post Body” field (this field is necessary to build a content template).

Gravity Forms form

In my test form, I’ve set the Post Body field to “Admin Only” visibility. This means users completing the form can’t actually see this field; only the administrator sees it in the Gravity Forms administrator area. You can access this option in the “Advanced” tab of the Post Body field. After you’ve added the fields, make sure you click the “Update Form” button.

Step 2 – Content template: Create your content template. To do this, click on your Post Body field and then click the “Create content template” option. That will cause a “Insert Merge Tag” drop-down menu and a text box to appear. To create your template, paste your contract or similar document into the text field. Then, in the places where you have gaps that need to be filled, select the relevant field from the “Insert Merge Tag” drop-down menu.

Ember 2

Step 3 – Visibility of output: Decide what you’d like your user to see once she has completed the form. Gravity Forms provides different options which you can access from the “Form Settings” > “Confirmations” for your form.

Default confirmation

If you’re asking people to fill out the form to provide you with the data you need to complete a contract or similar document, but without showing them the draft contract or document just yet, you may wish to show them a simple form submission confirmation page. In this scenario you can use a default confirmation with a message of your choice, such as: “Thank you for providing your information. We’ll compile your contract and send a draft to you shortly for review and execution.”

In addition, to avoid the posts created through the form submission from becoming public, you’ll need to make sure either that:

  • your site is password-protected; or
  • it has membership or access controls that lock down the created posts; or
  • the “Post Status” for the body field is set to “Draft”.

Redirect confirmation

By contrast, if you’d like a person who fills out the form to be taken to the completed contract or other document, then you can select the “Redirect” Confirmation Type. When you choose this option, you need to add your base URL (e.g., https://yoursiteurl.com/) in the “Redirect URL” field. You also need to select the “Pass Field Data Via Query String” option. In the text area you’ll see appear, type in: p={post_id}

Ember 3

The next step here is to set the Post Status in the Post Body field to “Published”.

(Now, when a person fills out the form, she will be taken to the completed document. Bear in mind here, though, that unless you’ve added some access controls to your site, anyone will be able to see the created post. If you don’t want that (and in many use cases you wouldn’t), you’ll need to add access controls to the created post, including (I suspect) a control that only the author of the post can see it.)

Step 4 – Add form to a page of your site: Insert your form into a page on your site (whether you want to make that page public or password protect it is up to you) and look forward to receiving submissions from the form!

Pros and cons

Here are the pros and cons of this approach:

Pros

  • The approach is comparatively quick and easy to set up.
  • It creates a semi-permanent record in the form of the created post.

Cons

  • Conditional shortcodes that can be used in other areas of Gravity Forms cannot be used in the content template.
  • You need to deal with access controls if you want only the user to be able to see the created document.

Form submission confirmation method

Introduction

The form submission confirmation method is similar to the previous method but it does not rely on post creation and it is possible to use conditional shortcodes (for an explanation of how the conditional shortcodes work, see this Gravity Forms page).

Walk-through

The main steps are these:

Step 1 – Create form: Create a form with the fields that will collect the information you need to complete your contract or similar document.

Step 2 – Create confirmation text: In the Form Settings > Confirmations area of Gravity Forms, either edit the default confirmation or create a new confirmation which has a “Confirmation Type” of “Text”. In the text box, add your default text together with the merge fields which will insert the field inputs into your default text upon form submission.  You can select the merge fields from a small drop down menu to the right of the text box:

Confirmation text

Step 3 – Add form to a page of your site: Insert your form into a page on your site (again, whether you want to make that page public or password protected is up to you).

Now, when a user completes the form, he or she will be taken to a confirmation page that displays the completed document. The user can then copy and paste the text and use it for his or her own purposes. Here’s an example of what it looks like on my site:

Document created through form submission confirmation

Pros and cons

Here are the pros and cons of this approach:

Pros

  • Comparatively quick and easy to set up.
  • Shows the completed document only to the person who submits the form. The merged output is not a permanent record (which to some might be a pro).
  • You can use conditional shortcodes in the text that you enter for your confirmation.

Cons

  • Does not create a permanent record of the merged document. (An administrator will still be able to find the field inputs in the Gravity Forms database, unless the form has been tweaked so as not to save – or delete – form entries, something that can be done with Gravity Wiz’s Gravity Perks.)

Gravity Forms + Zapier + WebMerge

Introduction

As I mentioned above, this method is the most powerful of the methods. At the same time, it is also the most involved to set up and you need to have a Zapier account and a WebMerge account. You also need to have the Gravity Forms Zapier Add-On.

For those not familiar with Zapier, it’s an excellent service that enables you to “connect the apps you use to easily move data between them”. For those not familiar with WebMerge, it’s an “online platform that allows you to easily collect data, populate a document and send it to any contact automatically”. It allows you to merge data with fillable PDFs, HTML documents created with WebMerge’s online editor, or Microsoft Word documents. Great stuff.

Walk-through

Here’s the basic process. It assumes you have a Zapier account and a WebMerge account and have installed the Gravity Forms Zapier Add-On. I’m using the scenario where you’re using form inputs to populate a Word template (rather than, say, a fillable PDF).

Step 1 – Create form: Create a form with Gravity Forms that will collect the information you need to complete your contract or similar document.

Step 2 – Create template: Create a Word document template that contains your default text together with the merge fields that will be replaced by a person’s entries in the form. Note that you can also use conditional merge fields. For information on how WebMerge approaches merge fields and what it requires, take a look at these pages on the WebMerge support site:

Before I move to Step 3, I should note that, when I created my first complex contract template, with multiple merge fields (including conditionals), it took me a while to figure out all the relevant statements to use in my template. I’ve documented what I think are the main ones below. (If I’ve missed anything, I suggest you approach WebMerge support. They’re super helpful.)

Sample statements to use in your Word template document

Populate document with content of a field:

{$Address}

Populate document with content of a field if the submitted content equals a certain value:

{if $Name == ‘John’}
{$Name} is a wonderful name.
{/if}

Populate document with some predefined text, and the content of a field, if there is any entry in the submitted field (i.e., it is not empty):

{if !empty($Context)}
Context and other text
{$Context}
{/if}

Radio buttons – yes or no options:

{if $AnyChangesToSchedule2 == ‘No’}None.{elseif $AnyChangesToSchedule2 ==’Yes’}Schedule 2 of this Contract is amended as set out below:{/if}

Checkboxes – For each checkbox item:

{if strpos($checkbox, ‘the value selected’) !== false}Content here{/if}

One other question you may have is how to remove extra whitespace around your if statements. To achieve this, you need to make sure there are no spaces around your if statements.  Here’s an example that uses a single if statement and additional content with merge field afterwards. Note how the “Description of Services” text starts immediately after the closing if tag:

{if !empty($Context)}Context

{$Context}

{/if}Description of Services

{$DescriptionServices}

Step 3 – Create a Zap: Set up a new “Zap” in Zapier. As explained on the WebMerge support site, login to your Zapier account and click Create New Zap. From there, choose GravityForms as the trigger and have that fire a WebMerge action (i.e., a new document merge):

Zapier

The Gravity Forms crew have produced a helpful guide that details the steps required at the Gravity Forms end (i.e., within your website) as part of this process. It walks you through the zap creation process from the Gravity Forms perspective. The key point is that you need to add a webhook, that Zapier will give you, to the Gravity Forms ‘Zapier’ Form Settings for the form you’ll be using. See the Gravity Forms guide referred to above for the detail. The screenshot below is of a Gravity Forms admin page (Form Settings > Zapier) that shows where this is done:

Zapier's webhook for Gravity Forms

At the Zapier end, once you select from your WebMerge account the document  that you wish to use, Zapier will load the fields in your document so you can map them to the Gravity Forms form fields (this is much easier than it may sound).

Ember

Once you’ve done this, you can test your new Zap and then name it and turn it on.

Ember

Now you’ll be ready to start producing merged documents. Fill out and submit the Gravity Forms form and WebMerge will create a merged document (contract, policy or whatever it is) for you.

There are additional settings that you can configure within your WebMerge account. They’re fairly self-explanatory so I won’t go into the detail here.

Pros and cons

Here are the pros and cons of this approach:

Pros

  • Enables you to use a fully formatted Microsoft Word template that, when merged, will retain its formatting.
  • WebMerge also enables you to create a merged PDF.
  • The ability to use conditional statements in your template is a major plus, particularly for documents of any complexity where you need to include or exclude content depending on a user’s form inputs

Cons

  • Comparatively more time-consuming to set up.
  • You need to have not only Gravity Forms but a Zapier account, a WebMerge account and the Gravity Forms Zapier Add-On, which will increase your costs.

Concluding comment

So that’s it. Three different ways to use Gravity Forms to build a contract (or other document) generator. They all have their pros and cons but, for documents of any complexity, the Gravity Forms + Zapier + WebMerge approach is the most powerful.

Let me know if you have any questions.

Would you like a privacy policy like mine?

When I was getting WP and Legal Stuff ready for release, I drafted the privacy policy that is linked to in the site footer. I did this because I would probably be collecting personal information (e.g., names of commenters and email addresses) and it was appropriate, therefore, that I let people know what I’m collecting, who can see it, what I’ll do with it, and so on.

When drafting the policy, it struck me that this is something that other bloggers and site operators – whose structural set up is similar to mine – may also need or wish to do. If you’re in this position, please feel free to create your own policy based on mine. To help you out, I’ve whipped up a form that takes a small number of inputs and then spits out a version of my privacy policy but with my details removed and your details inserted.

The form and output are based on a few assumptions:

  • that an individual is operating the blog / site;
  • the site is externally hosted;
  • you are operating an email subscription list that is managed by a third party service provider such as MailChimp;
  • you’re using WordPress for your site;
  • you accept comments; and
  • you use Google Analytics for site statistics.

If these assumptions aren’t correct in your case, you may need to adapt the output.

Of course, I can’t say whether the output will necessarily cover all bases for you, given your own circumstances and the laws that may apply in your country, but hopefully it’ll provide a helpful starting point.

To obtain your own starter privacy policy based on mine, fill out and submit the short form below. After you submit it, you’ll be presented with the privacy policy which you can copy and paste and use for your own purposes. (You may need to scroll down a bit to see it.)

  • E.g., WP Engine, Pagely, Bluehost, etc
  • E.g., MailChimp, Campaign Monitor, AWeber, ConvertKit, etc