I recently posted this item discussing Lexicon, a tool for organizing and checking defined terms. Lexicon’s website contains a page discussing “The Seven Deadly Sins of Defined Terms.” Among the sins described is the following:
Overlapping Definitions–When one Defined Term is contained within another, confusion can arise. For example, if (1) “Company,” (2) “Company Promissory Note,” (3) “Guarantee,” and (4) “Promissory Note Guarantee” are all defined, is a subsequent reference to the Company Promissory Note Guarantee a reference to (1) and (4), or does it refer to (2) and (3), or something else altogether?
I haven’t encountered this previously, and I suspect that it’s more of a theoretical issue than a real-world problem. What do you think?
This is an interesting topic that we do not give a lot of thought to, at least I never did. I see how many of the same or similar words or phrases can come up more than once. It is confusing and needs to be ironed out and cleared up as much as possible. Thank you
I’d say this is a real problem. This grammar construct has fueled the irreconcilable ambiguity over whether keyword advertising is a trademark “use in commerce.” The statute uses the phrase “use in commerce” and has statutory definitions for both “use in commerce” and “commerce”–with the statutory construction reaching different conclusions depending on which statutory definition is invoked. Eric.
I wrote the web page in question, and I included overlapping definitions as a “deadly sin” (excuse the hyperbole) because overlaps became an issue during the design of Lexicon. In testing, we ran into overlapping phrases from time to time, and they caused problems. “This phrase could be linked to any of these three defined terms; which should we pick?” Confusing, to say the least. Whereas a human will be able to resolve most overlaps easily based on context, software is not that clever. Dealing with that issue made me acutely aware of the ambiguity that could arise from such constructions.
When the terms are used without initial caps (as suggested in Eric’s example), the likelihood of confusion or disagreement increases significantly. On a related note, I think it can be risky to use common words as defined terms (e.g., “commerce” in Eric’s example, or “corporation”, or “we” (which I see defined regularly in 10-Ks), especially if initial caps aren’t used. Doing so requires vigilance to ensure that the defined word is used consistently in its sense as a defined term, and not just as a plain old word.
Ken:
The place I see it as a real problem is one like this. The contract defines the terms “Software,” “Licensor,” and “Licensor Software.”
Then, in text, it uses the term “Licensor’s Software.”
Now, was that a slip, where the term “Licensor Software” was meant? Or is this something else?
This risk only arises where you have defined terms that are composed of other defined terms.
It’s not right up there at the top of my list of contract drafting problems, but if you are just worried about contract drafting issues related to definitions, it’s one to keep in mind.
Chris
I can see that it might be a problem in the examples people have already given.
Just to give the other side of the argument, a term should usually be defined using the most accurate and concise phrase that applies, to maintain readability. If “Licensor Software” is the best way to describe what was being defined, I would use the term in any case because, as separate terms, “Licensor” and “Software” would not be placed together and the risk of confusion is therefore very low.
Licensor’s Software would surely be something different to Licensor Software.
I agree that using small caps makes things worse. In Eric’s example, if it was defined as “Use In Commerce” (i.e. with “In” also capitalised) there would be no problem.
Art
This happens routinely in software development as well. Lexicon is basically a contract debugging tool.
Not to make a molehill out of a mountain, but the solution seems obvious to me. Simply make any overlapping definition (in this case, the “Company Promissory Note Guarantee”) a defined term. You thereby preserve clarity of description without ambiguity.
A variant of this problem is something that might be called false parallelism, which I’ve seen. For instance, in one contract, I found definitions for Licensor, Licensee, Software, and Licensor Software — but none for “Licensee Software,” even though that term was used in the contract as well.