Friday, June 21, 2013

Legalese or Plain English? Either Way, TechCrunch has it Wrong

There was a post today on TechCrunch about a VC that uses a plain english term sheet, as if this were some earth-shattering innovation. Well, first, it isn't, and, secondly, TechCrunch seems to really miss the larger point: This term sheet is a summary of a larger, totally standard contract. In other words, the whole goal that TechCrunch seems to be excited about - a contract that is in plain english, hooray! - is false. This is a memorandum of understanding, a letter, a summary, that precedes the formal agreement itself. So, basically, this is a non-story.

However, it does lead to the more interesting question of contract drafting in general, and whether it is a better practice to use plain english or stick to the legalese. As with all things, I argue that it depends highly on context, and the intended audience for a contract.

For instance, when drafting a Terms of Service, or End User License Agreement, it is probably the right thing to draft so that a normal human being can understand what you are writing. However, if you think for a moment that I am going to draft a funding instrument or insurance policy in plain english, you need your head examined. If for no other reason - and there are many - this is because it is the language written on the contract that gets tested in court, and you want to have predictable outcomes when drafting contracts. This means you use language that has already been reviewed and tested by courts, even if it is cumbersome and bulky. So, even in the example of a TOS or EULA, when it comes to HIPAA compliance, I'm going to stick with the language I know won't get me in trouble.

A good analogy is to code: why don't engineers just write their code so it is really easy to understand? Well, to anyone who knows anything about coding, this question should appear somewhat clueless: programming is a functional activity. Code is written so that it works, first and foremost. Good code is often - and sometimes must be - easy to understand, but there is plenty good code out there that is very difficult to understand, even for very experienced programmers. Of course, it is always good practice to try to make your code easy to understand, but the reality is that function must dominate over lay-person readability.

The same is true for contracts: when a complex deal is memorialized, the documents about that deal will also necessarily be complex. The problem is that most people assume that because contracts are written in english, and that they understand english, that a contract must be faulty if it is not easy to understand. Well, this is a huge misconception.

In the end, the term sheet that TechCrunch has talked about is basically something like very good documentation, or comments that are in code. And that is great - we should all endeavor to document and explain our agreements much more thoroughly. However, as any software developer knows, writing good documentation is in no way a replacement for writing software that works, and writing a good term sheet is in no way a replacement for writing a bullet-proof contract.

No comments:

Post a Comment