This week’s musings on tech contracts…
I love light, casual, friendly language. In fact, I wrote a book that’s known for it: for explaining legal concepts in easy, colloquial terms. But the clauses in my book, The Tech Contracts Handbook, are not light, casual, or friendly. Nor is the language I recommend in our trainings. I don’t think “friendly” provides a useful goal for contract-drafting.
For instance, you’re on the vendor’s side and your colleagues or client wants friendly contract language. They want you to add some warmth to two blunt clauses in your standard terms:
1. Customer will be responsible and liable to Vendor for any misuse of the System by Users.
2. Customer shall indemnify and defend Vendor against any third party claim arising out of or related to an image Customer or a User uploads to the System
Your colleagues like these terms’ outcome, legal protection, but not their tone. Could you just soften them up a bit?

“Friendly” terms and unfriendly outcomes
Often, you can’t insert a comma without changing meaning. “Friendly” language, then, comes with high odds of changing a clause’s meaning.
How would you make the first clause above friendly? Here’s a try:
1. The Customer understands that its users’ misuse of the System could cause problems for the Vendor, so the Customer will try to prevent misuse.
That’s definitely friendlier, but what does it mean? Are you confident that, if a user damages the system, the customer is liable? I’m not. In fact, I’d say that clause could be used to avoid customer liability. It could mean that, once the customer has done “whatever it can to prevent misuse,” it has no further responsibility or liability.
Let’s try to make the second clause above friendly: the indemnity.
2. The parties both understand that images uploaded by the Customer’s users could harm third parties, so if someone sues the Vendor about one of those images, the Customer will handle the claim and protect the Vendor.
Is that even an indemnity? Probably not. The language is less threatening than the original, but it’s not clear what it means.
Courts will use extra language, even if it’s included just to be friendly
Part of the problem with both friendly examples above, and with many others, is extraneous language. By that I mean language meant to communicate friendly intent, rather than to impose obligations: the contract’s main role.
We might like explanations in contracts because they soften requirements and liabilities, leading to a friendly tone. So before imposing an obligation – as in #2’s indemnity above – we might want an explanation like the one in the friendly version of #2: “The parties both understand that images uploaded by the Customer’s users could harm third parties ….” That language might serves as a meaningless, polite preface in casual conversation. But unfortunately, it’ll mean something in contract interpretation. A court will search for meaning in every word.
That friendly language – the bold text the last paragraph – could mean the vendor accepts upload of images that create liability issues. If not, why did the vendor say it understands, “that images uploaded by … users could harm third parties”? That language could also mean the customer’s #2 obligations don’t apply to third party lawsuits about images that don’t harm third parties. So the indemnity doesn’t apply if third party harm is in doubt – or if the third party sues under a statue requiring a fix or penalties even without harm? The indemnified vendor probably didn’t intend either outcome, but the friendly language could lead later lawyers and courts down those roads.
A contract should read like an instruction manual for building furniture – or an aircraft carrier
If you’re building something from a kit, you want your instructions short, as simple as possible, and as clear as possible. You want blunt instructions, so you don’t waste time or get confused. (That statement above re furniture and aircraft carriers comes from an earlier installation of This week’s musings on tech contracts.)
It’s the same with contracts. They have a message to get across – instructions for a legal relationship. And since that relationship could be judged by a court and cost a lot of money, you can’t risk misunderstandings. So you keep it blunt.
To put it another way, good fences make good neighbors. And contracts are fences. Fences are not friendly. They’re blunt, stark dividing lines.
Friendly does work in some limited settings
Of course, your fence will probably work just as well if you paint it a bright yellow. So small friendly tweaks aren’t all bad.
If you really want friendly language, put it in recitals. Those are not contract terms, and they can be flowery. Just make sure it’s clear that, with the possible exception of some defined terms (in non-friendly language), recitals don’t create obligations.
Also, there are small steps you can take to make contracts friendly without disrupting their meaning. Replace “must” with “shall,” for instance. The latter is a bit formal, but it conveys an obligation without sounding quite so aggressive. (I don’t recommend “will” because it could be mistaken for a statement about the future, as opposed to an obligation.)
You also make contracts friendlier, in some cases, by improving drafting: writing shorter, simpler language. Ironically, that can also make them unfriendly. Short often means blunt – and that’s a good thing.
Try this yourself
Here’s a challenge: take some typical, brusque language from a contract you’ve worked on and make it more friendly. Then put both versions in the comments below. I suspect some revisions will work but many will not. I’m eager to see your language.
THIS ARTICLE IS NOT LEGAL ADVICE. IT IS GENERAL IN NATURE AND MAY NOT BE SUFFICIENT FOR A SPECIFIC CONTRACTUAL, TECHNOLOGICAL, OR LEGAL PROBLEM OR DISPUTE, AND IT IS NOT PROVIDED WITH ANY GUARANTEE, WARRANTY, OR REPRESENTATION. LEGAL SITUATIONS VARY, SO BEFORE ACTING ON ANY SUGGESTION IN THIS ARTICLE, YOU SHOULD CONSULT A QUALIFIED ATTORNEY REGARDING YOUR SPECIFIC MATTER OR NEED.
© 2025 Tech Contracts Academy, LLC