Failing to Tell the Story

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.

About the author

Ken Adams is the leading authority on how to say clearly whatever you want to say in a contract. He’s author of A Manual of Style for Contract Drafting, and he offers online and in-person training around the world. He’s also chief content officer of LegalSifter, Inc., a company that combines artificial intelligence and expertise to assist with review of contracts.