Re your comments document orientation. This is a very good point and one that I have given a bit of thought. Contracts do indeed consist of business data and should be treated as such. To create such data in Microsoft Word and keep it in Word documents is as criminal. But the problem is worse than that. Contracts are also business logic manifest in a completely useless format called human language. If you are interested you should check these links out: http://contracts.scheming.org/http://www.stefansen.dk/presentations/isola-contracts.pdf
> For example, lets say you need to store a bunch of contracts (as in your industry) in PDF/TIFF or whatever.
Contracts are not as unstructured as you would think. At least in my part of the insurance world, most of them are produced by a contract writing system of some kind. Think of it as assembling as a series of contract provisions, each having a valid set of choices to select. Use your auto policy as an example -
Yes there are other attributes captured, but you see the pattern. It's provisions and boilerplate. The use cases needing the imaged executed contract where the attribute/provision soup is not sufficient is uncommon.
The operational terms of the contract exist in some other system (and database) where it's consumable in some structured way.
It feels to me like where this is going to fall down is first contact with any business term that isn’t neatly covered by one of the form agreements. Not to say that this can’t be great for ordinary course arrangements that neatly fit within one of the defined buckets, but I’d be pretty wary (as either a business or a legal advisor) of any impulse to fit even a minimally bespoke deal into one of these templates.
Contracts exist in a weird state of counterpoise where they’re both supremely important (even the oft-maligned “boilerplate”) and totally inessential to the achievement of practical business objective. I’ve had clients sign contracts for nine-figure deals where no one has ever read the agreement after closing. But as soon as there’s a mismatch between the commercial expectations on either side, then every word matters.
And it’s just hard for me to understand how this is going to capture all the nuances of arrangements among sophisticated commercial parties. For instance, I saw on the site, several variations of alternative anti-assignment provisions. OK, so either the contact can or cannot be assigned. Simple enough. Does it also prohibit an assignment of the contract if the company is sold via a sale of all assets? (Should an ordinary course commercial contract really purport to dictate the form of a corporate-level transaction?) What about a pledge to secure debt? What about in an assignment for the benefit of creditors? What about an internal reorganization or transfer to an affiliate? What about a merger? What if the company issues new stock representing 19.99% ownership? 49%? 51%? And so on and so on ad nauseam.
Maybe these are all in fact selectable boxes and there’s language that addresses each of these fact patterns. But even aside from agreed language that, let’s assume, is good enough to implement the business understanding in each of these scenarios, these are weighty commercial decisions that require careful consideration.
Contracts are sort of like computer programs, read and executed by people -- by the parties; by constituencies within a corporate party; and sometimes by judges and juries -- instead of by CPUs.
Except that, unlike people: [EDITED FOR STYLE]
* CPUs don't come up with imaginative reasons why they supposedly needn't follow a clear, unambiguous program instruction.
* CPUs don't experience buyer's remorse and decide they like another program better.
* CPUs never have to be persuaded to comply.
EDIT: Still, there's much room for improvement in the way contracts are drafted; someday there may well be standardized, machine-parsable ways of expressing common contract concepts, so that readers aren't forced to struggle through the wordsmithing whims of J. Random Lawyer.
(Shameless plug: In that regard, see the Common Draft project that I've been working on, at http://www.CommonDraft.org. It's an organized compendium of contract term sheets and clause language, heavily annotated [and also very much an unfinished work-in-progress].) The long-term goals are (1) eventually to automate 80% of routine contract review work by programmatically comparing the preferred term sheets of Party A and Party B to generate a discussion list of the parties' points of disagreement; and (2) to provide an educational resource that will help people collaborate to do good things together.
There are plenty of areas where there is a standardised starting point for contracts - ISDA has already been mentioned but you also have LMA loan documentation in the financial space, standard/default articles of association for companies, various standardised construction contracts (eg NEC in the UK), standardised contracts (sometimes even written into legislation) for land purchases, etc - the point is you draft (to greater or lesser extent) on the basis of where you want to differ from the standardised contract. Creating standardised contracts in such a way that the commonly customised parts are machine readable data sounds like a very good thing to me.
The purpose of a contract isn’t to be efficient with paperwork or describe a high-level view of transactions. It’s a document that very granularly describes those transactions.
Any large organization has many people with the authority to spend money, and each one of those transactions will be supported by a contract.
I don't like clauses like this and forced arbitration clauses. But if you're selling a large software company you should be sophisticated enough to understand the contract, and not use a free term sheet without getting it reviewed.
How are the contracts expressed? The web page does not seem to provide any details on that part, which seems rather crucial. Are they written in some domain specific language?
We need a library of standard contract terms (so that every time you buy a thing you don't need to read a new contract, and to prevent shafting either side on the deals).
We also need those contracts to be much simpler. A single page of large font in language simple enough for a grade school graduate to understand what's supposed to happen.
A set of standard contracts would be great, but it would also be nice if there was a "why are these things in here and what do they all mean" document for each contract.
what use are contracts if buisnesses refuse to read them. Sure you as an employee might not but if you're running a company you really ought to read it on your key software. We're not talking about an email provider, its the key engine you're using. It's like if you didn't read the contract with the manfuacturer you hired to make your product...
reply