placeholder

/dev/lawyer

>> law, technology, and the space between

All content by Kyle E. Mitchell, who is not your lawyer.

You can subscribe via RSS/Atom or e-mail and browse other blogs.

Lexical Scope for Contractswandering ever closer to LISP

This post is part of a series, Common Form.

Following on from Contract Components

My definition of “Component” allowed me to change the results for any subdivision of a contract to facilitate reuse of generic contract parts without fear of structural conflict. Why limit component rules to specific subdivisions? Couldn’t we apply a general rule to all subdivisions of a document that give us the desired effects?

  1. Scope of Definitions. Each definition in this document applies only in:

    1. the Subdivision where the definition appears
    2. each Sibling of the Subdivision where the definition appears
    3. each Descendant of each Sibling of the Subdivision where the definition appears

    Where more than one definition of the same term applies in a Subdivision, the definition that applies in fewer Subdivisions overall takes precedence.

  2. Subdivision” means any organizational subdivision of these terms. The plural of Subdivision is “Subdivisions”.

  3. The “Parent” of a Subdivision is the Subdivision directly containing it, and if there is none, this document as a whole.

  4. A Subdivision is a “Descendant” of each Subdivision that contains it, directly or indirectly.

  5. A Subdivision is a “Sibling” of another Subdivision if they have the same Parent.

These rules give contracts lexical scope. The part of the terms where a definition applies, or its scope, depends on where that definition appears in the document. Scopes are coterminous with subdivisions of the terms, neatly represented as Common Forms. Very much as scopes of variables in many homoiconic programming languages like Scheme do.

In general, under this rule, definitions only flow down through the document, never up. That difference is most jarring in situations like:

  1. Purchase and Sale.
    1. Buyer hereby sells Blackacre to Seller.
    2. Seller agrees to pay $100 for Blackacre.
  2. Warranties.
    1. Blackacre” means the property at ….
    2. Buyer represents that Buyer has good title in Blackacre.

Under typical contract conventions, the definition of “Blackacre” would apply throughout. With lexical definition scope, the definition of “Blackacre” in 2.2 is “out of scope”, and therefore does not apply, in 1.1 and 1.2. That definition is in scope in 2.2, because 2.2 is a “Sibling” of 2.1, where the definition appears.

The interpretation rule clearly keeps definitions in component-like terms from causing problems above, in the subdivisions that incorporate them. Unlike my prior definition of Component, this rule handles conflicts between definitions in incorporating and incorporated subdivisions differently. Consider:

  1. Background. This is an agreement for licensing software with support.
  2. Business Days” means days other than Saturday, Sunday, and days on which banks in New York, New York are authorized or required by law to close.
  3. Billing. Licensee shall pay each bill within 30 Business Days of receipt.
  4. Support. [Written by someone else, as a component.]
    1. Business Days” means days other than Saturday, Sunday, and days on which banks in Hyderabad, India are authorized or required by law to close.
    2. Licensor shall respond to support request on Business Days.

Note that “Business Days” is defined both in 2 and in 4.1, and used in 3 and 4.2. Under the scope rules above, the definition in 2 would take precedence in 3, and the definition in 4.1 would take precedence in 4.2. It’s not that the definition in 2 doesn’t apply in 4.2. It’s that the definition nearby, in 4.1,overrides the definition further up, in 2.

Your thoughts and feedback are always welcome by e-mail.

back to topedit on GitHubrevision history