I’m in the habit of dividing the task of contract drafting into the what-to-say part and the how-to-say-it part. That’s a little too simple, as the how-to-say-it part can unexpectedly affect the what-to-say part if you’re not careful.
But it’s also a little too simple because the how-to-say-it part itself is made up of two parts. There’s command of the building blocks of contract language—in other words, what I cover in A Manual of Style for Contract Drafting. But there’s another part, what I call “telling the story.”
You might have figured out all the deal points, and you might have a grasp of the building blocks of contract language, but in a transaction of any complexity you still have to articulate the deal points and weave them together to create the limited and stylized narrative that is required to express a transaction.
That’s nothing to be taken for granted. Obviously, I have a decent command of the building blocks of contract language. (Hey, I wrote the book!) But anyone willing to pore over MSCD can match my command of the building blocks—it’s not rocket science. Telling the story is another matter, as it requires a writerly instinct. That’s something few of us have, and it’s tough to acquire.
I mention this because reader Jeffrey Aber pointed me to the recent case of Nuance Communications, Inc. v. International Business Machines Corp., No. 16-CV-5173 (KMK), 2019 WL 2006180, at *1 (S.D.N.Y. May 7, 2019) (PDF here). It involves a drastic failure to tell the story in a coherent way.
IBM and Nuance entered into a software license agreement under which Nuance licensed a technology called DeepQA. The dispute was over Nuance’s rights to updates. IBM argued that the contract limits Nuance’s license to DeepQA updates developed by IBM’s subdivision IBM Research Group (IBMRG). By contrast, Nuance argued that the contract also entitled it to DeepQA updates developed outside IBMRG, including those developed by IBM Software, another IBM subdivision that became involved with developing DeepQA after the date of the contract between IBM and Nuance.
At issue was the definition of “Licensed IBM Background Software.” In the contract it was defined as follow:
all Software that exists as of the Effective Date in all available formats . . . that is owned by, or that has been developed or licensed by the IBM Research Group, including Tools, and that is listed on Exhibit A, including any modifications, updates, error corrections, bug fixes, diagnostic and/or testing tools, that are JDBC complaint, and other changes, if available (“Modifications”), and if such Modifications are not contractually prohibited under a Third Party Agreement, and such Modifications are available, will be timely provided to Nuance; and where the Modifications continue to meet the scope contemplated in Article 2.1 regarding the licensing of DeepQA under this Agreement, as of the Effective Date and thereafter for a [defined] period . . . , and additional Software as agreed by the parties, provided to Nuance by IBM under the Agreement (collectively “Updates”) . . . .
As a piece of writing, it’s a mess. (IBM admitted that it was “a bit garbled.” You don’t say.) With the phrase “will be timely provided,” this definition includes an obligation. In other words, the definition is “stuffed,” and as a result it veers off track. And what is the semicolon doing there? That’s a sign of bollixed structure. Given the chaos upstream, the “and additional Software” clause seems awkwardly tacked on.
In their litigation, the parties argued over the meaning of including, and whether the semicolon before “and where” was more significant than the comma before “and additionally”. That’s a sign that both sides were floundering to make sense of the language at issue. Normally, I’m able to look at disputed contract language and come up with a succinct diagnosis. Here, I had to throw up my hands—it doesn’t come close to telling a coherent story.
This failure can’t be blamed on one person, or one party. After all, both sides signed off on this language. But we shouldn’t be surprised. It’s safe to assume that among those who work with contracts, those with a writerly instinct are vastly outnumbered by those without. That’s one reason why I’d like to see contract drafting largely in the hands of contract-drafting specialists. That’s something I discussed in this 2017 post.
If you think I’ve missed something, by all means say so.
8 thoughts on “Failing to Tell the Story”
Also, shorter sentences work better for contracts just like they do for prose. That’s my go-to eject button for a cumbersome set of embedded or encrusted clauses, whether definitions, provisos, or obligations.
Not just shorter sentences, but shorter paragraphs — and one issue / decision to a paragraph, to make it easier for the other side’s reviewer to scan the document.
Just like cross-examination!
If you’re not careful, you’re going to sound like one of those “All you have to do is use shorter sentences!” people :-)
It’s an application of the law I call “Occam’s Safety Razor:” when you don’t know what the answer is, start with something that almost certainly can’t hurt.
I haven’t read the whole case yet, but can tell by reading the quoted language that it was drafted by IBM; it’s their house style. Nuance was my client for several years, and I know their drafting style, and it was nothing like this. But here’s the kicker: when I was haunting the Nuance hallways (including during the year this contract was drafted, though I swear I had nothing to do with it) I noticed that most of the lawyers had copies of MSCD in their offices (First edition, a collector’s item!). Seems Ken had been there and given them The Talk. When I asked some of them why they didn’t write contracts in accordance with MSCD, they said words to the effect of “ah, we know how to write contracts!” More than that I am ethically constrained not to say.
At a more general level, though, to paraphrase a famous poem, the hand that holds the pen is the hand that rules the contract. It’s hard to get a point properly expressed against the interest of the party doing the drafting, no matter how bad the drafting is, as this case seems to demonstrate.
What a story! Yes, I did a seminar for Nuance, but I’m not so naive as to be shocked that my teachings aren’t manifest in the contract at issue. There could be all sorts of reasons for that, one of them being the delusional shrug that signals, “We know better than Adams.”
And yes, the drafter sets the tone, but it shouldn’t be hard to spot gibberish. This case demonstrates the price you might pay for being lax.
It’s possible to overstate the distinction between a contract’s what-to-say parts (the deal points) and its how-to-say-it parts (the contract language), but I don’t agree that the latter breaks down into a ‘building blocks’ (MSCD) part and a ‘storytelling’ or ‘stylized narrative’ part.
The problem in the Nuance case was that the contract didn’t make clear whether IBM was taking on an obligation to license to Nuance more DeepQA updates than IBMRG developed. The failure wasn’t of storytelling, but of stating the limit of a particular obligation IBM was taking on:
‘IBM shall supply Nuance with DeepQA updates developed by any IBM subdivision’; or
‘IBM shall supply Nuance with DeepQA updates that IBMRG develops. [Optional: ‘IBM is not required to supply Nuance with DeepQA updates that non-IBMRG subdivisions of IBM develop’.]
MSCD is right that narratives belongs in recitals. Why have I this feeling of being more royal than the king?