James Martin, an attorney in St. Petersburg, Florida has an article on his website regarding 50 tips for writing contracts that stay out of court. Most of the suggestions are good… a few are a little dated. This is my response to the dated things on his list:
3. Ask your client for a similar contract. Huh? If your client has a similar contract, they probably don’t really need you. Now, I’m not advocating reinvention of the wheel. If there’s a pre-existing solution to the problem, by all means, use it. But I’m guessing that someone’s coming to you to draft the agreement because you have the skills. More importantly, however, is that their template/sample probably contains a LOT of issues. So it’s usually 110% easier to start from scratch (or from your form) and customize it to your client’s specific needs.
4. Check the form books and treatises for a contract form. and 5. Buy forms on disk or CD-ROM. I don’t know who first created form books, but they’re not as good as one might think… and they’re not necessarily battle tested, either. You’d be better off getting a template from someone else you know if you don’t know where to start. There are exceptions, of course, but still – be careful (see the second part of my advice for #3 above).
6. Don’t let your client sign a letter of intent without this wording. Actually, my advice is to NEVER sign a letter of intent, regardless of the wording. As I’ve said before, a Letter of Intent is usually just a poorly written contract. Don’t get caught up in that mess.
9. Identify the parties by nicknames. This isn’t a hard-and-fast rule. Use nicknames only if it actually makes things easier to draft AND read. Be careful about using descriptive terms as nicknames (customer, vendor, consultant, etc) because other forms of that word could appear in the agreement. Use the “Find” feature of your word processor to discover if this is true.
12. Include recitals to provide background. I know a lot of people love these. But I hate them. I hate reading them and I hate writing them. On the other hand, for complex deals where the agreement could apply to many different things and you want to be clear on what the contract is really covering, this is the place. But for a standard software agreement, the place to list the products is in a product schedule… that way you can use the same license and only add additional product schedules w/o having to amend the agreement itself to modify some “Now therefore, the parties agree to license Word Processing application.” type of language.
17. Title it “Contract.” Actually, the better advice is to simply make sure that it doesn’t say “proposal” or some other transient contract type (like “letter”). Granted, I like document titles “Software Licensing Agreement” or “Amendment to Master Services Agreement”. But putting “Contract” in bold at the top of the first page is silly and WAY outdated.
24. Write number as both words and numerals: ten (10). I agree with Ken Adams on this one. Use the standard rules for numbers: words for zero through ten and numerals for 11 on up.
25. When you write “including” consider adding “but not limited to.” Not worth adding. Ever.
26. Don’t rely on rules of grammar. WHAT!?!?! OK. Look. Use plain English wherever possible. Write clearly. Using superior grammatical skills. If you don’t have such skills, don’t draft contracts.
29. Be consistent in grammar and punctuation. Well, at least Mr. Martin shows consistency in his inconsistency regarding grammar.
30. Consider including choice of law, venue selection, and attorneys fee clauses. Consider? Absolutely include choice of law and attorney’s fee clauses (though in some cases attorney’s fees won’t ever be granted… but it doesn’t hurt to ask). On the other hand, you’ll almost NEVER get venue if the other side understands it well enough to ask for a different location. But if you’re both in the same location, it never hurts to add it in to make sure you won’t be dragged out of state.
32. Define a word by capitalizing it and putting it in quotes. and 33. Define words when first used. No and No. Define words in a definitions section up front. Unless you only have an average of one defined term per section. Then you can define “in line”. Otherwise it just gets too ornery to try to make sure you define the term the FIRST time you use it. This is especially true when definitions end up getting used in the definition of other defined terms.
34. Explain technical terms and concepts. If you’re using terms that laypeople can understand, the only technical terms that should appear should be in a statement of work or other descriptive document regarding the work. As such, it should be written so as to be understandable by the people that have to abide by the contract. Judges and lawyers can find technical people to explain technical terms. The only time you should explain technical terms is if there’s a reasonable disagreement in the technically-educated community as to the usage of the term.
35. All contracts should come with a cover letter. Not necessary. If your contract is so difficult as to not be able to understand how to sign it, you’ve got a problem. The best thing I’ve seen so far? “Sign Here” tape flags that you put on the side of the document they’re supposed to sign for each signature line. Then paperclip your business card to the front with a post-it note attached thanking them for their help and asking them to sign and return one of the two originals.
38. Use your word processor’s spelling and grammar checker. Yes, but don’t rely on it. Two, to, too, toe. Their, there, they’re. Through, thorough. Notice anything? They are all real words and spelled correctly. Spell checker isn’t going to flag any of these. Grammar checker is no better: “A parakeet is not a bluebird.” is grammatically correct. But if you intended to say that a parakeet isn’t blue, the prior sentence is not correct but won’t be flagged.
42. Save the drafts as multiple files on your computer. Yes, but not how it was recommended. Unfortunately, using periods in your filename is still problematic for some operating systems. Weird abbreviations for drafts, comparisons, etc are also hard to decipher. Instead, try this: “filename vX date initials.doc”. So if you have a file called MasterService and it’s the 4th iteration being saved on September 29, 2009 by Jeffrey I. Gordon, the filename would be: “MasterService v4 092909jig.doc” Why do I do it this way? Well: a) it keeps the files in draft order in virtually all file systems (Windows, Mac, Linux); b) it notes which version it is (saves on confusion about which document is the latest); c) notes the date it was created; d) notes who created the draft. Sometimes I’ll substitute my company’s TLA instead of my name… but usually, I like my initials better to let me know that I was the author of that version of the document. When I get the last version that becomes the final, I change my initials to FINAL – so the name would now be: “MasterService v10 101509FINAL.doc”. This lets me know that v10 was the final and which version was signed.
44. Print the contract on 24 pound bond paper instead of 20 pound copier paper. Not worth the cost of paper. Especially if you want the other side to sign first – ask them to print two originals, sign both and send to you… you can’t control the paper it’s printed on. Besides, if you’re using a contract management system, you’re going to scan and forever more look only at the digital version, so the paper is irrelevant and not worth the added expense.
47. Initial every page of the contract. Wholly unnecessary unless you don’t trust the other side and you’re signing first. But as I’ve said before, if you don’t trust the other side, you shouldn’t be doing the deal in the first place.
48. Identify the parties and witnesses who sign by providing blank lines below their signature lines for their printed names and addresses. and 50. Add a notary clause that complies with the notary law. Witnesses and notaries aren’t necessary unless required by law for the specific type of contract you’re closing (usually for real property, but I’m not sure it’s required for any other type… anyone know for sure?). Many businesses have a notary on staff, but unless the document is required to be signed “under seal”, this also is usually not a requirement and is an added expense to some (and added time/effort for everyone).
David Dobrin (of The Applicator fame) wrote recently on the topic of brittle applications. He defines a brittle application as “one that doesn’t work unless a lot of disparate conditions are met.” In thinking about his description of MS-Word, I was struck by the concept that many contracts I encounter are brittle as well.
To illustrate my point, think about the last contract you reviewed. Did it have a definition section? How about references to external documents (a spec list, a set of documentation, a “missing” Exhibit or Appendix)? Was it full of cross-references or have noticeable gaps (such as missing language for standard terms)? Was the contract obviously written for a different type of product or service? In all of these situations, I believe you have a brittle contract.
Contracts are “incorporated” documents. This means that all of the various sections have to work and play together to form a cohesive end-product. When you’ve identified gaps, errors or problems, these mistakes can cause cascading failures throughout the entire agreement. A poorly-defined term, for example, could ripple through the contract, causing errors in judgment regarding expectations, or could even create legal problems with regards to intellectual property. In other words, the poorly-defined term doesn’t hurt itself, it hurts the entire document.
The same is true for commonly overlooked sections on subjects such as term, termination and scope. When a lack of attention results in an incomplete picture of the relationship, the net impact can be extremely detrimental (ever had a perpetually-renewing contract for poor services that was hard to get out of because termination was only for breach, yet the services weren’t defined well enough to hold the vendor to performance standards? I have.).
You can also look at brittle contracts from another perspective, one my friend D.C. Toedt might appreciate. D.C. seems to love language portability – drafting contract sections that can be used in a plug-and-play format to craft the appropriate document (you should check out some of his work in his clause library). This type of drafting is a part of the holy grail of contracting – the complete automation of the contract creation process based on a wizard-style interface which asks questions and assembles an appropriate finished product from such a library of contract clauses.
The inherent problem with document assembly is brittleness – that you insert a clause into the agreement that has to properly “work” with all of the other sections. If the clause has a faulty cross-reference, for example, the contract breaks. On the flip-side, however, document assembly fixes one of the aforementioned brittleness issue with current contracts – having a completely appropriate document for the specific product or service being offered under the agreement.
So… how brittle are your contracts (especially your templates)?
Filed under: contract format, contract management, contract terms, current events, law, negotiation
This Week on The Web. Interesting articles, stories and thoughts from around the web this past week that are related to contracts, licensing, negotiation or law:
AdamsDrafting
- Wal-Mart Case Raises Issues of Categories of Contract Language
- Another Instance of Semantic Ambiguity: “Buys”
- My Response to Someone Seeking Advice on Contract Drafting
- Contract Interpretation and Contract Drafting
Corporate Insurance Blog
E-Sourcing Forum
Firstdrafter
- Federal government is increasingly wanting unlimited rights in data, say commentators
- State law peculiarities – things to keep in mind in negotiating a choice-of-law clause
- Vendor sends its standard T&Cs after the deal is struck by e-mail – and later finds the T&C protections aren’t part of the contract
- An early-neutral-evaluation clause can help keep contract disputes out of court and protect business relationships
Madisonian
- Judge rules that a burrito is not a sandwich
- Our future as “parasitic aggregators” is in jeopardy
- How much of this do you think is copyrightable?
- Irony (Updated)
Settle It Now Negotiation Blog
- Negotiating Unity: Gettysburg, Rhetoric and Poetry
- Mediation of Insurance Disputes in the London Market
The (non)billable Hour
- What Do Your Clients Think About You?
- A Legal Blogging Roundtable
- Twelve Truths About Time
- Ten Rules for Presenters
In a strange twist of irony, I’m going to tell you that repeating something doesn’t make it true by pointing you to a 2006 post I wrote about Repetition.
It also appears that I think about this topic around holidays, too… but that’s irrelevant. The real reason I find this important is the recent internet slowdown caused by the massive use of social media tools to report Michael Jackson’s death about 30 minutes before he actually died. It wasn’t important that he was dead or alive, it was important for someone to be the first to report it (this happened again in New Zealand later that day with respects to Jeff Goldblum – thankfully, he’s alive). And while Jackson eventually did die, it wasn’t because the messengers made it true. The actual result was that people copied the message over and over, spreading false information. Like most rumors, it traveled like wildfire. Facebook, Twitter, MySpace, the blogosphere, Google, Yahoo!, etc… each experienced massive delays.
Moral of the story: remove repetitious language from your agreements. Oh, and don’t twitter as truth what you don’t really know to be true.
Have a Happy Fourth of July (whether it’s your Independence Day or not)!
In last weeks’ post, I stated that contracts don’t instill trust. Today, FirstDrafter (nom de plume of licensinghandbook reader D.C. Toedt) has a post where he disagrees with Ken Adams and says that contract terms need explanation as necessary. It should come as no surprise that I agree with Ken, but not based on Ken’s reasoning.
In Ken’s world, efficiency and breviety (with clarity of thought) are key. His opinion is that contract terms shouldn’t have explanations because a) it’s restating what was already said, b) confusion might result from the restatement. Ken clarifies that examples may be useful to show how a particular clause would play out (such as a pricing calculation) and that explanations might be warranted in specific situations where there is evidence to suggest that a particular set of “magic words” (contract phrasing you think necessary to get a ruling in your favor in the event of a dispute) might not be as magic as you believed.
D.C. seems to consider things from another perspective. Say, for example, we contract, including explanations as to our logic for selecting the particulars of the transaction, and then we have a disagreement. We go back to the document to negotiate a settlement (or we go to court seeing judicial review). In D.C.’s process, the reviewers (us or the judge) can read the logic, using it to help them decode the language and find a solution. However, I’m hard pressed to think of a situation where that would lead to real progress. In my mind, the logic is part of the contract language itself (not the Gemara – Talmudic commentary on the language) – so if the explanation explained the reason for the “how”, the “how” is still the process which must be followed. So even without the explanation, the “how” is still left undisturbed after judicial review. This goes back to Ken’s desire for contract efficiency – restating simply leads us to the same conclusion we would’ve had without the restatement.
I’ve been giving this a lot of thought recently, as I’ve felt quite torn over strict contract language and the need to try to write in Plain English™. Interestingly enough, comments in Ken’s post also suggest the need for explanations in consumer contracts. But I think it’s worth asking whether we can take Ken’s desire for simplicity and efficiency to the next level and write Plain English™ sentences throughout an agreement – eliminating jargon, Latin, magic words and other staples of contract drafting. (This is central to Ken’s entire specialty. The MSCD is his effort to help us write better agreements. If you draft/redline agreements but don’t own it, you should. By his own admission, it’s not perfect – but it’s a long way down the path towards perfection.)
Since I don’t have Ken’s laser-like focus on the language itself, I’ve been pondering whether a non-binding contractual sidebar would help the parties understand the intent behind the language. While there are perhaps good reasons to have explanations in contract terms – my conclusion ends up more in direct opposition to D.C.’s supposition that a party might later decide that they don’t like or want to do something in the contract the way it was contracted:
Tough luck.
A contract is NOT a guideline document or a suggested course of action. The essence (the tao) of a contract is that it’s a set of rules that both parties agree to follow. If you don’t want to be told how to do something, don’t sign the agreement. If you think that there might be improved methodologies in the future, don’t decide on the how – focus on the end result instead. But if you do, in fact, agree that we are going to act in a particular way, at a particular time, to achieve a particular result, for particular consideration, for a particular duration … and then you decide to unilaterally choose a course of action that countermands one of our agreed upon particulars … you should expect me to react in an unpleasant manner. If you don’t understand the terms (and/or can’t figure out how to use the “what if” game to see how the language would play out in real life), don’t sign the agreement.
Granted, D.C. is correct that it takes people to carry out the instructions and judges to interpret the disagreements. But they don’t need the why, either. If the contract particulars are problematic in any way, shape or form, there is a process to change it: the contract amendment. Until then, however, the only why you need to remember is that “that’s what was agreed at the time the contract was signed.” And while this sounds like a question and answer session with a two-year-old, that’s really the only answer that applies.
Deven Desai over at madisonian has a great post on Theory and Law Practice. I’ll let the article do itself justice, but the explanation for understanding theory is exactly why I usually demur when asked to provide templates, either here on this site or within the Software Licensing Handbook.
Giving the template to someone is like handing them a fish but expecting them to figure out how to fish with the thing flopping around in their hands. Hopefully, what I’m doing here is teaching you to fish (I like to think of it as deep sea fishing, actually… strapped into a chair on the back of a large boat… hauling in that sailfish that might skewer you if you’re not careful) – so you can develop your own templates and respond to someone else’s templates, all without breaking a sweat.
Douglas Gries over at Dymond Reagor Colville wrote an excellent piece on his blog about using contracts as value added business tools. I couldn’t agree more.
I joke a lot about contracts being for the divorce, not the marriage. But the reason that this joke is accurate is that the contract is (supposedly) the best piece of material you have to review when a relationship starts to go bad. The contract represents the world as the lovers saw it at the beginning of the relationship – full of possibility and promise, and perhaps a little bit of caution, too. Because of this, it’s a great document to review when you’re trying to repair damage and correct behaviors.
Unfortunately, too many agreements aren’t written in a way that actually gets at the intent of the parties. Instead, they’re filled with lots of appropriate terms and conditions – legal phrases and jargon. Which is fine, but when you’re trying to reconstruct each parties’ intent, falls flat.
In the old days, this was resolved with a lot of “Whereas, Now Therefore” clauses at the beginning of the agreement. You would use the Whereas statements to highlight the background of the relationship and the Now Therefore to indicate that the contract was the resulting action of the Whereases. But I think even well-crafted Whereas statements don’t get to the real heart of the matter.
So sometimes, I’ll try something a little different. A “Purpose” statement. Near the top. Right under the introduction about who the parties are, but before Section 1. The purpose is to lay out what is happening and why the contract is being signed. It can be as simple as “The parties are creating this agreement to provide the base terms and conditions for the vendor to provide service to the client.” or it can be super-specific: “The vendor is going to provide xx software to accomplish yy tasks along with zz support/training/installation services, as more fully described herein and in any attached SOWs.”
This type of purpose statement helps a subsequent reviewer (the divorce attorney, if you will), figure out some of the initial intentions and what a particular contract is trying to do. Sounds silly, perhaps, but I just reviewed a few dozen contracts in the last few days – and not one of them told me what the product or service was. Which meant that I had to try to figure it out based on what I knew the vendor offered – or based on clues left throughout the agreement. Not easy and not fun. But it made the review more challenging because I needed to know the scope of the offering before I knew what things to potentially look for or add to each agreement to cover the associated risks.
Oh, and if you think that cover sheets, memos or other documentation created at the time the contract is negotiated will explain it – well, perhaps it will. But you’ve got two problems with it: 1) it almost never makes its way with the contract; and 2) you can’t rely on it from an evidentiary perspective (we’re going to avoid the conversation about parol evidence here, but you might be interested to learn more).
Ken Adams is discussing definite articles over at his blog today. The question is whether it’s appropriate or necessary to include the “the” before a defined term such as Vendor. I’ll let Ken explain it in his own words.
In the ensuing small comment debate, I wrote a second response that apparently “muddied the waters” of the discussion. But I felt the last argument had merit and I wanted to discuss it further with you.
Here’s my second (unpublished) post:
Oh, I agree… it IS semantics. But when I’m drafting/reviewing/editing 200+ documents/year, sometimes that’s all I have. 🙂
My average template software license and services agreement is more than 35 pages long. If my opponent decides that they want to change VENDOR to ACME, I have to be honest and say that I don’t want to have to go through the document again to remove each instance of “the” in front of ACME – because most likely, they’ve done it about 2 or 3 revisions in (when it’s not as easy to just undo and re-do properly).
In thinking about it more, however, aren’t we actually converting the defined term into a proper noun? And in doing so, putting a definitive in front of it is actually incorrect for the same reasons why you don’t say “The Acme” or “The Jeff”?
Specifically, I think that the use of a defined term might convert that term into proper noun… and even if it doesn’t automatically, it would if the item it’s defining is a proper noun. In other words, “Vendor” would be a defined term that would also now convert into a proper noun because it’s serving as a replacement for “Acme Corp”, which is already a proper noun. On the other hand, “Services” might not be a proper noun, as the term Services is typically defined as “the work performed by the Vendor”.
Thoughts?
My Macintosh-geekery is pretty extensive. I’ve got a solid collection of Apple-related paraphernalia, computers, advertising pieces, etcetera. Amongst the collection are about a hundred shirts (I’m not exaggerating here, ask my wife). One of them is relatively recent and it’s one of the few that I wear, as the rest are pretty old.
This particular shirt is fairly plain – solid black with a white Apple logo on the back and in a rare departure from my preferred blank front, has “I (Apple logo) code.” on the front, dead-center on the chest. When I wear it, I have always kinda’ felt like a fraud. I don’t program computers. The most I know are the names of the various languages: C, Perl, Java, Ruby on Rails, PHP, etc. But when asked, I always say that I couldn’t code my way out of a paper sack.
I realized today that I’m wrong – to borrow a marketing slogan from Apple, I just needed to Think Different. Let’s start with two definitions.
Code (n): a system of words, letters or symbols assigned to something for the purposes of classification or identification.
Program (n): a series of instructions to control operation.
Hmmm… I think I might actually fit into these with a little twist. I am a Deal Coder. Yep, that’s right… I write code and programs. But you’d probably call it a contract. I take words and symbols and I combine them in a specific way to achieve a particular result. Each section of a contract is designed to address a specific set of circumstances. We even have what computer programmers call “comments” in our code – have you ever read a “Whereas” clause? It’s just a place for us to explain the why behind our code.
Heck, we even use similar language to describe how we run our code – execution. Oh, and we have buggy code, too. We issue contract revisions (amendments) much the same way a computer programmer provides bug fixes. And when we’re done with our use, we terminate what we’ve done.
Like computer programmers, we not only have to learn the language we’re coding in, but more specifically, as we improve, we have to learn how to refine the language we use. We clarify, we revise, we edit (see the work of Ken Adams in my blogroll). We reduce the bulk (bloat) where we can and we look for ways in which we can recycle code we’ve written before. Herein lays another overlap in language – we both have toolboxes of prior code that we use again and again to achieve a similar result.
So I am a Coder (Koder? 😉 ) and I do love my particular form of code. I’m wearing my shirt today with a new found sense of pride!
Are you a Koder?
Cna yuo raed tihs? Olny 55 plepoe out of 100 can. i cdnuolt blveiee taht I cluod aulaclty uesdnatnrd waht I was rdanieg. The phaonmneal pweor of the hmuan mnid, aoccdrnig to a rscheearch at Cmabrigde Uinervtisy, it dseno’t mtaetr in waht oerdr the ltteres in a wrod are, the olny iproamtnt tihng is taht the frsit and lsat ltteer be in the rghit pclae. The rset can be a taotl mses and you can sitll raed it whotuit a pboerlm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe. Azanmig huh? yaeh and I awlyas tghuhot slpeling was ipmorantt!
from http://swissmiss.typepad.com/weblog/2008/01/cna-yuo-raed-ti.html
Forget about automated spell-checkers for a moment… I wonder what effect this would have on contract reviews. Or, more specifically, contract accuracy? Would it matter at all? Thoughts?
NET(net), Inc. 