One of the basic principles of liquid law, is to make law more comprehensible, to make it readable, so that more of us can create with it the sort of agreements we want. To take the computer language analogy, we want to be able to move from machine code¹ to a higher level, more readable language like Python or Ruby.
While this is certainly not possible for all law (we can’t and don’t aim to reverse engineer existing legal precedent to make a comprehensive legal language), we can do this for specific domains, and we can make useful tools with this approach that capture the majority of use cases.
In order to do this, we want to create a language which is both legally robust, and easily comprehensible to the lay person. With this in mind, we can envisage a number of layers, from low level machine code, to the computing language of choice, and finally the domain specific legal language which we envisage as the core of a new form truly accessible legally binding agreements. However the user interface does not have to stop here.
On top of this domain specific legal language we can build a range of graphic interfaces, web sites and web applications, that can serve to create even more intuitive interfaces for users wishing to create their own legal agreements. These richer interfaces would allow a user to graphically draw an agreement, or interact with an interface rich in video and interactive media. A user would then have a choice of interfaces, and it is this choice which can lead to conflicts and issues – which representation is the actual legal agreement, the video, the web site, or the textual representation?
Certainly the existence of these multiple representations opens the door to potential inconsistencies and conflicts, but for the sake of useability and comprehension this is a cost that we believe is worth paying. It is not as if existing legal agreements are not open to various interpretations, why should this be more or less the case if we were to use video rather than text for the agreement? Indeed there is a good case to be made that the requirement for the legal expression to be implemented as functional code, could lead to a greater requirement for logical and therefore in a fundamental if not restricted sense, legal consistency. Legal bugs, to use the term, could be less common (a topic for another post).
In simple terms, the answer is surely that it is the textual form of the agreement, that should be “one that counts”. It can be printed out, and is more generally acceptable in a court of law. Creative Commons licenses have pioneered this approach – the license is a straight legal text, while the plain English, and the machine readable versions of the license are merely adjuncts. A case could be brought in which a user could claim that they agreed to the plain English version, and understood something different from the actual license, which is doubtless a main reason why this approach is so rare, but this is not an insurmountable problem.
It may be more work to create legal agreements with multiple representations, but this can be compensated by using organizational, and technical tools that allow new agreements to be s from previously worked out and clearly expressed components. It is a core premise of liquid law that this approach can revolutionize the cost for creating the greater majority of agreements that people use. Part of the legal savings that this approach delivers can be recycled to create greater clarity for the end user of the agreements.
Foot Notes
- It has been said that machine code is so unreadable that the United States Copyright Office cannot even identify whether a particular encoded program is an original work of authorship. – see Pamela Samuelson (Sep., 1984), CONTU Revisited: The Case against Copyright Protection for Computer Programs in Machine-Readable Form, 1984, Duke Law Journal, pp. 663–769, JSTOR 1372418