Idea: an open platform for generating custom legal contracts(openideas.ideon.co)
openideas.ideon.co
Idea: an open platform for generating custom legal contracts
http://openideas.ideon.co/2011/cure-for-jurisdyslexia-discovered?
12 comments
The complexity has a lot to do with how a contract is structured.
A good lawyer avoids internal cross-references. They're like the GOTO of contracts. On the other hand, lawyers treat "sections" the way programmers treat "methods" – each section is supposed serve a discrete function, and can be leveraged via cross-references to avoid repetition. So you have a tension between DRYing up the contract language and increasing inter-clause dependancies.
Contract assembly technology is pretty useless in my practice, since I'm most often reacting to the other side's agreement form. It's easy to implement basic Madlib-style contract templates, but in the end it's even easier to just edit a Word or text file. After all, as soon as the other side gets your draft, they make changes, and all your precious metadata goes pretty much out the window.
I'm more interested in tools that help me make smart decisions based on best practices, and what options/risks I ought to consider based on a completely arbitrary contract input.
A good lawyer avoids internal cross-references. They're like the GOTO of contracts. On the other hand, lawyers treat "sections" the way programmers treat "methods" – each section is supposed serve a discrete function, and can be leveraged via cross-references to avoid repetition. So you have a tension between DRYing up the contract language and increasing inter-clause dependancies.
Contract assembly technology is pretty useless in my practice, since I'm most often reacting to the other side's agreement form. It's easy to implement basic Madlib-style contract templates, but in the end it's even easier to just edit a Word or text file. After all, as soon as the other side gets your draft, they make changes, and all your precious metadata goes pretty much out the window.
I'm more interested in tools that help me make smart decisions based on best practices, and what options/risks I ought to consider based on a completely arbitrary contract input.
Or it might be as easy as writing a compiler. These things are hard to prejudge.
Compiler writing is easy? No. (I've built compilers for large subsets of C and Java, as well as my own languages)
Lord help you if you try to write a perfectly conforming compiler for C++ (has it ever been done?), and the U.S. legal system is at least an order of magnitude more complex than that.
Lord help you if you try to write a perfectly conforming compiler for C++ (has it ever been done?), and the U.S. legal system is at least an order of magnitude more complex than that.
To make that task even more complicated, people don't agree on what many of the rules are. Your "law compiler" would have to take in input and have output that's maybe this, or more likely this, but it could also be this...
Compiler writing isn't the easiest thing in the world by any stretch, but it's something that we manage to achieve all the time, unlike the mythical "program to do my programming" we are so quick to imagine.
Docracy (http://docracy.com) is a repository of crowd-sourced legal documents, designed for scenarios such as this. As others mention, it is very difficult to reliably construct working contracts from a cookbook of clauses. A sounder approach is to have a variety of complete templates, along with some community discussion and social proof of their worth.
One thing to remember is that contracts depend on trust. Not only between you and the party signing, But also between you and your lawyer.
To succeed, the service would have to be trustworthy enough that I wouldn't feel the need to have a lawyer "double-check" the contract first. You could argue that just having a lawyer proofread the document would be far less costly though I guess.
It will take a lot of trust to get a service to the levels of trust required for some contracts. One mistake and you could be screwed.
To succeed, the service would have to be trustworthy enough that I wouldn't feel the need to have a lawyer "double-check" the contract first. You could argue that just having a lawyer proofread the document would be far less costly though I guess.
It will take a lot of trust to get a service to the levels of trust required for some contracts. One mistake and you could be screwed.
Lawyers sort of have this stuff already. They tend to be fill-in-the-blank templates originally built around WordPerfect.
But the law is, dare I mention this, heinously complex. Why? Because the world is heinously complex. Law has to deal with everything and everyone; its subject domains cover all human activity.
One of the reasons lawyers stick to lawyerly gobbledigook is risk management. Various phrases and terms are embedded in lawyer-drafted documents because their meaning has been tested in court. They're known forms of words with known legal consequences.
If you turn law into a write-compile process (I once proposed this[1] and I was not the first), you run a series of new risks. The most dangerous being: which document is the "real" contract? Even if you include language saying "the generated document", too bad, the court might not agree.
Remember: every software system grows progressively more complex as it a) grows the boundaries of its domain coverage to remedy impedance mismatches and b) discovers strange and nasty corner cases.
Well the law is analogous, with the difference that the law has been hacked on for (in common law countries) for nearly a thousand years, including some very large patches.
It's complex because it's essentially complex.
[1] http://clubtroppo.com.au/2007/08/25/programming-in-legal/
But the law is, dare I mention this, heinously complex. Why? Because the world is heinously complex. Law has to deal with everything and everyone; its subject domains cover all human activity.
One of the reasons lawyers stick to lawyerly gobbledigook is risk management. Various phrases and terms are embedded in lawyer-drafted documents because their meaning has been tested in court. They're known forms of words with known legal consequences.
If you turn law into a write-compile process (I once proposed this[1] and I was not the first), you run a series of new risks. The most dangerous being: which document is the "real" contract? Even if you include language saying "the generated document", too bad, the court might not agree.
Remember: every software system grows progressively more complex as it a) grows the boundaries of its domain coverage to remedy impedance mismatches and b) discovers strange and nasty corner cases.
Well the law is analogous, with the difference that the law has been hacked on for (in common law countries) for nearly a thousand years, including some very large patches.
It's complex because it's essentially complex.
[1] http://clubtroppo.com.au/2007/08/25/programming-in-legal/
I've put many hundreds of hours into making my forms simple and to the point. I've considered dropping them into a public github repo, under a simple attribution license. I'd really like to have other people fork them and make pull requests for corrections/improvements.
Is there any interest in that?
Is there any interest in that?
A company called Microsystems used to have a product named D3: http://www.microsystems.com/pdfs/d3-success-stories.pdf
Unfortunately, they had to discontinue the product, in part due to a patent dispute Microsoft lost about how it uses XML in Word, if I remember properly.
A solution like this needs to be flexible and allow the logic to be diverted by humans, but is a brilliant thing for real estate and other industries that are full of common books of contracts and rules.
Unfortunately, they had to discontinue the product, in part due to a patent dispute Microsoft lost about how it uses XML in Word, if I remember properly.
A solution like this needs to be flexible and allow the logic to be diverted by humans, but is a brilliant thing for real estate and other industries that are full of common books of contracts and rules.
We're doing this right now at http://www.iubenda.com
and Privacy Policies are our starting point. Anyway, I can assure you that's far from being simple :)
Here you can see a sneak peek of the upcoming new version: http://www.iubenda.com/blog/2011/10/12/a-brand-new-version-s... :)
Not sure how far off the mark this is, but Paperlex[1] could be interesting to check out.
1. https://paperlex.com/
1. https://paperlex.com/
I second https://paperlex.com. I was at GA/NYC a week or two back when they publicly demoed for the first time. It was very impressive. Think markdown for legal documents. The most interesting thing about it, imho, was not the structured templating but the counter party signature mechanics. All done online and driven by the data in the document.
As somebody who knows and have done work for the Paperlex guys, I can genuinely say that they have a really interesting product, and the guys running the biz are bright. I think they're going to do well.
As far as legal contracts and forms for start-ups go, Orrick offers a "start-up tool kit": http://www.orrick.com/practices/corporate/emergingCompanies/...
I'm not sure if their license allows you to modify and redistribute.
I'm not sure if their license allows you to modify and redistribute.
I had similar idea, most of the time I get cookie-cutter contracts and having a service that would provide additional value as vault would be useful
to which Paperlex seems to answer almost exactly... good work
What about http://contractual.ly ?
making a contract is fine but how can you enforce effectivly against someone who breaches the contract, imho a effective system would be able to produce initial drafts of litigation documents based on the contractual clauses breached, otherwise people will just break the contracts willy-nilly and you'll be forced to enter litigation yourself, or take your computer generated documents to a lawyer
We discussed the concept in depth, and it might be more complex than you realize. Templates are one thing, but you probably can't "mixin" different clauses without generating legalese based on inter-clause dependencies...