GitHub for Lawyers (2013)
jduclos.com
jduclos.com
I mean, I'd be super happy if lawyering eventually looks like this:
import stock_sale
import confidentiality
import lockup
import governing_law
import states
import conflicts
export build(
stock_sale({
company: "Corp Inc.",
purchaser: "Jane Employee",
shares: 10000
}),
confidentiality(),
lockup(120 /* days */),
governing_law(states.CA),
// If two legal terms conflict, the latter takes precedence
conflicts.LATTER_WINS
)
But don't discount a secondary complexity – that of the contextual analysis and pure judgment inherent to legal practice, for which the human mind has a mysteriously unsurpassed capacity.
Super long term it could also be interesting if you could provide a fill in the blanks mask for clients that generates your contracts (a simple workflow where they fill in some details like names, corp, state etc. and a "what do you want")
Management can be difficult: Each 'module' needs a maintainer, someone responsible for keeping it updated, fixing problems, finding ways to integrate new concepts and requirements, etc. Based on what I know of law firms, finding attorneys with the time and attention for that can be difficult.
I've worked with in house and outside counsel on a variety of matters. The meter makes a difference in some things, it the individual attorney or lead attorney made a much bigger one.
It works well for lots of things. After a 30 minute consultation with a new client, the attorney can estimate the documents which will be required and can give a reasonably close estimate of the total cost. It also encourages the attorneys to still track time on a per-task basis and actually look for ways to improve.
Unfortunately for one attorney I know, the bankruptcy court still requires hourly billing, so he can only do value-based billing on the stuff he can get resolved outside of court.
It will reduce lawyering (around those documents) to litigating when things go wrong, and negotiating custom agreements when two parties have different preferences as to standard terms to include and neither is in a position to do a "take it or leave it".
"ROSS has joined the ranks of law firm BakerHostetler, which employs about 50 human lawyers just in its bankruptcy practice. The AI machine, powered by IBM’s Watson technology, will serve as a legal researcher for the firm. It will be responsible for sifting through thousands of legal documents to bolster the firm’s cases. These legal researcher jobs are typically filled by fresh-out-of-school lawyers early on in their careers."
Today's model of contracting is fire-and-regret: spec out as much as you can of the next five or ten years, and when the world changes, litigate.
That's not very agile. Hart and Holstrom won the 2016 Nobel in Economics for pointing out the futility of the idea of a complete contract. http://www.economist.com/blogs/freeexchange/2016/10/science-...
What's the alternative? Hirschman remarked that your voice sounds loudest when you are closest to exit. https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty
What if we treated contracts as an iterated stream instead of an immutable invariant? What if every contract had a maximum term of one year, one month, one day? Power imbalances might be reduced precisely because nobody's locked in: it's a lot easier to break up when you're just dating. After the marriage you might let yourself go.
Software is eating law, but "law is code" is only the first step. Just as the historic transition from proprietary to opensource informs ideas like "Github for law", the historic transition from waterfall to agile will find its analog in the legal and business domains by changing the way we develop and deploy contracts, ultimately driving changes in economic relations.
Think about how "no-contract" phone plans have made the telco market more competitive, to the benefit of the consumer.
Think about how agile development means less software project failure, and less software project failure means less litigation between client and outsourced development vendor.
That's just one example of how litigation might be reduced. If better tools and languages mean that we can better transform our intent into specification, we might be forced to be clearer about what we actually do and don't agree on, we might be more honest in our dealings, there might be an actual "meeting of minds", and when things don't turn out the way we expect, rather than blaming the other party, which seems dysfunctional, we embrace change together, and agree to consciously work on the relationship, to improve the next iteration of the contract … which is due to be revised and renewed anyway, next month, not next decade.
An example usage: http://www.commondraft.org/#ConfKExpress
(I'm not sure how the reference is meant to work because I'm pretty sure commondraft.org has been edited since I saw it some years ago; maybe it's meant to copy whole sections and then include the specific details in a page like the one linked above?)
Note that the CC license mentioned in the header isn't actually useful except to lawyers: it contains the noncommercial restriction with separate special permission for most uses by licensed attorneys (looks intended to prevent non-attorneys from actually using anything there in transactions).
I think Ethereum Smart Contracts are a good first step. It is independent of the blockchain concept though.
Not a markup language: a full-blown strongly typed specification language with first-class functions, that supports formal verification / static analysis / model checking.
Those ideas, rooted in computer science, are what will set the next generation of legal drafting apart from traditional work.
Of course the language will be compilable to both natural languages and "smart contract" languages like Ethereum.
I justify these claims and work through your example in detail here: https://medium.com/@Legalese/code-is-law-is-code-4492c864f33...
Other thinkers, like Primavera de Filippi, have commented on "from code is law to law is code": http://firstmonday.org/ojs/index.php/fm/article/view/7113/56...
An archive of prior art is available at https://legalese.com/v1.0/page/past
We're working to build an opensource language called L4 with these properties. If you know, or want to learn, declarative programming (Haskell), dependent types (Agda, Idris), theorem proving (Coq), model checking (CTL*), rule systems (Prolog), modal logic, CCS, CSP, etc etc, join us! Computational thinking required, legal experience a bonus but not really needed. (evil laughter)
Live updating of document section numbers/names and references back to them. Lots of named clauses in legal docs.
Workflow and electronic signatures.
Support for rendering as word docs or PDF files.
Check out Contract Express from Thomson Reuters (http://contractexpress.com) for the establishment's instantiation of something that approximates the features you describe.
The problem with it is, as others have said, that you are fighting an industry. The whole model is built around 6 minute units and the work is passed down to junior lawyers in order to make it as profitable as possible. There's a little bit of pushback from a company on occasion, but most pay as having your lawyer do it is, in effect, a form of insurance. You can always sue the law firm if it all goes wrong.
The better way to look at doing something like this would be to turn the legal industry on its head and make a law firm that's tech-enabled from the ground up. Most of the incumbents are now using tech (think Dentons etc) but none have been built with tech in mind. You could then massively undercut the market and have far more efficient working practices which would make you the go-to.
I actually gave a TEDx talk on all this stuff as I found the industry to be extremely frustrating and small-minded when it came to entrepreneurial activity.
The notion is far older than that.
I assume if my google-fu were better, I could find references to "RCS for lawyers" or "SCCS for lawyers" though, that were decades old.