Legal engineering

You might have heard about the recent kerfuffle over the Facebook terms of service. If you didn’t, this brief summary from Rocketboom will get you up to speed.

Mostly, it was about whether or not you could revoke their license to use and distribute your material by deleting your account. Their argument was that they couldn’t practically delete material from their backups and, if you’d sent things to someone else, they weren’t willing to delete that material if you deleted your account. These aren’t unreasonable concerns, but their approach was to require perpetual licenses for all material and all uses. The change was far broader than needed to achieve those goals – more nuance was required in their terms. After lots of wailing and gnashing of teeth, Facebook withdrew their initial set of changes, then, a few days ago, released a re-written set of terms that appear to be much less contentious. In particular, they explicitly state ‘People should own their information’. Hear, hear.

But, that’s not the point of this post. I’m interested in the fact that they’ve chosen to release two documents; one a high-level statement of principles, the other a statement of user rights and responsibilities. Compared to the old terms, which were legalistic and dense, these documents are quite readable. This, I applaud.

It’s not entirely clear, however, which one of them represents the real terms and conditions. Which is legally binding? If there’s a conflict, which takes priority? If they’re not binding, then where are the real terms of service? Most likely, the statement of user rights and responsibilities is meant to be the binding terms and conditions.

Generally, I really like the idea of providing a human-readable license alongside a legally rigorous version, because no one really ever reads terms of service, even though they should, and at least part of the reason is that they’re generally impenetrable. If the relationship between the two is clear and there are no incongruities, then great! Of course, language often isn’t that precise, and you can see how problems might arise.

A great example of this approach is in the Creative Commons license. When they were launched, much was said about licenses being written ‘legal code’ in that we have trained engineers and machines to read and use them, being lawyers and courts respectively. Let’s run with this, and see how a few concepts from software can be applied.

Software design are just common ways of thinking and solving particular problems that crop up again and again in various contexts. They might be abstract, and pertain to the way code is written (such as the decorator and singleton patterns), or they might be more concrete features that are applied such as, for example, common interface widgets like menus, scroll bars, and drop down boxes. In some form, design patterns probably appear in everything that people design. However, in software, these patterns are explicitly sought for, studied and re-applied. I’m not aware of this being a common practice in law, but I would expect the benefits of clarity, scalability, and re-usability that this brings to software engineering would be really useful in legal engineering.

Like software, legal systems can become horribly complex. In software, a major means of reducing this complexity is to employ modularity – problems are defeated by dividing and conquering. Where possible, software consists not of a single monolith of tightly coupled code, but of hierarchically organized components that interact cohesively. Benefits of this approach are a reduction in complexity, re-usability and portability of parts, and conceptual tools for analyzing and engineering models of complex systems. Various coding paradigms exist, the best known of which is object oriented programming; aspect-oriented programming and programming by contract are other paradigms that facilitate modularity. In law, there’s obviously some modularity (law is broken down into individual acts and codes, which are broken into articles, sections, clauses and so forth). Unlike well-engineered software, however, these components are strictly hierarchical and cannot be taken out of context.

Wrappers are an example of a pattern that allows software engineers to insulate themselves from the idiosyncracies of a messy component, a third-party driver, or a piece of hardware. Basically, an engineer writes a piece of code that knows all about how to handle the mess, then presents a nice clean interface that other engineers can work with without having to learn about the details of the mess themselves. Imagine if, instead of having to read all of the messy details of a complex license, you could just inquire, through a simple, well-defined interface, if certain conditions were true.

Before any of this makes sense, it’s important to consider the difference between informal language (that which we use every day), and formal language, where the meaning of all symbols and elements is defined within a particular lexicon, much as all software languages are. That is, legal writing needs to follow formal rules. One obvious problem here is that is required to be able to address pretty much any conceivable situation; this is effectively impossible to do with formal language, as you quickly end up with self-referentiality (which then allows self-contradiction a la the Epimenides paradox). If you don’t believe me, read Hofstadter’s ‘Gödel, Escher, Bach’ first, then argue with me. To overcome this problem, then, we need to have some way of insulating the parts that can be modeled formally (effectively, the parts that are most clear and logic) from the parts that cannot (effectively, everything that’s subjective in some way). The wrapper pattern mentioned above allows for this – tokens can be used to represent subjective elements; these tokens are treated as simple propositions within the formal part of the system, then spat out at the end. Incidentally, this is how propositional logic, and almost all written reasoning works. However, lest I make this sound easy, I should mention that while, hypothetically, this is possible, it’s unclear whether or not the resulting system of formal law and subjective tokens are workable.

If, hypothetically, enough of the mechanics of law could be formalized in such a way that it can be treated computationally, all sorts of things become possible. Firstly, there no longer needs be a legal priesthood whose job it is to parse the complexities of legal argument and language and explain this to the masses – this can be by software, and learned systematically. Imagine if legal code could be translated through some filter into a human-readable form. Imagine if you could query, using a well-defined interface whether a body of law has certain properties, or if certain activities are true. Imagine if law was extensible and modular. Imagine if the legal system was simple, accessible, and thin enough that legal disputes could be resolved in a matter of seconds rather than years, through software interfaces rather than the courts.

I don’t know which parts of this are actually plausible, or if it’s even possible. However, it t would make damned interesting research project for someone. I wonder if someone’s already tried..