I am both a transactional (contracts) attorney and a software developer. I've observered a number of fundamental parallels between contract drafting and coding. I can see how for certain "boilerplate" documents, computer-generated document assembly could produce decent results. But I honestly don't think that (human) lawyers can be eliminated, for several important reasons. First, consider how laws come about in the first place. It's an often messy political process with a lot of disagreement and compromises. What ends up passing might have deliberate ambiguities that purposely don't create certainty in a number of fringe cases. Second, most laws are either "over-inclusive" or "under-inclusive," meaning that the text can't possibly enumerate every situation, so there has to be interpretation around the edges. Third, some aspects of law involve subjective (not objective) standards and rely on such things as "intent," "reasonableness," "community standards," and "equity." These involve very human judgment on the part of a judge or jury and vary according to time, place, culture, ethics, community, etc. Although some cases can be resolved with mathematical efficiency, the legal process is usually inextricably intertwined with humanity and all of its subjective flaws, and as long as it's human beings writing the laws and humans applying interpretations and judgments, it will be a messy, emotional, occassionally illogical process.
That's exactly what I wanted to comment. The project frankly seems quite naive. At first, I thought it was a joke project. Only to realise, reading the comments, that it was a serious one.
I think the idea that laws are strict rules that are enforced in a robot-like fashion is a common misconception, specially in engineering circles. That's not true in civil law and certainly not true in common law. There are very simple and straightforward cases that can be thought more or less like that, but almost all criminal cases and many civil cases too are very much a game of convincing other people and not satisfying a set of rules. Jury equity is a thing, technically you can acquit someone by not making any efforts into convincing the jury that your client didn't break the law.
The law does not have the last say, humans do. Loopholes are just loopholes as much as the court considers them to be valid.
Yes laws can’t be implemented in a straightforward and neutral way. That’s not a benefit of laws or something we need to preserve. Exactly the opposite.
The fact the process is sitting on a case for YEARS because they can't decide how to interpret the facts, or which laws apply, or what they mean, or even simply due to the procedure being enormously inefficient for everyone involved, in fact usually means that whether you are found guilty or not in the end... you lose.
And humans can always have the last say. Computers don’t take that away from anyone. Having computable law doesn't mean 100% of it is computed by dry algorithms.
The goal of the justice system is not to be efficient or fast, it is to be just. It is a last resort for complicated cases that can't be easily settled between the parties. You don't want to have every single dispute going through the justice system. That sounds like a dystopian authoritarian future. You want the people in society to self organize and settle their matter privately as much as possible.
It is very much a benefit that it's interpretative and slow. We want it to reflect the culture and people's common sense. We want it to be as fail proof as possible (even if it take ages to come up with all the evidence and arguments). And fail proof here is not to interpret the law in the most pedantic of ways, but in the way that is the most just. The reason for lawyers and courts are exactly the edge cases that are difficult to agree upon.
And when we look at the actual status of the smart contracts, we realize how far actual programming is from their own stated goals... They call the incidents "hacks" although we simply see incomplete contracts being used the way they were written, in some edge case.
That gets to the heart of the matter. I have studied computer engineering and law as well. Statements like "Verilog allows programmers to draft circuits, Legalese's L4 will allow programmers to express law" demonstrate naivety to the real challenge. The authors should take a closer look at the disillusionment that has arisen after fifty years of rule-based knowledge representation and inference.
Consider also the disillusionment that a significant portion of the population feels when confronted with the nearly 1000 years of rule based knowledge representation that is common law.
Maybe a good law would be that if you can't be arsed to write the law in a formal language, or can't figure out how, then it shouldn't be a law in the first place :)
Human language, and therefore laws and court decisions written in human language, work because members of society share an enormous amount of tacit and background knowledge and share similar value standards based on their cultural history. The fact that all this information can be assumed and does not have to be explicitly specified is what enables us to communicate efficiently in the first place. If you had to specify the actual knowledge content in order to fully understand facts and draw computer-aided conclusions, the effort to write or read these texts would be almost infinite. The idea of writing laws and contracts in a "programming language" thus misses (once more) the real problem. And beyond that works like those of Gödel or Wittgenstein showed other limits of formal systems long ago.
The limits of formal systems are nowhere near being approached by law, which is generally pretty simple but written in obtuse language or full of exceptions that exist purely because of the fact that its very hard to change laws. Legal communication is precisely the opposite of efficient. That being said, some types of law are obviously less amenable to being described in formal language (like laws concerning murder or situations involving complicated human - human interaction). But that is absolutely not true for the average contract , which constitutes most of the legal industry's revenues and time. In that case the only problem is that laws are pointlessly complex. As another example, we'd all be a lot better off if taxes were formulated as a program.
Laws are neither complete nor free of contradictions, and they don't have to. They are the result of a consensus among members of society that has grown over centuries. Democracy is significantly based on trust, transparency and comprehensibility. Legislation is subject to the permanent challenge of finding a balance between regulatory density and manageability. And even if it were socially feasible to rewrite all existing laws, to formalize them, and to massively increase the density of rules: the set of rules will always remain discrete, and it is a naïve assumption to want to fully capture the continuity of human action with a discrete set of rules; there will always remain an unspecified residue that requires human judgment. Striving for a perfect system fails merely because there is no universally accepted definition of a perfect system; and societies in which an attempt was made to realize the utopia of a perfect system were usually totalitarian or became totalitarian in a short time.
You mean natural languages. Formal languages (of which programming code and math are examples) are also human languages, but more well defined and usually designed by few (opposed to emerged from usage by many).
Roughly the same way I feel about HIPPA certification. Except that there is an additional interaction of building codes with zoning laws that leads to inflated housing prices in the US. Also, if you want to know if the house was built to code, you have to inspect it yourself, or at least be on site frequently enough to keep the trash from being stashed in the dead space.
There is of course a separation between safety and standards that is hard for laws and codes to grasp. The separation between intention and results is one of the reasons why you want these things explicitly defined as part of a formal specification for a law, it makes it possible to determine whether it is having the desired effect, and if it is not it could .e.g trigger a clause removing the code from being in effect. Rent controls would be a perfect example for this, though the whole point of my argument in my top level response is that trying to measure whether rent control is effective is the hard part (every serious study of rent controls shows that they are not).
These caveats make sense. I think that the role of computing and automation in law will be similar to their role in many other fields where the new technology does not necessarily eliminate humans completely, but instead increases their productivity by broadening the scope of their work, eliminating the bulk of repetitive and time consuming activities and allowing them to focus their efforts on areas that require nuance and judgement.
An interesting aspect of law-related automation concerns cases that could "be resolved with mathematical efficiency", but for whatever unfortunate reason end up slipping through the cracks in enforcement. Unequal, unpredictable and discretionary enforcement is often source of corruption and inequity, so filling those gaps would be welcome.
I'm not sure it always both "increases their productivity by broadening the scope of their work" and "allow[s] them to focus their efforts on areas that require nuance and judgement." It might increase productivity, but it could actually decrease critical thought. For example I've met some (disclaimer: some, not all) accountants who have become so reliant on software that they've essentially become data entry personnel and haven't nurtured the ability to think strategically about how or why to do certain things in light of the ever-changing tax code. It's easier to answer a software prompt. This isn't to say it has to be this way, and I agree that freeing up time doing mundane things should allow greater focus on the difficult and more important things. But often times it promotes a "good enough" mentality that enables higher volume, more competitive prices, more free time, or some combination of all three. So for every professional who is now able to do their work better, there are also probably some whose inability was disguised by the fact that they were able to do much of their job without a full understanding of the intricacies. This is especially dangerous in law, because a judge isn't going to care if you were spoon-fed language that "looked good" without fully understanding the overall legal context involved. It's often said that in law school, the most important thing you learn is how to "think like a lawyer." While that might be exaggerated a bit, it underscores the importance of critical thought and why it's a "practice." Automation is good if used as a tool to assist that process, but there are definite downsides if it's allowed to diminish ongoing competent understanding of a rapidly changing landscape. Or worse, if people without a legal background rely on it, thinking that they are getting the right "advice" which in some cases is very difficult to give even for seasoned professionals and is certainly not an exact science.
In practice, separating the subjective/objective elements is harder than it seems at first glance (and often impossible). The ideal, "perfect" contract would reflect the parties' intent with complete accuracy and would be clearly and fully interpreted by a judge/jury the exact same way. In reality, Party A and Party B want to "get the deal done." In many of the larger tech contracts I handle, the actual persons negotiating (sometimes even dedicated "contracts managers") are many steps removed from the stakeholders. Sometimes, it's a whole separate onboarding company. But even if it's the CEOs in the room, and they know fairly clearly what they want to put in a Statement of Work, they usually don't often consider (or want to think about) all of the intracies of the thousand ways something might go wrong. And standardized MSAs often fall very short (and sometimes lead to absurd results or contradictions); they are far from one size fits all and can't really be standardized to a menu of options either. 99% of what I do is dealing with retained background IP, warranties, indemnification, and liability limits. What is ultimately agreed upon is not usually something that can be determined with algorithmic certainty, nor would it matter, because the both parties would have to agree to use the same algorithm. In reality, it depends upon the particular type, severity, and likelihood of the risk to each party, each party's risk aversion, relative bargaining power, and -- much more than one might expect -- the entrenched corporate culture. A lot of the "art" in negotiating is presenting something to the other side that they can "sell" to their own superiors to get the deal done. And, very, very frequently, there's something irrational about it. For example, someone might not budge on narrowing an indemnification clause, but might bend on a blanket liability limit that would weaken it to practically nothing. Also, sometimes you might let something slide, because given the current state of the law with regard to how such a clause might be interpreted, you'd feel confortable enough that it would be interpreted in your favor -- i.e., in your risk assesment, you're considering how human beings (judge/jury) would interpret it. I've heard arguments before about how humans built laws and also built bridges, therefore laws can be reduced to scientific/mathematical/computational constructs. But unlike bridges, laws are based on this concept of "jurisprudence" which involves a foundation not built on mathematics, but instead built on ethics, morality, and philosophy. They're the thread of society. To fully "computerize" law, you'd have to do the same to society and humanity itself.
> In practice, separating the subjective/objective elements is harder than it seems at first glance (and often impossible).
Because, and this is where law just messes with my brain, the field deals as much in the NORMATIVE as it does in the objective and subjective. in my limited understanding...I'm left feeling like the normative is treated as objective by those in the field, but looks subjective to those outside of it.
It's the concept of "no code software development" applied to law, and it'll have the same problems. Edge cases by the million.
I wouldn't trust a computer to be my doctor, and I wouldn't trust one to be my lawyer either. As assistants to my doctor and lawyer, sure, but to replace them? Never.
Basically it’s good at solving trivial between parties that would probably member have bothered to sue each other. Anything else will probably be more expensive.
This legalese reminds me of UML. The only truly comprehensive way to capture the essence of a program is to write the program.
> I honestly don't think that (human) lawyers can be eliminated
That sounds very plausible. But do you think that human lawyers might gradually become a profession of people whose job partly involves interfacing with a software implementation of (large) parts of the legal code? And do you think there is any hope for defining (large) parts of the legal code in a formal language with well-defined semantics?
The challenge is that there are often many choices to make; the choices often benefit one party over the other; and either the choices themselves or the possible ramifications of those choices are not well understood by the parties. No two (separate groups of) parties are identical, and to an extent, no two projects are identical. So there's no single "right" answer that can be defined that works in every case, and it very often comes down to bargaining power and subjective risk aversion. I think there's more room for standardized or even automated contract provisions for less complicated transactions, but there are still some dangers. For example, a lot of real estate purchase agreements have been standardized by various state real estate associations that publish forms with various check-boxes for choices. The real estate agents in this case would be the ones "whose job partly involves interfacing with" software (or in this example, paper forms with physical checkboxes in many cases). From experience (I did real estate litigation for a few years), I can say that this didn't always work out so well... because the agents and the parties have to both understand the meaning of what they're choosing and the potential impact of those choices, and that requires an understanding of the law which is complex and not static. Relying on the form is nowhere near enough. This difficulty is vastly greater in areas of the law that are shifting more rapidly, like IP.
This is like how some people think philosophy is beautiful and pure logic and boils down to modus ponens but a lot of philosophy is making emotional and intuitive arguments for each proposition.
This is exactly like the "how can I use static types when I talk to other untyped things".
Computational law does not nor should it mean limiting ourself to purely objective concepts and automatically-resolvable disputes. We can still introduce as abstract parameters all the fuzzy humanistic things we want. This just forces us to separate those from the "boring parts", which will make everything more productive. This is a lot like how with fancy dependent types you can pass around proofs of undecidable/non-computable things -- "undecidable" and "subjective" are equally bad at run-time.
Done right, right, this is also good for fairness because it's exactly to the extent the objective and subjective stuff is all mixed together that "the party with the most expensive lawyers wins". All the drudgery keeps everyone but the rich out.
-------
All that said, there are still immense challenges to pulling this off. Doctors and lawyers are insanely protected classes in this country --- the last, most powerful guilds --- and everything is designed against this. In "physical small repeatable goods" capitalism, well you can always try to compete end-to-end to the final consumer and slowly eck out market. But court cases and ex lawyer judges make for relatively-rare, high-risk proving ground, and foxes guarding the hen-house!
Also, I am skeptical of this beginning with contracts / private sector and not law itself / governments. The way we write programs today is like a Gustafson's law vs Amdahl's law situation in which rather than reducing complexity/mental drudgery using machines, we simply fill up our expanded capacity with more --- from hand-calculating rocket trajectories to debugging garbage bloated software stacks. If as increased corporate profits went to longer EULAs and other paperwork, this could unleash a torrent of non-sense orders of magnitude greater: please sign these 50 MiBs!
You are taking this page too literally - the fonts are telling - it is starup-talk! There is a serious endeavour underneath - but at this stage they prefer to advertise the fun side of their project. I am sure they have well internalized critique like yours - because it is kind of obvious - and when they write "Without spending time or money on lawyers" - they don't mean it in an absolute sense - it is just that maybe in some cases you can generate a legal document by yourself, but in enough cases you'll need 10 times less lawyer help.
Lots of coffee. Started coding in the 90s and put it aside for a while to go to law school and then did litigation full time for a few years; then transitioned to a dev and eventually management of Dev/QA in a software company; then after the 2009 recession I formed a company for which I do all the dev for as well as went back to practicing law (almost exclusively in the IP transactional context). Split my time about 50/50. I'd never be able to do it if I were still doing litigation and going to trial; fortunately contract drafting/review/negotiation is a lot more sane/flexible regarding scheduling, and in both cases I have an understanding boss (me). But I could definitely use a vacation. :)
I don't believe the project has the goal of eliminating lawyers in the world. The goal, I think, is to produce semi customized contracts from modular and parameterized components without lawyers. Lawyers today build up a cache of legal documents that they stingily dole out to clients who pay. Most often these documents are poorly written, often being copied from older documents passed down to them from older wiza... I mean lawyers, and then extended primarily by slapping on provisions and enumerations as they come up or are thought of.
If instead we had a standard library of contract components that could be composed in verifiably compatible ways, that would be a huge achievement. I think that's what legalese is doing.
If you are intrigued by the idea that law can and will be represented as computer code / data, here are a few link to go deeper :
* British national act as a logic program (1982): the paper that is the based of most current effort in this domain https://www.researchgate.net/publication/234805335_The_Briti...
* Standford codex LSP initiative that try to standarize the format in which legal rule will be encoded https://law.stanford.edu/publications/developing-a-legal-spe... (as far as I know the initiative is still going, don't hesitate to contact oliver goodenough if you want to get involved)
One position I've heard is that cultural concepts that are used in legislation or contracts ("reasonable effort", "reasonably foreseeable", "undue risk") may always be assessed subjectively by humans, but that the logical structure of rules and conditions ("any of the following", "none of the following", "two or more of the following") may not be.
There are lots of drafting disputes about things where someone wrote something like
> a and b or c
leading lawyers to argue about whether this should be read as ((a and b) or c) or (a and (b or c)).
There's no reason that this kind of ambiguity should have been permitted to exist in the first place.
I think my understanding of this is related to my understanding of Lojban, which tries to avoid all syntactic ambiguities but explicitly says that it's a non-goal to avoid ambiguities related to the cultural meaning of words and concepts. Like if you say something is "medieval" or "fun" or "convenient" or "beautiful" or "fair" or "postmodern", Lojban doesn't try to make the truth-conditions for your statement objective with regard to what these concepts do or don't refer to. But to the extent that that's agreed between two people, they should then agree on what a particular sentence using these concepts means or doesn't mean.
Though I do envision that when people use better tools for avoiding parsing ambiguities in legal texts, they will still argue (and there will be many legal philosophers insisting) that they should still be permitted to argue that something was still a drafting error, because the (only permitted) interpretation under the drafting formalism is manifestly unfair or unreasonable and could not have captured their true intention.
I feel like this argument is akin to saying that the measurement ruler will never take off because medieval worksites use "soft" local measurements. I think the long-term view, in my opinion, is that of course contracts will be clearly delineated with definite terms. We may still need juries to determine facts and application of these contracts to facts, but we should not have to try to understand the intent of the contracting parties- that's what the contract is.
I firmly believe that it will be. However it won't be anytime soon because this entails a transition similar to going from rule by king to rule by laws.
The law is (nowdays) is backed by writing, and since I think that computing is a next step in the evolution of writing (along with printing press) one day---likely in dozens of generations (hundreds of years)---the law will be backed by computing.
All these technologies change the nature of a human's consiouness; it will take hundreds of years. Look at Walter Ong's work for better made arguments along these lines https://en.wikipedia.org/wiki/Walter_J._Ong
+1 Law is human-to-human agreement about a lot of vague soft stuff. Code APIs are computer-computer agreement.
Some exceptions to the above are:
1. Financial contracts (see ISDA derivatives).
They're written with a big "human" document upfront and then there's a "notification addendum" attached to each use of that contract.
2. Master Sales Agreements (MSAs):
The first MSA is a human-to-human agreement. Everything after that is order-forms. And negotiating the MSA requirements is very very human (risk, trust, effort, cost, benefit & promises). Order forms are pricing decisions that can be "automated" (especially around annual renewals if within budget without red flags).
As do all laws. You have a point about contracts though, assuming we admit contracts between non-moral parties to actually be a legally enforceable thing.
If your would-be law/contract/??? can't get both sides in front of a court, one ought to disregard its terms.
For folks who happen to be unreasonably interested in this stuff: there are research engineer positions open at the Centre for Computational Law at Singapore Management University where the bulk of the R&D is happening, in partnership between Legalese and the university.
TL;DR: Move to a tropical island, get paid to write open-source software, and explore the arguments being made in this thread in way more detail than you dreamed possible. DM me on Twitter, @mengwong
I had a discussion with my boss not long ago, he's a tax lawyer with a few decades under his belt. I asked him simply if he thinks he'll keep his job for more decades to come. His answer was quite enlightening, mainly because of how concrete it was: The problem with tax law (which is not the only set of laws, and not contract law either, but perhaps automatable nevertheless) is that it's simply come to the point that it is at right now as a cumulative effort of centuries of work. It works additively and builds structures so complex that the title tax lawyer almost becomes meaningless with so many specialties being required; VAT, corporate and personal income taxes, inheritance and property... Any effort to algorithmically digitise the existing law would fail unless it's able to perfectly replicate it in code. All of the loopholes and exceptions, safeguards and declarations, there's immense inertia ahead.
What he on the other hand thinks has been revolutionary is free access to law, advanced text search tools, and software to make filings and communication significantly easier. That's the boring part that speeds your work up so you can spend more time devising plans to get your clients to pay less in taxes, and construct stronger defences.
There are many low-hanging fruits in this process; I wish these guys the best of luck, but it seems to me that the comparisons drawn (Intuit, Adobe, etc.) are not analogues. Lawyers aren't seeking these tools for it doesn't provide them value, it only takes away billable hours away.
It seems like there could be a lot of value in disentangling the web: repealing the original laws and replacing them with a single law that covers everything in one place. Legal refactoring if you like.
I can only imagine that would be a humungous task. And presumably the existence of case law makes it much harder still.
It would be quite interesting to think about what the legal equivalent of unit tests would look like. Presumably a large collections of sets of circumstances and desired legal outcomes. It seems to me that this might be an interesting output of legislatures in addition to statutes (although whether they would/should be controlled by the legisalture or judiciary is also quite an interesting question, as our existing system seems to rely quite heavily on the judiciary being able reinterpret laws in ways the original legislators most likely didn't intend)
> repealing the original laws and replacing them with a single law that covers everything in one place. Legal refactoring if you like. I can only imagine that would be a humungous task. And presumably the existence of case law makes it much harder still.
These are called Reform Acts. They are indeed humungous tasks, rarely undertaken. Where I studied law, in the Northern Territory, a Law of Property Act was passed in 2000 and repealed Acts and overruled case law going back to the 12th century in Britain. It was indeed a massive effort.
For some areas of law the Act is also a Code (the Act explicitly says that it is the sole, whole body of the relevant law). This is mostly done for criminal law.
Codes are rare in common law jurisdictions like the US, UK, Australia, Canada, New Zealand etc. Codes are much more common in civil law countries like France, where the ideal is for all of law to be centralised and rationalised. Both systems require endless tinkering, debate and reinterpretation, which is why I am skeptical of universalist missions to convert the whole of the law into a system of formal symbols.
Right, but that in itself doesn't make it a civil system.
If I recall correctly Quebec separates by private and "public" law, so if you get divorced or break up a company it's one system, if you steal from someone, the other.
Legislators are not the sole source of law in common law countries. There is also case law.
Legislation is typically drafted in a structured way, with deliberate norms and forms. There are professional drafters who do exactly that on behalf of legislators, and a body of case law on the interpretation of legislation that guides their work.
> As Merigoux explained more fully on his blog, this project became possible because the French government open-sourced the code that they use to calculate residents’ taxes, which was written in a domain-specific language called M, but they didn’t release the compiler that would have been needed to actually run any code written in that language. MLang is a compiler for M code written by Merigoux, and it has two special features: it translates the tax calculation function to Python, and it enables formal verification of features of the tax calculation using an automatic theorem prover called Z3.
The idea that simpler laws won't get exploited is... Well, I get it, because that's how one operates in computer security, but the way the law works is necessarily quite different. It's not designed so much to make doing what is illegal impossible as it is to make it possible to prosecute those doing things that we'd like to discourage.
There have been attempts by the French and Dutch governments to codify parts of tax law as a trial of sorts, check out M for one https://github.com/MLanguage/mlang
Nevertheless, such efforts cover minimal portions already very clearly defined and debated. As another commenter replied, reforms are rarely undertaken for various reasons. One great issue with tax law is also that whatever code you may write is not necessarily guaranteed to be 'better' (fairness, revenue collected, lack of loopholes and edge cases, completeness, correctness... pick your metric) simply because it's code. That's what I thought too; but no longer.
> Lawyers aren't seeking these tools for it doesn't provide them value, it only takes away billable hours away.
All billable hours aren't created equally. If I can automate the work that I currently hire fresh grads to do - the work of actually drafting up contract agreements for review and wills - but price my services just under the prices offered by other firms then I can make a killing.
You can purchase a hand carved wooden table for your living room and some people still actively manufacture these "bespoke" items, however most folks shop at IKEA and chose between one of a dozen styles available for a dining room table. These two products are mostly functionally identical in terms of supporting food and weathering the years (if you go by depreciation the IKEA table probably loses value slower than a hand carved table - and you can replace it pretty much at will). There will likely always be contract lawyers around to sort out large M&A agreements and other high priced transactions, but wills and simple employment contracts - delivering these in a correct format (i.e. not just a download a sample contract and fill in names possibly resulting in something unenforceable) will be a game changer.
Taxes are extremely complicated - but they got that way by design. The US Tax code is the result of one of the most insane applications of regulatory capture in the world and it's there to allow Intuit to continue printing money at the expense of the tax payer - simplifying those (like for real - not the 2017 version) might not end up happening for decades as there is a ton of money entrenched - so that seems like an incredibly poor part of the market to initially target.
Contract law though, it's not simple but it's so utterly clear and actually codifying it would likely greatly aide law makers in discovering and resolving any existing loopholes and might even provide some useful insight into how the US could better handle the question of employee vs. contractor by enumerating rights and privileges in a clearer format.
And wills, pretty much everyone seeks independent legal council to write one of these at some point - it is highly advisable depending on where you live (in Canada a lack of a clear will causes assets to be tied up by the government for an extended period of time) so you could make a lot of money edging the market out there in particular.
> If I can automate the work that I currently hire fresh grads to do - the work of actually drafting up contract agreements for review and wills - but price my services just under the prices offered by other firms then I can make a killing.
This is probably true, but has a definite knock on effect that breaks the existing training model pretty badly.
I suspect the longer term stable solution is relatively fewer working lawyers relying more on tools - but transitioning the industry to that model will be painful.
Sure, but the intended user for a lot of this stuff isn't the lawyer – it's the end-user who's glad to have an alternative to the lawyer! Like, owning a bicycle means I don't need to call a taxi for some trips. Not all trips, just the local ones, but that's a lot of my trips.
Free access to law, and software for filings like afterpattern.com, that's the boring stuff that lawyers don't want to do and I don't want to pay for, so win/win. And that's all part of the larger vision of computational law that Legalese wants to help realize. Thanks for the good wishes and I hope to deliver on the vision, we've been at it for five years and will probably be at it for another ten before we start seeing results percolating into the real world.
There's a well known book on law called "An Introduction to Legal Reasoning". And in this book, it more or less calls out this scenario on the first page.
"The pretense is that the law is a system of known rules applied by a judge; the pretense has long been under attack. In an important sense legal rules are never clear, and, if a rule had to be clear before it could be imposed, society would be impossible. The mechanism accepts the differences of view and ambiguities of words. It provides for the participation of the community in resolving the ambiguity by providing a forum for the discussion of policy in the gap of ambiguity. On serious controversial questions, it makes it possible to take the first step in the direction of what otherwise would be forbidden ends. The mechanism is indispensable to peace in a community."
I've thought a lot about this because it directly impacts whether you could turn a contract into code. Code is for the most part very deterministic - you can expect that the logic you use will be interpreted in the same way every time given the same inputs. When that isn't the case, it's generally considered a bug.
Law and contracts appear to be deterministic, but are in fact not. Anything that is written into a law or contract is subject to interpretation later. There's no attempt at making it exhaustive because it's not possible, nor is it necessarily desirable. Sometimes contracts contain language that becomes invalid later on, and you don't want to define things too tightly or you'll have to modify the contract non-stop. Sometimes things arise which are not spelled out in the contract and as long as the parties agree, there's no problem. The rules around contracts are a lot more bendable than in code, and "it depends" is quite often the answer to many questions. So is there overlap between code and contracts/law? Certainly. But the deeper you go, the more exceptions that arise.
I agree completely, and the quote you cited more eloquently describes what I was trying to convey in some of my earlier comments. Coming from a software-development mindset, I started practicing law twenty years ago, and the hardest adjustment to make was to understand that even though the law seemed analogous to deterministic code on the surface, in reality it is much different. Today, both writing code and practicing law, I still have to remind myself of the difference sometimes. It is a completely different mindset when dealing with ambiguity, especially in the cases where ambiguity is sometimes desired, welcomed, or necessary. It is also eye-opening to realize that the parties never consider all of the future possibilities, and as such, it's not even possible for a document, however syntactically correct, to convey the intent of the parties 100% -- they don't even know their full intent as to infinite possibilities. I think many of the commenters, just like I did before, struggle to understand this. They don't realize that the "flaw" they're trying to correct is actually a feature -- a messy, sometimes annoying, irrational, subjective, human, necessary feature that's actually an important part of the functioning of society. It's intoxicating to think of a purely logical society driven by immutable, consistent, and brutally efficient laws for everyone, but upon further thought, it's a bit terrifying. Thankfully, it's also impossible.
I've been thinking about this for literally decades.
Unfortunately while the idea is solid, and very much viable, it's all about institutional inertia, not merely technical ability. Good luck to this startup, and I mean it.
Here's the definition:
the formal and technical language of legal documents that is often hard to understand.
"the typed pages were full of confusing legalese"
Business people actually think it's an asset to have an attorney that is "good" with legalese, but the practice actually represents dishonesty. And attorneys are expected to catch these unclear legal language, but most won't complain b/c it requires a few extra hours of back and forth for which they can charge money for. If software is going to eat law, I hope one of the consequences of that is better allocation of legal services and more transparency in legal contracts
One thing I really like about the Legalese front page is they identify the problem with all the other numerous contracting-automation startups out there. We don't need another soup-to-nuts automated contracting solution. We have those, they're fine but they're not going to bring about world peace.
What we really need is an industry-wide API-like-thing to provide a higher base to build all the other contracting solutions on top of.
Right now the default API is "English language" and law of your choice. That's too hard of a problem to solve transparently with technology and it presents a learning curve that's hard to justify with an endgame of vendor lock-in and product instability. And you can only do so much if you're the only contracting party "speaking" that API. Designing a replacement API isn't easy either, and industry adoption may be nigh impossible from the position of a startup. But these folks seem clever and they think big so something to watch.
The site is horrible. Like really really bad. Hard to read, ugly, confusing. I mean I don't want to be negative, I want to give good feedback, but I can't even copy what i want to respond to.
Sorry about that! I'm adding a link to the PDF version which I think is tagged for accessibility. So you should be able to click on the image and go to the PDF. Give me a while, though, am fighting with Jekyll.
The problem here isn't that we are missing a language for expressing laws. Indeed, DSLs for expressing legal axioms don't really exist, and I expect that formal verifiable languages will be created, but even when they are, the problem is not an inability to express laws, the problem is how to map them to entities in the real world.
To give only a single example, "what is admissible evidence?" Assume for a moment that we have solved the "what is admissible evidence in this context" problem. Now you have a giant list of pieces of evidence, testimony, etc. How do you prove chain of custody? The legal system is utterly blind to the world, its agents are intentionally blinded to much of the information, and practically blinded to others.
Even with modern surveillance the amount of uncertainty that is present in many legal cases is substantial, and machine learning won't help you here, because every legal case is a one off. I'm sure someone will try to create a statistical guilt detection net despite the obviousness that it will inevitably produce unjust results.
If you want laws to be written in formal languages, you need a system for defining formal semantics for the entities and relations that their abstracted axioms describe, and things like OWL and RDF are not sufficient, because they only provides the hypotheses, not the evidence. You can assert that evidence subClassOf admissible-evidence, but you need proof that the assertion is valid that can be checked by multiple parties (or anyone with the desire to do so). The one-off nature of many cases often means that you can't go out and test the hypothesis again.
These are hard measurement problems, and we don't have a good language for describing them, and how the measurements themselves are governed by the legals system.
That said, being able to bootstrap simulate court cases with juries drawn from the population would already be a massive win for interrogating laws and their implementation and enforcement. Similarly being able to simulate new legislation to reveal loopholes would be fantastic, though I doubt politicians would enjoy that.
There is quite a bit of data, but I don't think it is particularly amenable to the current fads in machine learning. Amusingly people complain that we'll never be able to write down all the axioms, yet someone wrote down all the laws. Economically unattractive due to a tragedy of the commons certainly, but at the end of the day someone is going to have to write down all the axioms, one way or another. Maybe modern machine learning techniques could be used to generate the axioms for humans to review?
Given that OWL and RDF is meant for both open world data and data models, and is amenable to partial specification, it really solves the problem of relating legal rules to the rest of the world quite well. In your legal ontology you just specify evidence, and admissible evidence, and then another ontology can pick up from there and model it in a specific domain.
And OWL has formal and provable entailment rules. So everyone can agree, given samme ontologies what the implications are. There are unsolved problems there but most of the things you list are already thought through.
I would love to see this succeed, if only so that their static analyzer can go around detecting vulnerabilities ("loopholes") in all sorts of common laws. Legal 0-days!
This reads like it's something new, and maybe parts of it are, and probably any implementation will be 'new' in the sense that it uses recent technical innovations; but when I was in law school 10 years ago, I had a professor (with a chair in 'computational law' or something like that) who had been doing such things since the 1980's. Being a software developer in law school, I looked into his field quite a bit (there have been entire conferences on this topic since the 1980's) and there have been a lot of 'research projects' that explored various parts of what it seems this project is proposing; but none of them practical or big enough to make any impact. And, as usual in academia, it then dies off when the funding ends and the next cycle begins.
Anyway, I'm interested to see what will come out of this, but I see very little awareness of past work, which might be because they want to make it look more revolutionary than it is; or because they're reinventing the wheel. Time will tell.
An important aspect of this is that it is located in Singapore. Singapore is a heavily regulated sandbox in many, many areas. And it is small. For example, there is only a single companies registry and only a single tax authority. And Singapore has a history of mandating big changes. And a lot of effort sunk into presenting itself as cutting edge in terms of government services and management of its population. I'd suggest that it may be possible for Legalese to try some things in Singapore, perhaps in concert with one of the government authorities, that could be an interesting demonstrator.
(Disclosure: One of the founders is a good friend, and I am wishing them success.)
Isn't this the problem "smart contracts" were supposed to solve? I say "supposed to," because the problem here is that if contracts are code, and code can have bugs, then contracts can have bugs. Technically, this is true of traditional contracts, but, if a traditional contract has a bug, it gets settled through the court system, not just executed as is.
It's worth noting that 'Smart Contracts' are more 'Financial Instruments as code' rather than 'Ricardian Contracts' which are what most people think when they see 'smart' and 'contract' together.
I had a comment on the last time this came up where 'A computer language for law' was a bad idea unqualified, but this page actually seems to address most of the points I raised in that comment.
The thrust of the comment is 'Law is not something that will be executable and that we just automate' but more 'Law is something with an underlying structure that we can use engineering tools to write, validate and understand.' That is to say, the tools are there to help the humans with doing law stuff, not doing it for them.
This page is pretty wooly and high level, but it does seem to be going more down that avenue, which is laudable. It does mention smart contracts and Ethereum which I think might be distracting in the early days, but we'll see.
The project seems to miss the fact that when you build an English to DSL compiler, if there are problems with the compiler, the English will prevail under our court system ... not the compiled DSL.
As a result, the computational legal infrastructure will slowly diverge from what the actual legal outcome would be.
It looks like a new legal system would be more useful. Law is intentionally vague for all sorts of reasons both good and nefarious. Computational law is automated contracts.
OTOH if they succeed at coding a large % of finance law, they 'll have created an excellent machine to find loopholes to exploit.
> In 2008 I spent a month writing a web-based system for managing all YC's funding documents. With one click you could get an instance of the latest docs, prepopulated with all the startup's info from our database. The lawyers quietly ignored it and kept using Microsoft Word.
Others have said in the comments that doctors and lawyers are "the last, most powerful guilds" remaining. On the one hand, it's easy to call for "the end of lawyers". (The Legalese website says that sort of thing as a provocation, a way of staking a flag in the sand.) On the other, it's likely that society will always define a special role for the white-collar warrior, the champion of the courtroom; for high-stakes, once-in-a-lifetime situations, you want expert human hand-holding.
In books like https://www.amazon.com/Future-Professions-Technology-Transfo... Richard Susskind offers a more nuanced middle ground. Look at medicine: together, the Apple Watch, WebMD, DirectLabs, home glucose monitors, and home blood pressure monitors (let us never miss an opportunity to say "sphygmomanometer") allow millions of people to do for themselves what they used to need a doctor for. In turn, that lets doctors focus on more high-value work.
Suppose we distinguish quantitative and qualitative reasoning: numbers belong to the former; legal and logical problem-solving to the latter.
Quantitative reasoning went in-house when spreadsheets (the original killer app) landed on the PC: now millions of people do for themselves what a couple of generations ago used to be the domain of the accountant, the bookkeeper, the finance specialist.
What would "spreadsheets for law" look like? If tools emerge that allow laypeople at home and in business to explore for themselves simple questions like "what is the deadline for me to do X", "what things am I required to prepare ahead of that deadline", and "how do I get out of doing Y", frankly the lawyers might breathe a sigh of relief so they don't have to keep annoying people by answering "it depends". There's plenty of low-hanging fruit out there like that which makes people's lives better. Software like docassemble.org and startups like afterpattern.com are exploring these possibilities. Farther into the science-fiction future, researchers in France did a lovely demo, basically fuzzing the tax code to find a sploit that deserved to be patched. https://blog.merigoux.fr/en/2019/12/20/taxes-formal-proofs.h...
One final point: people who argue for the necessity of discretion and the desirability of vagueness and ambiguity tend to have, in the past, benefited from such discretion. But there are less privileged people out there who have been on the sharp receiving end of discretion, and they might prefer a little less discretion and a little more algorithmic, explainable, deterministic fairness!
