IME, where keywords and terms of art are used in contracts it tends to be because they’re being copied directly from a controlling opinion in that jurisdiction. Otherwise, as you say, the words being used are mostly ascribed their lay meaning because nobody can predict what magic words a court will expect when construing the document.
To continue the programming analogy, though, any decent programming language will include the ability to add comments, which don’t affect how the code actually runs, but which can be used to make it easier for a human reader to understand. And any decent program, in turn, will make extensive use of this commenting feature. Is anything analogous in widespread use for Legalese?
The bulk of program code doesn’t consist of keywords, either–in fact, only a very small percentage of it does, and many of them mean essentially the same thing, or at least one of the same things, that they do in ordinary language. I suspect the most common confusion related to keywords does not arise from, say, unfamiliar Latin terms, but from those which hold a plain meaning, but carry additional significance or specificity in legalese. “Unclean hands”, for example, seems pretty clear–your hands are dirty, i.e., you’re guilty of something. That doesn’t, however, make it clear to the layperson that the defense is claiming you shouldn’t get what you’re asking for because you were acting unethically and/or in bad faith.
Legalese also tends to hold onto archaic meanings and expressions, largely, I think, to maintain backward compatibility. Consider an expression you may see in parliamentary proceedings; an item is ordered to “lie on the table”. It means the item is being put aside, probably permanently, and will no longer be discussed. In modern common idiom, on the other hand, putting something on the table means you’re showing it to others and inviting action or discussion on it. Anyone not familiar enough with parliamentary procedure to understand “tabling” an issue would be confused.
However, none of that is the main point of the analogy; it’s just one of the ways in which legalese resembles a programming language, and not necessarily the main reason for confusion. Most laypeople can’t read software code, either, and it’s not because of the keywords; it’s because they don’t understand the logic behind it. It requires a level of detail and precision that simply isn’t present in ordinary speech.
To expand on that, let me offer some examples.
“John Q. Badguy, hereafter referred to as the DEFENDANT…”
You’ve just defined a constant, using plain English, so that you can plug Mr. Badguy into standard functions. This isn’t something people generally do in conversation, so it may seem like unnecessary fluff or misdirection to them.
“…Courts, moreover, ‘cannot rewrite a contract to force a bargain that the parties never made.’ Denaxas v. Sandstone Court of Bellevue, L.L.C., 63 P.3d 125, 132-33 (Wash. 2003)”
You’ve invoked an exception-handling function, which returned a string for your message. A layperson will likely understand the string, but not the function call, because they don’t know how to look up the citation.
“(B) if (and only if) the transferor receives stock other than nonqualified preferred stock—
(i) subsection (b) shall apply to such transferor; and…”
if((stockReceived == true) AND ((stockType != "nonqualified") AND (stockType != "preferred")){
subsectionB(transferor);
}
Conditional branching and Boolean logic. The legalese should be pretty readable to laypeople, compared to the software interpretation, but they’ll probably have to look up some stock terms, and “if (and only if)” may cause some stumbling, because it’s not a common construction in ordinary speech.
The point of all this is that legalese and software code are written the way they are for the same reason: to perform an algorithmic procedure without breaking down. The procedures in question may be as different as calculating a trajectory and transferring a piece of real estate, but they both need to be as unambiguous as possible. If you have to write a thousand lines of text/code to handle an obscure scenario that only comes up once every few years, it may look like a huge amount of useless babble to a layperson, but it’s really there to prevent a disastrous crash/expensive litigation.
Well, sort of. It does use named constants (e.g. ‘The XYZ Holding Companies Limited, known hereafter as “the Tenant”’) to make things easier to read. Unlike most computer languages, it can also have statements that modify previous statements, so large bits of logic can be slightly separated from the various details. I suppose good Legalese style will note those following statements (“Except as noted below in Section 3.B.2.,”), and since those clauses may not be strictly necessary, this is probably a kind of commenting.
But the main issue with Legalese is not the logic of any statement , but rather the incredible amounts of error-handling and defining of terms. I think nearly anyone can understand any particular clause in the above example, it’s the number of different conditions attached to the main action that is confusing. What people want is a less-detailed summary that gives the big picture.
But the problem is that Legalese is only invoked when there’s a dispute about what the contract says. And when there’s a dispute, the exact details matter, so summaries don’t help. (Not sure how to fit that into the programming analogy)
You’ve just inadvertently given a classic example of the ambiguity inherent in English as a source code: “to table a document” has diametrically opposed meanings in American and Commonwealth parliamentary proceedings.
You’ve given the US meaning - to put the matter aside for an indefinite time. However, in Commonwealth parliamentary procedure, “to table a proposal” means to deal with it right away - it comes from the practical act of putting a document on the clerk’s table, to be entered in the record for immediate debate.
Churchill in his war memoirs recounts an episode where a high-ranking joint US-UK committee spent a long time wrangling about whether or not to proceed with a proposal. Turned out the Brits and the Yanks both wanted to go ahead right away with the proposal, but when the Brits suggested tabling it (ie proceed immediately, in Brit speak) the Yanks were upset, because they wanted it to go ahead and thought the Brits were suggesting it be delayed indefinitely.
Since that’s the source code lawyers have to work with, is it any wonder we try to nail down the meaning of words and the terms of the contract as firmly as possible? 
Yes, the Senate Procedural Interpreted Language forked from the Parliamentary Interpreted Scripting Utility Project a couple hundred versions back.
But the same is true of a programming language. When it’s invoked, it’s to run a program on a machine, which is going to ignore the comments. The purpose of comments isn’t to make the code run better; it’s to make it easier for the programmers and anyone they deal with (in this case, the lawyers and their clients) to understand and maintain the code. Like you said, sometimes the client requests changes to the boilerplate-- To do that, they have to have some understanding of what the boilerplate means.
Chronos, the answer to your question is no not really in my experience. You do see headings, and a clause saying “headings are used for convenience only and shall have no effect on the meaning of this agreement”.
But let’s not go over the top here: legalese mostly just isn’t that hard to understand for a person with reasonable comprehension skills and a degree of persistence. It’s just dense and unfriendly. Mostly, people who can’t read it either can’t be bothered, or are the type of person who couldn’t read any complex thing. They are the same people who wouldn’t be able to read a technical manual, or follow instructions for assembling something from Ikea.
Others have correctly noted that legalese is a specialized language that decreases ambiguity.
My question goes in the opposite direction as the OP: why don’t lawyers have a more compact notation for legal documents, like mathematicians and programmers do?
Even a trivial mathematical expression translated to English would expand many-fold, if expressed unambiguously. Likewise for a simple computer program. Therefore, they each have specialized notation that is both compact and unambiguous.
An actual legal notation would have numerous advantages:
- It would be far more readable to even semi-trained people. True, untrained people would not be able to read it–but they can’t read standard legalese, either.
- It could be automatically checked for syntax errors, logic holes, redundancy, etc.
- It could be automatically translated to “perfect” standard legalese if necessary.
- It could be “optimized”; transformations applied that simplify the document but maintain the exact meaning.
- A contract could be more easily built with pre-made components that are verified to be “known good”.
- Once the facts of a case are established, they could be encoded into the same notation, and a case could be resolved automatically.
And so on. So why not?
Because legal documents are (mostly) public record. What’s the point in having a public record in a language that requires specialized training to read?
Lawyers do use a sort of shorthand in intra-office communications (and increasingly in inter-office e-mail); the word plaintiff is often represented by pi, the words defendant or defense by delta.
I’m inclined to agree. I have no legal training, but I have found that if I break legal documents down into small pieces and chase down all the jumps (footnotes, citations, and so forth), I can generally understand them, at least enough to satisfy my curiosity. I wouldn’t presume to offer anyone legal advice based on my understanding, though. I’m not that confident.
I see several problems with consistently adding lay explanations to legal documents:
-
The simplified explanation will inevitably fail to cover everything the legalese does, meaning that it may be misleading in some situations.
-
There’s a risk that the explanations will be interpreted as binding, so you would have to put at least a little extra legalese around them to prevent it, as you described. You could probably handle this by putting the comments in a consistent format–say in sidebars, like in a textbook–and adding a blanket disclaimer at the beginning of the document.
-
Time. I’m not just talking about the fact that you’d be burning a lawyer’s (expensive) billable hours to add the comments. Many legal documents are written under a time crunch. Court filings often face tight deadlines, as do contracts. For that matter, many judges have a very heavy caseload. The people qualified to write the explanations may simply not have time to do so.
As I mentioned, an unambiguous notation could be compiled back to standard legalese if necessary. It would be vastly more cumbersome, and in reality no more readable to the layman than a well-designed specialized language, but it would be at least theoretically accessible.
I’m certainly not talking about shorthand here. I don’t know precisely what it would look like, but it would probably in part involve set theory. For instance, the first sentence of the document could look something like this:
define confidential_information := non_public_objects ∩ all_information ∩ objects_obtained_under_agreement
Actually, as stated, the first sentence is this:
define confidential_information := non_public_objects ∩ (all_information ∪ terms_of_agreement) ∩ objects_obtained_under_agreement
However, one can see that including terms_of_agreement is redundant, since it is a subset of all_information.
That’s just one possibility, of course. Other forms are possible. The point is that I’m not talking about shortening words or phrases here.
The issue with that is that “confidential information” has different meanings in different legal contexts.
That’s why it was defined as a local constant in terms of sets which *are * the same across different contexts. Another contract may have an entirely different definition.
Of course, you would need some predefined sets to build the local sets from. But that’s true anyway. The original paragraph doesn’t define “non-public information”, so either it was defined earlier in the document, or there is a standard legal interpretation of the term.
Some legal documents even include recursion.
Their motive is always the same: To do what they can to protect the client. This isn’t really about lawyers. This is about how parties to a business transaction are likely to disagree and come into conflict with each other. They hire their lawyers to protect them as much as they can.
There’s also another justification for opaque language: Parties often can’t come to an agreement if the language is specific. Make the language opaque, and both parties can enter into a transaction they consider mutually beneficial. Chances are that it won’t become an issue. This doesn’t happen because the lawyers want it to happen, but because in business, the parties always want to end up with a mutually beneficial transaction.