Why are so many contracts that I come across so duff? What do I mean by duff? I mean bad. I mean that they contain clauses that are either a) not appropriate in the context, or b)just don’t make practical sense, or c) are so badly written that you can’t work out what they really mean, or d) are so one-sided that no sane person would ever agree to them.
This matters in a B2B context because most contracts get negotiated and the costs of that negotiation reduce the margin of both buyer and seller. If costs are incurred which could have been avoided, the end result is lower margins, increased time to market, and the creation of friction between both buyer and seller.
I came across a really duff contract the other day. My client decided to move away from the software developer he had been using – the relationship had turned sour. He found a new software developer who, after talking to him, seemed clearly much better, more competent and more committed. He was all-round better and more professional.
Unfortunately, this was not true of the contract that the software developer put forward. It was a classic duff contract and chock-full of inappropriate, ill-considered and badly written clauses. There was a clear mismatch between the message we were getting from the developer and what the contract was saying on his behalf. And, by the way, I’m not blaming the software developer. He had got the contract from a well-known law firm.
You might be wondering – how do these duff clauses end up in these duff contracts? Aren’t these contracts written by lawyers – often at pretty substantial expense – who know what they’re doing? Well, in theory, that’s clearly the case. But there’s two important factors that we need to bear in mind. Firstly, there’s the brutal fact that a number of lawyers don’t always know what they’re doing. Secondly, lawyers are very risk-averse and that same aversion to risk produces some strange results.
One of the ways that aversion to risk manifests itself in lawyers is a tendency to kitchen-sink a contract. What do I mean by kitchen-sinking? It’s when you throw in everything you can think of, including the kitchen sink. The driving force is fear: the lawyer is scared that he might leave out a clause as unnecessary or inappropriate and thereby make a mistake and get sued for negligence. So rather than making a judgement call – a judgement call implies making a judgement and that in turn opens the possibility of making the wrong judgement – many lawyers will throw everything, including the kitchen-sink, into the contract.
Another way that this particular trait manifests itself is that many lawyers will often include in their contracts clauses that they have seen in other contracts even if the clause in question isn’t particularly relevant, and even if they don’t really understand the effect that the clause is intended to have. An unthinking willingness to cut and paste is just another manifestation of the kitchen sink approach.
There were a number of duff clauses in this duff contract, but today I’m going to mention just two. The first one was an Acceptable Use clause. An Acceptable Use clause (which often appears as an Acceptable Use policy), is something you will often find in the terms and conditions of consumer-facing social media and other services where consumers can post their views on a publicly accessible forum. You will often find it in SaaS and hosting contracts. Basically it says that, if you put up material on our forum which is offensive or inappropriate, then we have the right to take down that material and kick you off the forum forever. Which, frankly, is fair enough in that context. However, in this particular context, although the software developer was also providing hosting, the software he was creating for my client was a transactional platform where the end customers were businesses and quasi-regulated. In other words, whilst there may be plenty of scenarios where an Acceptable Use clause is appropriate, this wasn’t one of them.
However, what really got my goat in the Acceptable Use clause was these two provisions. Here’s the first one.
The Client is responsible for; …. maintaining email address from the forms email@example.com and firstname.lastname@example.org for receiving complaints of network abuse activities, as suggested by Internet Official Protocol Standard RFC2142. [emphasis added].
Anyone know what the Internet Official Protocol Standard RFC2142 is? No, I didn’t think so. However, I Googled it and I can tell you that it’s a proposed (yes, proposed, RFC stands for Request For Comments) standard from May 1997. Yes. May 1997. You don’t have to be an Internet guru to come to the conclusion that this document is now out of date.
The second provision was this one.
IRC services or IRC related services are not permitted. This includes, but is not limited to “IRCd servers”, “egg drops”, “bots”, and “bouncers”. The purpose of this restriction is to prevent attacks on the [Company] service due to malicious activity that has been known to occur on the IRC network EFnet and Undernet.
Does anyone remember what IRC is? It stands for Internet Relay Chat and is a form of chat technology that went out of date long before Facebook. Twitter etc. In fact, I Googled both EFnet and Undernet and I can confirm that the last post on the EFnet site was in 2015. I tried undernet.org, but I couldn’t get it to respond.
So, why are these clearly out-of-date provisions appearing in this standard contract (recently provided by a well-known law firm)? Because of the risk aversion I mentioned above. Rather than making their own judgement and taking the risk of getting it wrong, many lawyers will prefer just to cut and paste clauses they have seen in other, similar, contracts. A million flies can’t be wrong. It’s a good example of where the wisdom of the crowds doesn’t apply.
Here’s another clause from that same duff contract. You often see it in SaaS and hosting contracts and it seems to have first occurred in one of the first SaaS contract templates that became popular amongst UK lawyers. It’s been gaily cut and pasted by lawyers ever since without any thought as to what it really means.
The Client shall have sole responsibility for the legality, reliability, integrity, accuracy and quality of the Client Data.
At first blush, it sounds plausible. After all, it’s the client’s data, and the client should be responsible for it, shouldn’t they? But, if you start picking at it, it becomes less clear. What’s the difference between accuracy and quality? If there’s no difference, then why have two terms? It just confuses things. Then, what about reliability and integrity? Are they really just one thing, or two different things? And what’s the difference between reliability, integrity, accuracy and quality? Don’t ask me, it’s not my clause, and I’ve got no idea.
But, apart from this “let’s not think, let’s just chuck words at it” approach, there’s a fundamental problem with the clause, because the accuracy (or whatever) of the data can’t be the client’s sole responsibility. Yes, it’s the client’s data. Yes, the client is likely to be one of the primary inputters of the data, but the supplier also has a responsibility to maintain the fidelity of the data, not only by avoiding simple corruption of the data, but also by ensuring that any operations which the supplier’s software performs on the client data do not result in any errors. For example, a software process which adds 2 plus 2 should not produce the value 5.
I was recently acting for a neobank. We were negotiating a contract to obtain core banking technology from a market-leading supplier of SaaS banking technology. The supplier’s contract contained the term equivalent to the one above (more or less verbatim). The problem is that the nature of banking is that a number of operations are automatically, by virtue of the software, carried out on client data. For example, money comes into your account, money leaves your account, and at the end of the day there is an amount of money sitting in your account: the balance. All this data (transactions in, transactions out, balance) is going to be client data because the client will own it, but the accuracy of those operations can’t be the (sole) responsibility of the client. It’s the supplier’s software that’s carrying out the operations: more than that, one of the main points of acquiring banking technology is to make sure that these operations are carried out, and carried out accurately.
We made that point to the supplier of SaaS banking technology and they seemed to be a bit surprised: no-one’s ever raised that point with us, their lawyer replied. We ran through our reasoning and, after some discussion amongst themselves, they agreed that our reasoning was correct and they agreed to amend the clause to something which more accurately reflected the real-world allocation of responsibilities.
I’m hoping that they amended their standard form to something more intelligent, but I haven’t checked. If not, then there’s a good chance that there are a number of neobanks out there that are unwittingly assuming legal liability for any defective data produced by the supplier. That’s not a great place to be if you’re the bank.
Does the approach set out in this blog sound appealing to you? Is a lawyer that can combine legal analysis with a commercial view, and make an actionable recommendation based on that combination, sound better than what you’ve presently got? If Yes Contact Me.