Blogs

The Devil's in the Definitions

By Larry Schroepfer posted 04-23-2015 11:46

  

One of the big differences between how most non-lawyers read a contract, and how most experienced transactional lawyers read a contract, has to do with the definitions.

In my experience, most non-lawyers take the definitions for granted.  They assume that they intuitively know what defined terms mean based on everyday usage of those terms.  So they plunge right into the agreement's operative sections without spending any real time on the definitions.

Most experienced transaction attorneys, however, know that the defined terms are often "where it's at" in understanding an agreement, and that they need to parse and to fully understand the definition structure before going to the operative provisions.  And the more complicated an agreement is, the more important this exercise becomes.

 Here's a few thoughts about definitions and their usage in an agreement:

  • The fundamental premise about definitions is that any defined term can mean whatever the drafter wants it to mean, which may not necessarily mean what you'd think it means based on the common understanding of the term.  To take this to an extreme, instead of defining the term as "Confidential Information", I could define it as "Celery", and there would be no legal or operative difference between the two terms (it would, of course, be weird to say that "Recipient shall not disclose any of Discloser's Celery or use its Celery for any other purpose other than to perform under this Agreement", but that's beside the point).
  • The crucial corollary of the above is that a skillful drafter can often bury "inconvenient" restrictions and limitations in the definitions.  In other words, if there are provisions to which the other party would likely object if those provisions are made explicit, they can be incorporated as part of the definition where they are less likely to stand out. 
  • For example, I remember negotiating an agreement where the client was going to receive government funding to further develop technology that it had already created.  The client was concerned that the funding agency could obtain rights to anything developed under the agreement as a "Subject Invention".  However, we were able to include a clause in the definition saying that that "Subject Inventions" would not include any improvements, changes, modifications or developments relating to the client's "Background Technology" (as separately defined). 
  • Another example is a development agreement under which the developer was concerned to carefully limit the scope of rights to its knowhow and technology that the other party (the party funding the development work) would obtain, even if that knowhow and technology were developed under the Agreement.  In that case, we defined "Developed Technology" to be "the Deliverables that are specified in the Statement of Work to be developed and delivered to the other party hereunder".  So the idea is that the funding party would not get any rights to any knowhow or technology, even if developed under the Agreement, unless that knowhow and technology is specifically called out as a Deliverable in the SOW document. 
  • Definitions get particularly tricky if there are "nested" definitions -- i.e., definitions within definitions.  An example would be something like, "Licensed Product means any Software Product that infringes a Valid Claim of any Licensed Patent, or which uses or incorporates any Licensor Technology".  There are five defined terms here: "Software Product", "Valid Claim", "Licensed Patent", "Licensor Technology" and "Technology" (the definition of "Licensor Technology" would incorporate the separate definition of "Technology").  It's crucial that the reviewer fully understand all of the limitations and restrictions of all five definitions to fully understand what the "Licensed Product" is.
  • For this reason, whenever I get an agreement to review that's fairly complicated, the very first thing I do is diagram the definition structure, particularly if there are extensive nested definitions.  I'll start by writing a synopsis of the highest level definition ("Licensed Product"), and then bullet underneath it a synopsis of the nested definitions.  If there are definitions that are down two levels (like "Technology"), I'll separately bullet "Technology" under the "Licensed Technology" synopsis.
  • If an agreement is fairly short and simple, it's OK to define terms "in-line" (i.e., define the term the first time it's used in the agreement), rather than to include a separate Definitions section or exhibit.  A good example would be a nondisclosure agreement -- it's sufficiently short, and there are a limited number of defined terms, so it's easy to find them if the reader needs to refer back to the definition.
  • With most agreements, however, there should be a separate Definitions section or exhibit.  That way the reader knows where to turn if he or she needs to refer back to the definition.  If there are any in-line definitions in addition to those in the Definitions section, I like the practice of including an "Index of Definitions", so that all of the definitions are found or at least referenced in one place.

Starting with the definitions won't mean that you're going like all of the limitations and restrictions they contain.  But at least you're dealing with the devil you know.

0 comments
41 views

Permalink