Reviewing the Manual of Style for Contract Drafting by Editing Twitter’s Patent Agreement
Synopsis for lawyers
You should really buy the Manual of Style for Contract Drafting – it’ll make you a better drafter and editor. This post applies the book’s rules and guidelines to a publicly-available legal agreement (Twitter’s Innovator’s Patent Agreement) to explain what the book is and why it is valuable.
tl;dr, for programmers
Contract writers have no equivalent of RFC 2119, mostly because contract drafting is hard. MSCD is a good try – defining terms and demanding consistency, just like the compiler lawyers lack. This post is a rewrite and fleshing out of the github edit history.
- A contract for the selling of a field and a house, from the Sumerian city of Shurrupak, now in the Louvre.
Introduction
I’ve believed for several years that the Manual of Style for Contract Drafting is a book that “every commercial lawyer should have on their desk“. You can judge the MSCD from its cover: it is aimed at people who draft contracts, attempting to teach them how to improve their writing style so that the contracts they create or negotiate are more legally precise, more concise, more enforceable, and easier to understand.
When Ken offered me a copy of the Third Edition for a book review, I jumped. But good reviews got written fast and I had nothing new or different to add. So I let the book review project sit for a while.
The thing is, once you’ve read MSCD, every time you read a legal document (even a good one!) you immediately start noticing small details that scream “MSCD would not approve”. So when I saw that Twitter’s Innovator’s Patent Agreement was on github, and started noticing those same small details, an idea was born: write a book review, in the form of public edits of the agreement.
This is that review. Quoted text is from the agreement, with additions in blue underscore and deletions struck through in red (following standard legal style for edits). Unfortunately, the original plan (simply copy the comments from the github edit history into the blog post) did not pan out, but if you’re comfortable with reading git histories, an un-massaged version of the review below is in my github account.
This is not about Twitter!
To be clear, this is a review of MSCD, not a critique of the Twitter IPA. The Twitter IPA was used simply to apply the book to a “real world” document and make it more tangible. The fact that you’ll see a bunch of edits below doesn’t mean the IPA is a bad document. Relative to some other documents I could name, including many I’ve written, this is actually a pretty small amount of edits. Because there are so many rules and suggestions (400+ pages of them!), applying MSCD to virtually any real-world contract will lead to a wall of edits. So this does not reflect badly on the drafters of the IPA, and shouldn’t be taken as a negative commentary on the substance of the agreement – which I think is important and innovative.
Note for non-lawyers
As I noted in the tldr, this book has a lot in common with RFC 2119 – the document that tells internet standards writers what words like “should”, “must”, “recommended”, etc., mean in the context of Internet Engineering Task Force memos. RFC 2119 is important to write a good standard, but at the same time, it is not a substitute for understanding of the relevant technology. Similarly, this book is about contract style – it can tell you how to fix language, but isn’t a substitute for actually understanding contract law or other bodies of law a contract might deal with, like IP. So don’t buy it and think it’ll turn you into a contract drafter :)
The Review
Key principles
The book opens with a discussion of key principles for contract drafting (the “Characteristics of Optimal Contract Language”). Most of these are Plain English Drafting 101 stuff, like “omit archaisms” and “omit problematic terms of art”, or “be precise” and “employ usages consistently”. None of them are rocket science. And yet, once you’ve read the rest of the book (and as you’ll see below), you’ll realize that most contract drafters mostly only pay lipservice to these principles. By elaborating these principles into extensive, highly detailed rules, MSCD will make you realize how badly most contracts violate some of these “obvious” things.
Organization and contract front matter
MSCD is very organized, in much the way you’d look at a contract – front to back (though not always). In that vein, chapter two covers the literal front of the contract – titles, introductory clauses, etc. It provides model language, ideal structures, and critiques traditional language; consistent with the rest of the book, it goes to an extreme level of detail to help drafters choose the exact best styles, consistent with the principles laid out in the first chapter. Applying these rules gives some sense of the flavor of the book as a whole.
For example, MSCD 2.110-113 discusses (and recommends against) the traditional use of a single word: the defined term “Agreement”, primarily on grounds that it is repetitious (violating one of the principles of chapter 1). In the IPA, removing the term highlights that it was defined, but never used – a common mistake. (This is a recurring theme: carefully applying the MSCD rules will not only catch the rules highlighted by MSCD, but also find other problems.)
This INNOVATOR’s PATENT AGREEMENT(“Agreement”) is made between the person(s) named below (collectively referred to as “Inventors”) and [COMPANY NAME], a [State of Incorporation] corporation, having a place of business at Company Address (“Company”).
Some MSCD rules are incredibly minor. For example, MSCD 2.18 recommends against using ALL CAPS in the first sentence, because that is already done in the title. There is literally no substantive change here, but it makes things read a little better – which adds up for long documents.
INNOVATOR’sS PATENT AGREEMENT (IPA), Version 1.0
This INNOVATOR’s PATENT AGREEMENTinnovator’s patent agreement is made between the person(s) named below (collectively referred to as “Inventors”) and [COMPANY NAME], a [State of Incorporation] corporation, having a place of business at Company Address (“Company”).
MSCD tries hard to be comprehensive, but can’t. The principles of the first chapter, like MSCD 1.63-1.66, “Contract Language Should Employ Usages Consistently”, help fill in the gap. In the absence of a rule on how to do templating, my revised IPA sticks with [ALL CAPS AND BRACKETS] for values that should be filled in when the document is used.
This innovator’s patent agreement is made between the person(s) named below (collectively referred to as “Inventors”) and [COMPANY NAME], a [State of Incorporation][STATE OF INCORPORATION] corporation, having a place of business at Company Address[COMPANY ADDRESS] (“Company”).
The book’s attention to detail can occasionally be maddening. But on the whole, I find it helpful. By forcing you to look again at “the way things have always been done”, it can help you see ways to improve contract clarity and make things more readable without sacrificing (and often improving) precision. As an example, MSCD 2.68 recommends against including the address of a party that is a registered legal entity, because the combination of the full official name + the jurisdiction in which the organization is registered should be sufficient to uniquely identify the organization. From Ken’s perspective, if you need the address for communication, put it in a section on notices – not the beginning of the contract. See also the general principles of MSCD 1.41-1.58, “Contract Language Should Omit Redundancy”.
This innovator’s patent agreement is made between the person(s) named below (collectively referred to as “Inventors”) and [COMPANY NAME], a [STATE OF INCORPORATION] corporation, having a place of business at [COMPANY ADDRESS] (“Company”).
MSCD discusses dating agreements (i.e., when does the agreement actually take effect?) in some depth in 2.21-2.45 and 5.3-5.7 (four pages of discussion). This type of recommendation is one of the areas where MSCD shines, since thinking about this once and adopting a standard, carefully considered, style can avoid a variety of problems. The change below gives the agreement a date (and related signature block) in accordance with MSCD’s recommended defaults, but users of the agreement might want to consult MSCD and amend the agreement appropriately to their situation. (This is one of the rare sections where the book admits of much flexibility – it is often quite rigid in its recommendations.)
MSCD’s recommendations usually, to my eye, improve readability. In one of the few recommendations that I find less readable, it recommends the wordier phrase below to replace “Agreed to and accepted” as the closing line of the document. I use it because (1) I’m seeking in this experiment/book review to follow MSCD’s recommendations, not necessarily my own instincts; and (2) MSCD’s recommendations in this area seem well justified – you can find them at 5.8-5.22.
Note that, in the original intended use case of this document, the agreement may be dated in several other ways – for example, by submission to the patent office. However, as it is usually good form to date stand-alone agreements, I’ve included these terms here, whether or not strictly necessary.
In the opening:
This innovator’s patent agreement is dated [DATE] and is made between the person(s) named below (collectively referred to as “Inventors”) and [COMPANY NAME], a [STATE OF INCORPORATION] corporation (“Company”).
In the closing of the contract:
AGREED TO AND ACCEPTED:The parties are signing this agreement on the date stated in the introductory clause.
Strict application of MSCD while editing someone else’s contract would lead to horrible overkill, even when the recommendations are often well grounded. As an example, MSCD 2.46 recommends “between” as the preposition in the introductory clause, correctly calling traditional alternatives like ‘by and between’ “silly couplets” (a sign of legalese discussed in MSCD 1.42), and also rejecting the “made between” used in the IPA.
No sane negotiator would quibble over “made between”, “by and between”, and “between”. However, it is also a good example of where internalizing MSCD’s arguments will encourage you to be concise. A word here, a word there- it adds up over time.
This innovator’s patent agreement is dated [DATE], and is made between the person(s) named below (collectively referred to as “Inventors”) and [COMPANY NAME], a [STATE OF INCORPORATION] corporation (“Company”).
Recitals, archaisms, and categorizing types of language
WHEREAS, using WHEREAS in recitals is archaic legalese, and WHEREAS avoiding archaisms is another principle all lawyers would tell you they endorse, and virtually none practice, and WHEREAS MSCD recommends not using whereas (MSCD 2.128), I have removed it from the IPA’s recitals, and used proper sentence structure (2.129).
In discussion of recitals, MSCD uses a technique that recurs throughout the book: intense, specific, precise categorization, based on usage and purpose, with matching commentary and style guidelines. Recitals, for example, are categorized into “purpose” recitals, “context” recitals, and “simultaneous transaction” recitals, and then rules are provided for each. The IPA’s recital falls into the category of “purpose” recitals: indicating why the parties want to do this deal (2.118). Based on this categorization, MSCD suggests using ‘wants’ – which is “consistent with everyday English” – instead of the “oddly steamy” ‘desires to’ (2.131-132).
[Were I editing for substance, I might add another sentence to explain why this particular agreement was used to reach the goal of assigning the invention.]
WHEREAS theThe Inventors have invented certain patentable subject matter whichmatter, and they desirewant to assign these inventions to the Company;.
When nitpicking is also substantive change
The next change is probably the first change that will make lawyers seriously nervous, because it removes the magic words “good and valuable consideration“. In a passage that is typical of the book, 2.149-2.164 of MSCD goes into some detail about why the traditional “recital of consideration” is unnecessary, and what it should be replaced by. As is common where the book is at its best, the discussion doesn’t merely say “these are bad, you should remove them”, but instead discusses background law (the Restatements and caselaw), and explains why they support Ken’s conclusions. It also lectures the courts on what they should do, which I find tiresome. (Certainly not the only legal treatise with that problem.)
In one of MSCD’s many suggestions that should be common sense, but isn’t, the book recommends that if there is some doubt as to whether or not there actually is consideration, the magic words should be replaced with an explicit discussion of what the consideration actually is. I have left that out here because it is a more substantive question, but it would be something for Twitter’s lawyers to consider if they ever considered adopting my changes.
NOW, THEREFORE, for good and valuable consideration, the receipt of which is hereby acknowledged, theThe parties therefore agree as follows:
Specific words and the MSCD index
While diving into the IPA’s definitions, we can start seeing more of MSCD’s attention to detail by looking at the legal-ism “hereof”. MSCD hits on hereof in three places – 4.92, 13.260, and 15.12. The relevant one here is 13.260, which simply recommends avoiding all “here-” and “there-” words, correctly calling them “one of the hallmarks of legalese.” (See below for more discussion of herein.)
This sort of thing is one of the strengths of the book. Almost a third of the book is Chapter 13, a list of words and phrases, with advice on how best to use every single one. Much of it does not apply to the admirably simple IPA, but most contracts will hit on a number of the words and benefit from reading the advice.
Note that this change also uses “the date of this agreement” as part of the replacement for “hereof” because, for simplicity and readability, MSCD 2.28 recommends using “the date of this agreement” rather than the traditional “Effective Date”.
“Affiliate” means with respect to any Entity, any other Entity, whether or not existing on the date hereof,of this agreement, controlling controlled by or under common control with such first Entity.
MSCD 13.376 is quite clear: no latinisms, except the most basic ones – pro rata, status quo, vice versa. This is a good example of how following MSCD will make documents more readable not just for other lawyers, but also for non-lawyers as well.
Any sublicense granted by the Inventors under this section must be without threat or additional consideration; otherwise, the sublicense will be considered void ab initio.from the beginning.
Relatedly, MSCD’s index is excellent and really key to using MSCD well: once you’ve gone through the book once and have internalized the important points, you can use the index every time you’re unsure of a specific phrase or concept. So, here, I saw “hereof”, thought “I’m pretty sure MSCD has a discussion of ‘hereof’”, and used the index to quickly find and review the discussion. Certainly, the index is what made this review possible!
Categories of contract language: performance, declaration, obligation
Chapter 3 of the book is about “categories of contract language”, where different categories (like language of agreement, of obligation, and of performance) are identified, and rules (and examples) set out for each one. Language of performance is highlighted as the kind of thing that the contract itself causes to occur. No less than 16 different commonly used ways of expressing this are identified and graded from “avoid” to “recommended.” “Hereby” comes out on top (“recommended”), and above “do hereby”. Once you’ve read his analysis, you’ll probably agree it’s the best way to express that the contract itself causes the action to occur. So I use it here, despite it being an archaic “here” word.
To me, breaking down language into categories like this (and others like them) are MSCD’s most useful mental discipline, because they help me think through exactly what I want a given clause to do, and then they give me the right language to do it with.
[Again, trying to stick to edits MSCD specifically recommends. Here, the mixed-tense 'sell'/'have sold' language is very unclear and unusual, and could probably stand to be rethought or removed, but is not, as far as I can tell, a clear MSCD violation.]
1. Subject to the terms and conditions herein, Inventors do hereby sell, assign, and transfer and have sold, assigned, and transferred to the Company, for itself and its successors, transferees, and assignees, the entire worldwide right, title, and interest in and to the following patent application(s):
Another category of contract language that MSCD goes into in some depth is “language of declaration” – i.e., language used by the parties to declare facts. This category is then further split into statements – used when one party wants to assert that a statement is accurate – and acknowledgements – used when one party wants the other to admit knowledge and accuracy of a statement.
Lawyers traditionally use “represents and warrants” to handle statements, but MSCD goes on at great length (citing caselaw, the UCC, and a few dictionaries) as to why this is a bad idea, and why “states” should be used instead. Importantly, he emphasizes that relying on “represents” to trigger a specific sort of remedy is unreliable, and that instead contract drafters should be explicit about what remedies they expect and how they will be enforced. (You can get the flavor of the argument, and his approach throughout the book, in Ken’s blog post on the issue.) Changing it here is a reminder that the book will make some lawyers uncomfortable (by challenging ritual word use) and can help drafting (by encouraging drafters to be precise and explicit about things like remedies). A more full rewrite of IPA could carefully consider the remedy question, though I tend to think that given the structure of the IPA it is not a substantive problem with the agreement.
Inventors representstate that Inventors have the rights, titles, and interests to convey as set forth herein; and Inventors covenant with Assignee that Inventors have not made and will not make any assignment, grant, mortgage, license, or other agreement affecting the rights, titles, and interests herein conveyed, except as explicitly set forth herein.
The other part of language of declaration – acknowledgement – is traditionally handled with “acknowledge and agree”. MSCD 3.318 (and 3.18) points out that the parties already “agree” to everything in the agreement in the opening of the contract, so “acknowledge and agree” later in the contract is redundant. (Redundancy is, correctly, another key sin MSCD acolytes hate.) This edit changes both “acknowledges and agrees” to simply “acknowledges”, and also removes a redundant “Inventors agree that”.
Inventors agree that Assignee may apply for and receive patents for Subject Matter in Assignee’s own name. Assignee acknowledges and agrees that the above promises are intended to run with the Patents and are binding on any future owner, assignee or exclusive licensee who has been given the right to enforce any claims of the Patents against third parties.
Assignee acknowledges and agrees that the promises in section 2 and 4 are intended to benefit third parties, except in the case of an assertion of claims of the Patents authorized under section 2.
“Language of obligation” is, not surprisingly, a key category of contract language, and one that MSCD goes into in some depth. One of the key recommendations on “language of obligation” is careful precision about what word is used to indicate obligation, which most contract drafters are somewhat sloppy about – sometimes using shall, sometimes using will, sometimes using must, without particular rhyme or reason.
MSCD 3.46-3.85 recommends using “shall” instead of “agree to” to indicate when one party is obligated to – has a duty to – another. This is one of the few places where a post-MSCD contract will look more like legalese, but again, the justification is thorough and persuasive. Following this recommendation, I have removed two instances of “agree to”. The same analysis of language of obligation also recommends many places where shall should not be used- this same change removes two of those uses.
2. The Company, on behalf of itself and its successors, transferees, and assignees (collectively the “Assignee”), agreesshall notto assert any claims of any Patents which may be granted on any of the above applications unless asserted for a Defensive Purpose. An assertion of claims of the Patents shall be consideredis for a “Defensive Purpose” if the claims are asserted:
3. Inventors agree that Assignee may apply for and receive patents for Subject Matter in Assignee’s own name. Inventors agree,shall, when requested, and without further consideration,to execute all papers necessary to fully secure to Assignee the rights, titles and interests herein conveyed.
This license to the Inventors is not assignable, although the license shallwill pass to the heirs of an Inventor in the case that the Inventor is deceased, and the Inventors, individually or jointly, may appoint a representative who may act on their behalf in granting sublicenses under this section.
“Covenants to” also falls afoul of Ken’s sword as a poor choice for language of obligation (3.86). Here I remove it, though the usages in the IPA are somewhat unusual and so tricky to replace.
Assignee covenants with Inventors thatshall encumber any assignment or transfer of its right, title, or interest herein will be conveyed with the promises herein as an encumbrance.
3. Inventors state that Inventorsthey have the rights, titles, and interests to convey as set forth herein; and. Inventors covenant with Assigneestate that Inventorsthey have not made, and willshall not make, any assignment, grant, mortgage, license, or other agreement affecting the rights, titles, and interests herein conveyed, except as explicitly set forth herein.
Ambiguity and Uncertainty
All of chapter 11 of MSCD is devoted to “the ambiguity of the part versus the whole” – essentially, the many ways that a drafter can make mistakes when trying to discuss parts of a whole (i.e., selling some parts, but not others, or making sure you sell all parts, or…). The section includes an interesting case study of a Third Circuit case, showing how drafters can very easily confuse judges. The change below is an attempt to remedy such an ambiguity in the IPA. “Each” (MSCD 11.83) appears to be the best way to cover the intent of the authors here, but “all” would probably also work and be consistent with the rest of the section.
(a) any and alleach inventions and improvements (“Subject Matter”) disclosed therein;
Chapter 11 isn’t the only single-minded chapter of that sort. Chapter 8 is devoted entirely to practical and scholarly discussion of the many variants of “reasonable efforts”, Chapter 9 to “material”, Chapter 10 to “references to time”, and Chapter 18 to “amendments”. Each one will show you flaws with common language and how to improve it.
Chapter 7 is another, critical one – “Sources of Uncertainty in Contract Language”. Among the categories of uncertainty are lexical ambiguity, antecedent ambiguity, undue generality, and conflict. IPA mostly avoids these problems, but not always. For example, it uses “herein” throughout the agreement. Besides being a “here” word (discussed above) in many places it was unclear what the “herein” referred to – was it a specific section? the entire agreement? This is an example of the antecedent ambiguity Chapter 7 warns about. The same happens with the “promises” made in Sec. 2, which are referred to throughout the document, but never actually named or described in Sec. 2. A hacky solution would be to say “The Company promises” rather than the original “The Company agrees” (original language) or “The Company shall” (my language). A better solution might be to break up Sec. 2 into smaller sections and have one section that consists entirely of the “promises”, titled/named appropriately and then refered to by the rest of the document.
Structuring the document
MSCD has extensive discussion of how documents should be structured (Chapter 4). Because of the overall simplicity of this document, I have not changed much. However, it recommends providing headings for sections (MSCD 4.15-21). As with many of the things that seem nitpicky at first, attempting to apply MSCD’s rules can expose substantive problems. In this change, I drafted headings for each section, but my attempt to write a meaningful heading for Sec. 3 suggests that it is not well-organized, and could be usefully split up into smaller sections. (A common problem; I ran into it with MPL.)
1. Assignment of Applications, Inventions, and Patents.
2. Limits on Assertion of Patents.
3. Patent Details.
4. License for Enforcement.
The same chapter’s discussion of enumerated clauses (MSCD 4.28-4.37) is (for me) one of the weaker sections in MSCD, because it is not entirely clear how to consistently apply them. In this case I have split up the list of (a), (b), etc. in Sec. 1 by adding a colon and made formatting changes (not shown here) to make the formatting consistent with the next section. This consistency makes it more obvious that “therein” and “thereto” are used in subparts (a) and (c) but “the above applications” in (b) and (d) – a problem I have not yet fixed, but a good example of how better typography and structuring can lead to better understanding of the text. It also makes more obvious that it is unclear whether the defined term “Patents” includes sections (b) and (c) – a potentially significant ambiguity in the text that should probably be resolved.
including:
Defined Terms
MSCD’s chapter on Defined Terms covers a variety of topics, including location and structure of definitions. It also recommends against the common practice of redundantly defining singular and plural terms (like “‘Inventor’ or ‘Inventors’ means…”) on the sensible ground that the less redundant definition “wouldn’t confuse a reasonable reader”. Here the IPA follows the correct MSCD behavior, but checking MSCD’s rule led to a change fixing the capitalization of “inventor” in Sec. 4, likely an actual bug in the IPA.
Any sublicense granted by the Inventors under this section must be without threat or additional consideration; otherwise, the sublicense will be considered void ab initio. This license to the Inventors is not assignable, although the license shall pass to the heirs of an inventorInventor in the case that the inventorInventor is deceased, and the inventors,Inventors, individually or jointly, may appoint a representative who may act on their behalf in granting sublicenses under this section.
Other Considerations
It is important to note that there are a variety of things I haven’t done here. I haven’t, for example, touched much substantively – I haven’t analyzed the validity of the patent grants. MSCD will not help you with this; it is not a substitute for substantive knowledge of the legal field you’re drafting the agreement in.
I also haven’t touched some of the more complex drafting questions. For example, MSCD correctly points out that many “triplets” are redundant and reflect drafting that sounds pretty but is not legally precise. At the same time, without deep knowledge of the field, you often can’t winnow them down. So a careful MSCD reader will treat these as a warning flag and do more careful analysis. IPA has a few of these warning-flag triplets: “sell, assign, and transfer”, “successors, transferees, and assignees”, “right, title, and interest”. But it is out of the scope of this review to actually see if some of these words could be winnowed out.
Similarly, the book has an extensive discussion of definitions – how they should be used, where they should be placed. Because of the structure of the IPA, “Defensive Purpose” (a key concept) is structured as a definition. I suspect that a truly thorough review of the document would have restructured that (based in part on an MSCD-driven analysis) though I can’t say for sure.
Finally, this has just not been comprehensive. MSCD’s appendices have a sample edit, similar to this one, identifying 209 changes in a six page document. So you can really, really dig down if you want to, and I’m guessing Ken (if he reads this review) would have much more to say about it!
Conclusion
This review really just scratches the surface of what MSCD can do for a drafter, but I think it yields a more readable, more correct document. It has to be taken with a grain of salt in places, but overall, the conclusion of this review is simple: everyone who writes or negotiates contracts for a living should buy and read it. Even if you apply only 1% of it, your contracts will be better than they were before.
Syndicated 2013-10-07 00:05:15 from Luis Villa » Blog
