Latest Posts

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

A brief history of WordPress

Many have written accounts of the birth and growth of WordPress. For example, there’s a punchy timeline in the WordPress codex, an interesting 10 year visual history on WPMU DEV and interesting posts on WPExplorer, WPBeginner and Kinsta WordPress Hosting. An even richer account is likely to be released soon, as certain WordPress aficionados are currently writing “a new book about the history of WordPress drawing on dozens of interviews with the original folks involved and extensive research”.

For the purposes of this blog, I don’t need to explore the history of WordPress in the same level of detail (and it’s best that I leave that to the historians and others). It does help, though, to set out a few key points about WordPress’s development as well as the nature and roles of Automattic Inc and the WordPress Foundation. They help one understand the origins of the WordPress software, the legal structure around WordPress and its licensing, the relationship between WordPress and WordPress.com and the relevance of the WordPress Foundation. In addition, the origin of the WordPress software is relevant to some of the spats I mentioned in My WordPress story, whilst the legal structure around WordPress and its licensing is relevant to a range of significant issues that have excited debate within the WordPress community (topics I’ll address in later posts).

From 2003 to 2014

As explained on WordPress.org, “WordPress was born out of a desire for an elegant, well-architectured personal publishing system built on PHP and MySQL and licensed under the GPLv2 (or later)”. Significantly, it was the official successor of b2/cafelog, so let’s start there.

b2/cafelog was launched in 2001 by Michel Valdrighi. It was described as a “classy news/weblog tool (aka logware)” that worked like this:

“You type something and hit ‘blog this’ and in the next second it’s on your page(s). You can write extended entries, or even entries that span multiple pages. You can also use BloggerAPI clients to post to your b2 weblog.

What’s original in b2? Pages are generated dynamically from the MySQL database, so no clumsy ‘rebuilding’ is involved. It also means faster search/display capabilities, and the ability to serve your news in different ‘templates’ without any hassle.”

Sounds familiar right?

In 2003 Matt Mullenweg and Mike Little forked b2 and created WordPress: the beginning of a beautiful thing that in time would come to power up to 23% of the world’s websites. Since 2003, we have seen (among many other things) introduction of the WordPress plugin architecture (2004), introduction of the theme system and static pages (2005), widgets, tagging and pretty URLs (2007), several new and improved user interfaces (2007-2014), custom post types and multisite (2010), post formats (2011), the theme customiser and previewer (2012), built-in audio and video support and improved security measures (2013) and live widget and header previews (2014). In a nutshell, WordPress just keeps getting better and better. And let’s not forget about the WordPress codex: it contains an incredible amount of useful support documentation across all manner of topics.

WordPress and the GPL

Like b2/cafelog, WordPress is (and had to be) licensed under the GPL (the well-known acronym for the “GNU General Public License”). Its codebase has been developed and contributed to by a wide range of developers around the world, meaning that no single person or company owns the WordPress software that is available on WordPress.org. It is perhaps as open source as open source can be.

I’ll have more to say about WordPress and the GPL in later posts.

Automattic Inc

In 2005, Matt Mullenweg and others founded Automattic Inc. According to a SiliconBeat article at the time, Matt wanted “to launch a company that could provide the necessary clout and support for the WordPress software and the newer WordPress.com [platform]” that provides free hosting for WordPress sites as well as a range of paid upgrades and business offerings. Today Matt describes Automattic as “the secret force behind WordPress.com, Akismet, Gravatar, VaultPress, IntenseDebate, Polldaddy, and more”.

As I’ll discuss in more detail in a later article, Automattic also registered a range of WordPress-related trademarks. As noted above, though, it doesn’t own the copyright in all the code that comprises WordPress as we know it today. The software is community owned, whilst Automattic is the commercial vehicle through which Matt and many others support and leverage WordPress, with its most well-known business being the WordPress.com platform. (I don’t propose, in this post, to go into the differences between WordPress.org and WordPress.com but, for those interested in the subject, I recommend WPMU Dev’s WordPress.org vs WordPress.com: A Definitive Guide For 2014.)

The WordPress Foundation

The other point to note in relation to legal structure is that, a number of years ago now, Matt founded the WordPress Foundation, “a charitable organization … to further the mission of the WordPress open source project: to democratize publishing through Open Source, GPL software”. The Foundation went public in January 2010. Its website describes its raison d’être as follows:

“The point of the foundation is to ensure free access, in perpetuity, to the software projects we support. People and businesses may come and go, so it is important to ensure that the source code for these projects will survive beyond the current contributor base, that we may create a stable platform for web publishing for generations to come. As part of this mission, the Foundation will be responsible for protecting the WordPress, WordCamp, and related trademarks. A 501(c)3 non-profit organization, the WordPress Foundation will also pursue a charter to educate the public about WordPress and related open source software.”

(I’ll say a bit more about the reference to trademarks in a later post.)

Wrapping it all up

So that’s it for my brief history of WordPress. In a nutshell, WordPress was a fork of b2/cafelog and, like b2/cafelog, is licensed under the GPL. It has evolved dramatically since its humble beginnings in 2003, so much so that it now powers up to an incredible 23% of the web. Matt and others founded and operate Automattic Inc to support the WordPress software, WordPress.com and other ventures and Matt founded the WordPress Foundation, a non-profit organisation, to further the WordPress mission and protect WordPress for future generations. As I said in my opening post, thank you.

(Thanks to Tom Marcello for his image of Dexter Gordon and Benny Bailey from 1977, licensed under a Creative Commons Attribution-ShareAlike 2.0 Generic licence.)

Why legal stuff matters

For some people, thinking about legal stuff may not be at the forefront of their minds when they’re developing, designing, launching or adding content to a WordPress website or developing and releasing a theme or plugin. I suspect it’s also not at the forefront of the minds of some people who launch commercial theme and plugin shops, release WordPress ebooks, produce WordPress podcasts, and so on. It’s easy to get caught in the moment and the excitement of developing, writing or releasing something new. I know what that’s like. Just as a lawyer building a website may pay little attention to something that a developer would consider crucial, so too can developers, designers, bloggers and entrepreneurs pay little attention to things that lawyers consider important if not crucial.  And, of course, in some cases people want to do what’s right or in their commercial interests but just don’t know what the relevant laws are or how they apply.

The legal stuff does matter

There are various reasons for sticking to the right side of the law and being mindful of legal issues that may help or hinder you depending on how you approach them. But what do I mean by “law”? Let’s break it down. When I refer to law here, I’m usually referring to one or more of the following areas of law:

  • Contract law: Depending on your situation, contract law and the content of your contractual arrangements can affect the rights and obligations you may have with WordPress developers, designers, web hosts, commercial theme and plugin providers, support shops like codeable and WerkPress, Automattic Inc (if you use WordPress.com, VaultPress or the like) and any other person or organisation with whom you may transact for the purchase or supply of a WordPress-related (or other) product or service.
  • Copyright law: In many if not most countries, copyright law is statutory in nature, meaning the rules that govern copyright are set out in one or more pieces of legislation. Copyright law is relevant to a range of WordPress-related activity, including the intellectual property provisions of contracts you may have with developers, designers or customers; terms of use that you may wish to add to a commercially oriented WordPress website; software (e.g., WordPress, theme and plugin) licensing permissions and obligations (including compliance with the GPL); and the content that you add to your website (including text, images, audio and video), whether it’s your own content or content you license or otherwise obtain from other sources.
  • Tort law: Without getting into the niceties, tort law is essentially the law of non-contractual civil wrongs. The content of tort law depends on each country’s laws. In many countries (most notably those with common law legal systems) torts are the creation of the courts; in some countries some torts have been partially or fully codified in legislation; and in other countries, such as certain countries in Europe with civil law legal systems, the equivalent of torts are set out in legislation. In general terms, if A commits a tort against B, B usually has a cause of action (right of complaint) against A for which it can seek remedies in court, such as damages or an injunction (an injunction is an order requiring the defendant to stop doing something). Examples of torts relevant to online activity are defamation, negligent misstatement, deceit and injurious falsehood, breach of privacy or confidentiality and intentional infliction of emotional harm. I should stress that, as with other areas of law I’m mentioning, these torts are not at all specific to WordPress itself or your use of WordPress in particular. In the present context, they generally relate to the nature of your site content. The same issues could arise with any publication through any medium. I mention them, though, because they are relevant to an assessment of site content and consideration of site content is relevant to the broad subject matter of this blog.
  • Privacy law: To the extent relevant here, privacy law relates to the content you obtain and publish where that content includes information about individuals, that is, personal information. It can also affect what you do, for example, with the information you may have on customers or clients. Privacy law, or data protection law as it’s commonly referred to in Europe, is increasingly important and is increasingly coming under the spotlight in the context of online activity. The key point, in very simple terms, is that you need to be careful how you handle and what you do with the personal information you may collect or that is otherwise provided to you. Depending on the laws that may apply to you given the countries in which you live or do business, this can apply to both individuals and organisations alike.
  • Anti-spam law: Anti-spam laws are becoming increasingly common around the world and are invariably statutory, that is, the rules are set out in legislation. They are another set of laws to bear in mind when ‘cold calling’ people via the likes of email or text messages (which some WordPress businesses might do), creating email lists and sending emails to list members (which WordPress plugins and third party services that integrate with WordPress make very easy these days) and using plugins that enable you to send text messages to people’s mobile phones.
  • Consumer protection and trade law: Aspects of consumer protection and trade law can be relevant to the way in which WordPress businesses conduct themselves and market and sell their products and services. In some counties it is important, for example, for businesses not to act in a misleading or deceptive manner, e.g., by making misleadings statements in trade on your website or as to the nature, features or functionality of a theme or plugin, for example, that you may be selling. In countries that have ‘fair trading’ style laws, such conduct could invite intervention by regulators or give affected consumers a statutory right of action against you. (Such conduct might also have contractual consequences, e.g., enabling an affected consumer to get out of a contract by which he or she would otherwise be bound.) And some countries have laws or regulatory guidelines which require you to disclose that an affiliate link is in fact an affiliate link.

Other areas of law may crop up from time to time as well. (When they do, I’ll try to mention them.)

Ultimately, keeping on the right side of the law and taking legal issues into account that may affect you or your business is desirable not only for peace of mind but to enable you to avoid legal problems, protect your assets and reputation, obtain the rights you may need, and safeguard your time and resources (having to clean up legal problems after the event can drain them). The last thing you need is having to spend precious time and hard-earned money getting out of a legal bind or obtaining rights that you might have already obtained if you’d taken relevant issues into account at the outset.

I’m not giving legal advice in this blog but I do hope to be able to help WordPress users and businesses keep on the right side of the law and take legal issues into account that may affect them or their businesses. And as I said in the previous post, let me know if you have any questions.

My WordPress story

How is it that a lawyer becomes wrapped up in WordPress? What makes a lawyer explore legal issues that can arise through application of the open source licence that governs its use? What makes a lawyer want to analyse a range of legal issues that can arise through personal and commercial publishing using the world’s most favoured CMS? The answer is simple: a maturing passion for WordPress. Yes I’m a lawyer (sounds like a confession doesn’t it) but I’m also a keen WordPress user and have been for a long time. I thought I’d tell my story to enable readers of WP and Legal Stuff to understand how this all came to pass.

Blogging and RSS fever

I have vivid memories of coming across blogging and RSS in 2004. I was working in Frankfurt, Germany, having transferred there from London, England (and I’d transferred there some time earlier from Wellington, New Zealand). For some reason, the freedom and immediacy of personal publishing and the distributive power of RSS captured my imagination, so much so that they wouldn’t let go.

I was a lawyer at the time (as I still am), which I guess makes my story a little unusual, at least back then. Back then, in 2004, few lawyers had heard about blogging and the mere mention of RSS would make most lawyers’ eyes glaze over. I was working in a large international law firm, where promoting one’s legal knowledge and expertise was an important element of the firm’s marketing strategy, but getting an article published involved a lawyer, a marketing department and the techies who managed the firm’s website. My colleagues were friendly and talented people but the number of heads involved in getting an article out the door was mind-boggling and meant inevitable delay and inefficiency.

I could see blogging and RSS being powerful tools for lawyers. I wanted to write about it but I was concerned that my firm might disapprove. Being a newish father with a young family, I didn’t really want to rock the boat. That may sound strange now but, back then, there were very few lawyers publishing their own content online on blogs separate from their employers’ main websites. There was a handful in the United States but very few in Europe and certainly none in the larger law firms.

Feedmelegal and Pharmablawg

So in September 2004 I decided to start blogging anonymously through a blog I called feedmelegal. I started off using Typepad. I wanted to “add another voice to those lauding the potential benefits of [weblogs, webfeeds and related technology], but purely in the context of the practice of law and the sharing of legal knowledge with clients, potential clients and, to some extent, the public generally; and to suggest how such technology [could] be put to advantageous, competitive and ethical use by, among others, lawyers and their clients.” From that point forward, I started blogging about blogging and RSS, with topics such as “The significance of webfeeds for lawyers”, “Weblogs: A primer for lawyers”, “Legal weblogs/webfeeds: Which international law firm will deploy first?” and “Blogging and legal risk”. I kept this going until November 2005 which was shortly after my second child was born and shortly before we moved from one country to another. In the meantime, in around February 2005 I’d started another blog, this time using Squarespace, on pharmaceutical legal issues, called Pharmablawg (I know… that ‘blawg’ word never really took off…).

My discovery of WordPress

It was after using Typepad and Squarespace that I got stuck into WordPress in earnest. I’d discovered WordPress in 2004 or 2005 but it wasn’t until late 2005/early 2006 that I kept reading about WordPress and discovered how easy it was to set up your own installation of WordPress and how flexible, even back then, the software was.

Almost every site I’ve built since then has used WordPress. They include a legal news aggregation site, a lawyers’ association website, a charity website, barristers’ websites and websites for my own and others’ development and marketing. I’ve even built an online contract generator using WordPress and Gravity Forms (that particular generator produces HTML output) and I’ve built another one using a combination of WordPress, Gravity Forms, Zapier and WebMerge (that one produces fully formatted Word output). (I’ll write a post about that in the future.)

I’ve benefited from the generosity of the WordPress community, attended WordCamps, purchased many commercial themes (the first being one of Brian Gardner’s Revolution themes) and plugins, learned a bit of HTML and CSS along the way, listened to hundreds of WordPress-relevant podcast episodes and paid developers to tweak sites and build plugins for me. I followed WooThemes’ development closely, was a fortunate early purchaser of a lifetime developer’s licence for Gravity Forms (what a buy!) and am fascinated by Matt Mullenweg’s recent emphasis on WordPress as a platform. This all culminates in my long-held view (shared by millions of others of course) that WordPress is a fantastic CMS.

Turning now to the legal side of things, I’ve considered a range of legal issues that can arise in connection with one’s use of, or development of themes and plugins for, WordPress. I’ve also witnessed a good number of spats. There have been spats between the founders of WordPress and theme/plugin developers (usually around the requirements and spirit of the GPL), spats between theme/plugin developers and users who have quite lawfully exercised rights conferred on them by the GPL, and spats between well-known plugin developers over alleged copyright infringement. I’ve seen the WordPress founders soften their stance on commercial themes (at least those fully released under the GPL), I’ve seen theme and plugin developers being puzzled by GPL requirements, I’ve seen the likes of Envato and others adopting a split licence for WordPress themes and I’ve seen both theme and plugin developers applying licences that, on their face, are wholly inconsistent with the GPL. I’ve discussed such matters with theme developers and I’ve thrown my hat into the ring on a few occasions.

So what…

I mention all this to demonstrate my knowledge of WordPress and passion for it. To confess passion for a piece of software probably sounds a little bizarre (no doubt Rowan will call me a “WordPress zealot” again) but, like millions of others, I love WordPress and the community that’s developed around it. Why? WordPress and its community truly made me appreciate the power of open source software and the generosity of the open source spirit. WordPress has opened my eyes to alternative business models, it has made me explore a range of open source legal issues and it has let me dip my feet and even knees into an industry which, had I been born a few years later, I’d probably have pursued in preference to law.

It is this history and my passion for WordPress that gave me the idea for writing this blog. I’d like to bring disparate legal threads together and help WordPress developers, designers and users navigate the legal issues that can arise through their varied uses of WordPress itself, WordPress themes and plugins and a range of other things. Some of these issues are unique to WordPress or specific theme shops, plugins or services while others can arise with any GPL-licensed software or any self-publishing. My goal is to cover as many WordPress-relevant legal topics as I can, in a single place, to give WordPress developers, designers and users as much of a one-stop-legal-shop as I can. I hope it helps.

Questions, questions

If you’d like me to consider any particular issue, don’t be afraid to Ask me a question. (You’ll appreciate, though, that I’m not providing legal advice on this blog.)

Tuning in with a dedication

So I thought I’d start this blog with a dedication, a bit of gratitude if you will.

Since version 1.2 of WordPress, each readme.html file included with the WordPress download has included the following “first things first” statement from Matt Mullenweg:

“Welcome. WordPress is a very special project to me. Every developer and contributor adds something unique to the mix, and together we create something beautiful that I’m proud to be a part of. Thousands of hours have gone into WordPress, and we’re dedicated to making it better every day. Thank you for making it part of your world.”

Matt thanks us, the WordPress users, for making WordPress a part of our world. It is, however, we that should thank Matt and all his co-developers around the world for making WordPress a part of our world. That’s what I reckon anyway. WordPress has affected literally millions of lives for the better. Thank you to all those who contribute to it.