Imagine if lawyers from different firms collaborated on standard documentation for everyday legal transactions, e.g. loan agreements, wills, conveyancing etc. What if it was all freely available to their clients too? We call this open-source contracts (“OSC“).
This is part 2 of a 4 part series of posts exploring whether the legal industry could and / or should adopt an open-source approach to legal documentation.
Part 2 explores whether and to what extent the open-source software paradigm could be applied to legal contracts.
Check out the full series: part 1; part 2; part 3; and part 4.
Is legal drafting like writing code?
Yes and no
Similarities
Drafting contracts and writing code involve many similar disciplines, constructs, and themes in terms of how a contract is put together versus how the code is written:
Differences
However, there are many interrelated differences regarding the nature of legal language (and human language in general) and code:
1. Definition
Coding languages are formally defined. Each language has a strict mathematical definition for their syntax and a formal mathematical definition for their semantics. Human languages do not; rather they evolved through millennia and lack formal and unambiguous definition.
For this reason, coding languages are precise whereas human languages are imprecise.
2. Grammar
Coding languages need a “context-free grammar“; there should be only one way to interpret a statement and this interpretation is independent of the “tokens” (i.e. words) in the statement. Human languages are “context-sensitive” languages; the meaning of one word depends on the other words in the sentence as well as its relative placement to other words. A computer reading a program can only have one interpretation whereas a human reading a contract can have multiple interpretations of the same drafting.
This is one reason natural language processing is hard for machines.
3. Strict
Coding languages adhere to strict rules regarding the uses of symbols and punctuation marks, e.g. (), {}, [], ;, “, ‘ , <, >, =, +, *, -, =, /, and # to name a few. All have strictly defined uses in various coding languages.
Unlike human language, there’s no room to repurpose these symbols beyond their intended use. If you don’t use them as intended your code means nothing to a computer and “breaks”, i.e. won’t run or stops running mid-flow.
With human languages, you can take liberties with grammar, punctuation, and word meaning yet remain understood. You might be thought an idiot if you do it wrong, but you’ll be understood to a greater or lesser extent!
Code is less forgiving.
4. Ambiguity
Computer languages are unambiguous and have bounded and precisely defined vagueness (such that no instance of vagueness can ever contribute to ambiguity).
As a result, every computer program has exactly zero or one meaning. If a program has zero meanings, it has an error in it. If it has one meaning, it’s a valid program you can run. If it has two… well, it doesn’t. Either you misunderstood the documentation, or the documentation is erroneous. No program ever has two meanings. You’d be hard-pressed to find any human language sentence of reasonable complexity that doesn’t have more than one possible meaning!
By contrast, all human languages abound with ambiguity and arbitrary vagueness.
5. Complexity
Computer languages are simple. The most complex computer language barely comes close to the structural complexity of the simplest full-fledged human languages. In terms of syntax, some of them are completely regular; most are context-free; only a few have a very limited degree of context sensitivity. In terms of semantics, they are extremely restricted.
Human languages are crazily complex and laced with nuance.
Conclusion
Coding languages (and human languages generally) are vastly different beasts in terms of their nature. However, the means by which code is written and contracts drafted are more similar than not.
In many ways, the same processes, constructs, and concepts are shared between the disciplines of drafting and coding.
As a result, we don’t think it’s a crazy idea to think about how the OSS paradigm could apply to contract drafting, i.e. OSC.
What would OSC look like?
OSC might borrow the following features and concepts from the world of software development:
1. Collaboration
Law firms collaborating to create and curate versions of their products (e.g. contracts) and making them publicly available (not necessarily for free), including to clients and other law firms. Collaboration would comprise the design, development, bug-fixing, and testing of legal contracts over time as new legal cases challenges or market moods shape prevailing views on how to draft a particular contract or clause.
2. Innovation
The pooling of collective knowledge could lead to the sharing of innovative drafting and / or solutions to cutting-edge legal problems. If 1000s of lawyers are pooling knowledge to fine-tune the best drafting it is potentially more likely for innovative (or at least balanced) new contract paradigms to evolve, perhaps even hybrid contracts containing code (e.g. to execute an executory obligation based on the occurrence or absence of an extraneous fact) and traditional drafting.
3. Tech
Law firms would use cloud-based tools to curate versions of their products, e.g. something like GitHub, which is a prominent tool for version control and collaboration on OSS allowing different developers to work on the same codebase by enabling downloading / uploading of code, versioning, merging of versions and discussion. See part 3 of this series for more detail regarding this point.
4. Parameterisation
The most common clauses in contracts might become more modular and in some cases coalesce into parametrisable obligations whereby users (clients or law firms) have well-defined tramlines within which to negotiate changes to such clauses, in turn streamlining negotiations. This might work best with executable obligations, perhaps in structured finance documentation where the operation of a clause can be determined by the presence or absence of an extraneous fact (e.g. an agreed price for a commodity on an agreed market).
5. Productisation
Collaboration could drive productisation through the homogenisation of contracts via increasing the standardisation of products applicable to each industry sector / market tier. In turn, this could allow clients and law firms to handle greater volumes of transactions quicker and faster than before.
6. Adoption
Like OSS, making OSC products freely (or cheaply) and publicly available can create widespread adoption and a loyal community, in turn driving further innovation and user stickiness.
7. Legal Requirements
Without commercial constraints, contributors to the OSC ecosystem can be focussed on satisfying the legal requirements in contracts rather than the commercial requirements of individual clients or the law firm’s business drivers, perhaps improving the legal quality of the documents (versus improving the commercial concerns alone) thereby reducing legal errors by removing commercial cost and time pressures.
Conclusion
The above sounds great for clients. Better collaboration and freely / publicly available legal documents mean time saved via reduced negotiations and money saved as greater quantities of high-quality legal documentation enter the public domain.
What’s left for the law firms who charge huge fees for the generation of such contracts on a bespoke / premium basis?
Rather a lot we’d argue. Perhaps controversially we’d also argue that law firms are already using open source contracts, they just don’t know it yet!
Next time
In the next article, we’ll discuss whether and to what extent law firms are already engaged with open source contracts. Jump to the next article in this series by clicking part 3.
Check out the full series: part 1; part 2; part 3; and part 4.