Concepts

Plain text legal documents: a philosophy

Legal documents should be plain text files. Not Microsoft Word or PDF files.

We believe that if legal documents were written and maintained as text files, the law would be more accessible to the people it governs. Lawyers would work more quickly and intelligently for their clients. Legal standards and best practices would evolve more easily.

But the law and anything adjacent to it is stuck on Microsoft Word and PDFs.

Emailing around Microsoft Word documents may have made sense in 1999. And DocuSigning PDFs with squiggly pretend signatures may have made sense in 2009 when people needed the gentle suggestion that electronic signatures were legitimate. But today, those processes are outmoded and make it difficult for the legal world to take advantage of the information locked inside its documents.

The legal world can do this by taking a page from the practice of software development. Software development happens almost entirely in plain text. That choice, made decades ago, makes the process of software development efficient, powerful, and widely available.

Standardized tools

Plain text invites the use of existing concepts and tooling that have existed for years in the software world. Tools for:

The legal industry approximates many of these tools, poorly. These approximations are proprietary and limited by the requirement that they play well with Microsoft Word, an application that is notoriously difficult to interoperate with.

Indeed, Magistrate's own blueprints use Jinja2 and JSON Schema. These well-understood, open source tools allow developers to jump right in and create their own legal blueprints for their own use cases. This wouldn't be possible without a commitment to plain text as the medium for legal documents that people create with Magistrate.

Opinionated formatting & typography

Legal document creation in Microsoft Word invites mixing the concerns of substance with formatting. As any law firm associate will tell you, struggling with Microsoft Word's formatting capabilities takes up time, costs money, and distracts a lawyer from doing what they were hired to do: bringing their expertise to bear on the substance of the document.

The total mixture of substance with style makes it hard for non-lawyers or junior lawyers to understand what is important, and what is inconsequential. Do we use straight quotes or curly quotes? Are section titles bolded? How are sections numbered? These are inconsequential details that lawyers spend too much time on because there is no alternative.

Legal docs in plain text files allows for similar enforcement of best practices, for example from well-known books like Typography for Lawyers or the Manual of Style for Contract Drafting. It also allows for the application of custom stylesheets when its necessary to break out of best practices if, for example, there are court-imposed formatting rules.

Software developers might read this and be reminded of the debate over tabs vs. spaces, or where the curly brackets go when defining a function.

Software developers have largely solved this bikeshedding problem by developing a set of best practices and then enforcing them automatically during the development process. For example, the Python community developed a set of formatting standards (PEP8) and created black, the so-called uncompromising Python code formatter.

Not every Python developer likes the formatting choices prescribed by PEP8 or black, but they generally don't fight it. Because it doesn't matter.

Unfair bargaining

Formats like Microsoft Word and PDF contribute to injustice and unfair bargaining. If you think about your own experience, you may understand this to be true.

Think of the last time you received a DocuSign. It presents you with a PDF that you either sign or decline to sign. You have no ability to negotiate it or make any changes. If you have some leverage, you can ask for a "Microsoft Word copy" of the contract, which you can then edit with track changes. That is, assuming you have purchased a copy of Microsoft Word. It's a lot of friction, and it exacerbates unfair bargaining by making it technologically impossible by default for you to even propose changes in your favor.

Before computers, if you received a contract on paper, you could cross things out, write things in. You could negotiate. You no longer can negotiate as a matter of course. The format in which the contract is presented to you has a lot to do with it.

Legal documents can get pretty complex, but they're not rocket science. An untrained person could understand even a reasonably complex contract with a close reading and a little bit of persistence. Add in the operational difficulty of dealing with formats like Microsoft Word and PDF, and it discourages people from even trying.

With plain text, negotiation becomes more possible. Platforms for signing documents can enable negotiation more easily as a technological matter if the underlying document is in plain text. Negotiations then can become immediately about the substance of the document rather than finding the right file format.

A better future with plain text

Legal documents is a purposefully broad label. We do not only mean "instruments enforceable by courts of law."

Legal documents include the obvious: contracts. But they include a whole host of other documents, each with varying levels of enforceability in courts. Some examples:

Written consents of boards of directors
Insurance policies
Bylaws for corporations and for unincorporated associations
Legislation

What is so exciting about using plain text for legal documents is the opportunity it offers to standardize and open source the creation of legal work product using established tooling from the software world.

Imagine a world where folks could put legal document templates on GitHub-like platform and invite people to contribute. Consider the domain specific languages that could arise to automate the boring stuff out of the law and highlight the contentious stuff for human input and judgment.

Finally, a note on the relationship between computer source code and legal documents, especially in the new world of blockchain and DAOs. Legal documents and computer source code have many similarities. Recognizing the ways in which source code is similar to legal documents and, crucially, recognizing the ways in which they are not similar, will open exciting frontiers in the future of public and private law.

In our view, source code will not supplant legal documents entirely in the foreseeable future. Source code is a precise description of how a computer program should run. Legal documents are, in the final analysis, a description of human relationships. Human relationships are infinitely complex and for that reason it is not possible for a legal document to describe with complete coverage all the edge cases in any reasonably complex transaction between two humans. Human judgment is always needed in interpreting legal documents and it will be for the foreseeable future in any just system of government.