Terms of use
comments 2

When changing your terms of use, do you respect your customers?

Recently I received an email from a WordPress-related business telling me its terms of use had been updated. The email didn’t specify what had changed so, for some strange reason (a lawyer’s idle curiosity perhaps), I clicked through to see the latest terms, half hoping to see a change log or a blog post summarising what had changed. Did I find any such thing? No. The terms themselves only had a “Last modified on X date” entry. No change log. No explanatory blog post. And the site contained no archive of previous versions that would enable me to do an automated comparison, assuming I’d be motivated enough to do that. (I suppose one could try the Wayback Machine but a paying customer shouldn’t need to resort to that.)

These terms were over 4,500 words long. I’m not sure how any user is supposed to understand what has changed in these circumstances. In many if not most countries, users will bound by the changes, thanks to what’s called a unilateral variation clause (a clause that allows one contracting party to amend a contract’s terms without the consent of the other party) together with a fairly standard “you’re responsible for reviewing the terms on a regular basis” statement, but the point I’m driving at here is not a legal one. It’s a ‘respect your customers’ one.

Imagine a commercial plugin developer who releases an update to a commercial plugin and says, simply, “we’ve updated the plugin folks”, without any reference to the reason for the update or to what has changed. Just as that’d be poor form, so too is it poor form (in my view anyway) to change your terms of use without any summary of the changes in a notifying email, a change log underneath or linked to from the bottom of the terms, or a blog post.

A statement in any of these places doesn’t need to specify the changes word by word with military precision, but it is helpful to summarise the changes for the (perhaps small) subset of customers who might actually care about what could be a change to their contractual rights or obligations.

I mention this not because I was particularly irked by not being able to identify the changes on this particular occasion (the business in question is superb and I trust it) but because usability / customer experience considerations shouldn’t stop at the point at which a lawyer cobbles together some terms of use for your business or makes some changes to the terms when requested. To the contrary, if I’m a paying customer and my rights or obligations are being changed unilaterally, it is entirely reasonable to expect to be told – even if only in summary form – what is changing.

Now, I know that many sites don’t do this and that many customers wouldn’t care but, in a competitive market, why risk losing those customers who might care about such things to a competitor?

(Featured image: Sergey Nivens / Bigstock.com)


  1. Hey Richard,

    Excellent article. I, too, am frustrated by the “our terms have changed” notices pointing to a 12-page, single spaced document that looks oh so much like the last one I agreed to. I like your comments about summarizing the changes.

    I am now working with an attorney here in the US to draft my first privacy policy, website terms of use, support agreement, etc for my site. It’s just like the code I write – document, document, document – so I, and anyone else, knows what changed when everything is reviewed days, weeks, or months later.

    I enjoy your site. Keep up the good work.


  2. about plugins to swftoare released under the GNU GPL:It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, so plug-ins must be treated as extensions to the main program. This means they must be released under the GPL or a GPL-compatible free swftoare license, and that the terms of the GPL must be followed when those plug-ins are distributed.If the program dynamically links plug-ins, but the communication between them is limited to invoking the main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.This is an accurate assessment of the meaning of the GPL in terms of compiled code. When applied to scripting languages such as PHP, however, things get a bit hazy.When WordPress dynamically includes some code (as it does with configured plugins), it could be argued that that code is essentially being linked ; as the process is conceptially very similar to the linking process used to produce a binary. However, in compiled code the end result is a binary, and part of the object code in that binary is a machine translation of the source code that was included. Since that source code is being combined with GPL’ed source code to produce a single program, it must be GPL’ed as well.With PHP and WordPress however, the source is interpreted and the end result is markup that defines a web page. The Free Software Foundation has always been very clear in stating that the output from GPL’ed programs is not covered by the GPL; a good thing, because otherwise every webpage served from Apache Web Server would have to be free for public reuse, rendering copyright on the web useless.In the case of a WordPress plugin, WP invokes 3rd party code when specific events occur. This 3rd party code must conform to a specific interface that WP expects, but that’s no different than requiring a Windows executable to be in a specific format and provide specific entry points; which certainly doesn’t place licensing restrictions on the executable in question.As I see it, if 3rd party PHP code contains pieces of WordPress source code, it must be GPL’ed. If it merely calls functions provided by WordPress (most WP plugins make use of either the add_action() or add_filter() functions), I’m not so sure. If it doesn’t call any of WordPress’s code, it wouldn’t have to be GPL’ed. A Linux binary doesn’t have to be GPL’ed but if it links to GPL’ed libraries provided with Linux, well, things get so confused that the FSF came up with the L-GPL just to address the issue.It really boils down to this:Given a plugin that is released under a commercial license, and assuming momentarily that WP’s license absolutely restricts the use of plugins to those that are distributed under the GPL, installation and use of that plugin would invalidate the commercial license it was distributed under. The plugin would not automatically become GPL’ed swftoare, it would simply not be licensed at all, and any webmaster using it would be doing so without the legal right to redistribute it, as no valid license gives him that right. This is usually the primary function of a commercial license, and that restriction would remain effectively intact. Regardless of licensing, the author would still hold copyright on the plugin, and would have legal recourse should his customer redistribute his intellectual property without permission.Furthermore, the author of such a plugin is not constrained by the terms of the GPL, as there is no requirement that he accept those terms in order to develop his plugin. He can code plugins all day long without so much as downloading WordPress. (Testing, granted, would be a bit of a chore.)The long and short of it is: WordPress plugins that aren’t derived from some piece of GPL’ed code dont have to fall under the GPL themselves. And if for some reason they did, breaking that constraint wouldn’t have much effect in terms of legal rights and responsibilities.

Leave a Reply

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