(cbf to read? go straight to the tl;dr infographic)

open source  ●   international  ●   diverse   ●     remote-first   ●    aspirationally teal   ●   softly holacratic
(see our culture keys)

Marc Andreessen said, software is eating the world;  at Legalese, we say software is eating law. Our solution to the broken-law problem is to resolve it at a fundamental level, using math, computer science, and logic. At the core, we are an open-source complaw project working on the drafting of legal documents the way programmers develop software.

We start by creating and implementing L4, a domain-specific language (DSL) for legal that is specifically designed to capture the particularities of law, its semantics, deontics, and logic. Just as Cadence's Verilog allows programmers to draft circuits, Legalese's L4 will allow programmers to express lawyes, the applicable laws, but also the regulations, business processes, business logic, and other quasi-legal rules — all the rules and logic that you want your documents to adhere to.

Our activities are distributed across 2 parallel tracks:

• DSL research:   use-inspired R&D on the design of a DSL for law
• product development:   development of user-facing web apps in different verticals and domains

These are a stack:  the web apps sit atop smart contracts which sits atops smart law/statutes/business process rules, and they all sit atop a bunch of math, logic, and a few "magic" tricks.

---

Our first product tackles startup fundraising.

It allows entrepreneurs to create, automate, and execute entire fundraising workflows for angel or seed rounds under 5 minutes — we're talking the main investment agreement, corporate resolutions and amendments, rights notices, as well as prerequisites like ESOPs and vesting, all compiled from high-level expressions.

Currently, product development and R&D are discrete and run in parallel. In 3 years (or so), we expect the 2 strands to dovetail.

Innovation Premise:   Law better off as Code

The legal industry today is where software was in the late 1950s:   getting ready to make the jump from macros to compiled languages. Tomorrow's lawyers will look a lot like today's programmers:   drawing on opensource libraries, they will configure code for clients that compiles to readable contracts – maybe English, Mandarin Chinese, maybe Ethereum/Hyperledger. From that future, we will look back on today's lawyers, drafting agreements in Microsoft Word and checking references mandraulically, as white-collar successors to John Henry.

A smart contracts world needs computational legal more than ever. The Institute of International Finance (2016) writes:

Why now?

Thirty years of academic research in deontic modal logic, contract formalisation, static analysis, and language design are coming to fruition in papers like Tom Hvitved's PhD thesis (2013). Contracts are multiparadigmatic: they can be object-oriented, event-driven (reactive), functional, aspect-oriented, declarative, and imperative, all in the same document. Academic contract formalisations are just now beginning to satisfy the necessary properties for reduction to software practice.

What Legalese is Not

• Computational Legal Augmentation
  Legalese excludes the “computational legal augmentation” field well surveyed by Prakken & Sartor (2001). Defeasibility is essential to law, lest the law turn monstrous. However, it renders deductive logic futile. We admire their prodigious display of brainpower, wish them good luck, and retreat to the easier, more deterministic, less controversial end of the spectrum.


• General purpose language that allows non-programmers to program
  L4 is not a language that “allows non-programmers to program”. This is a fallacy. See Essay by Zompist about Programming Languages and Paul Ford’s magnum opus, What is Code? An expert who can write legal code in L4, by that act becomes a programmer, just as any magic-user who can combine two existing pieces of magic to create an original third becomes, even in the smallest degree, a sorcerer. That said, the apps that Legalese-the-company build will instagrammify L4 in the form of "low-code platforms".


• Expert system that gives legal advice
  Legalese is absolutely not an expert system that gives legal advice.


• Online repo of existing legal materials
  Legalese does not simply fight to get existing legal materials online. That’s the job of the Free Law Project, Public.Resource.Org, FALM, OpenLaws, and the LIIs.


• Building legal ontologies
  Legal Ontologies are a huge area of research which we would like to reuse, not reinvent.


• Statistical A.I.
  Ross Intelligence harnesses Watson to do cool things. We don’t do deep learning, machine learning, or natural language processing to try to understand natural language contracts. The A.I. we're interested in is Symbolic AI.

The Business Challenge

Very clever people have thought long and hard about a world in which computers execute contracts, where programs transfer money to people and people transfer money to programs, where decentralized cryptocurrencies disrupt banks and financial institutions. Very clever people will be involved in the effort to build a bridge between formal and natural languages. Many man-years will go into developing a Github/Wikipedia of legal templates that are freely available for all to use.

Legalese is clever in a different way. The business challenge of getting from the 20th-century status quo to the 21st-century promised land requires the ability to scout and climb a monotonically increasing path through multidimensional “value-proposition” space toward the global optimax. This is as much a logistical and business challenge as a computational linguistics challenge. That’s why we’ve chosen to start with spreadsheets: we optimize for the power user while building a painless onboarding pathway for first-timers.

You know how some extreme runners run fifty marathons in fifty consecutive days? Actually running the marathons is one kind of challenge. Arranging the flights, travel, and accommodation so the runner gets from finish line in one city to starting line in another, is a different kind of challenge. Developing a domain-specific language, or a library in which to model contracts, is the former kind of challenge. Making Legalese succeed as a business is the latter kind.

Natural Language Generation

Text planning and interaction effects are critical to contract generation. One part of a contract may affect another. Sometimes these interactions are simple, and can be represented by a DAG. Sometimes these interactions are, superficially and conventionally, cyclic, and need to be decomposed with some clarity. Metaprogramming helps to correctly represent these interactions. CoGenText is an example of an NLG company. See also GrammaticalFramework and Attempto English.

Social Implications of Natural Contracts

(Written as a response to a thread on HN)

Today’s model of contracting is fire-and-regret: spec out as much as you can of the next five or ten years, and when the world changes, litigate. That’s not very agile. And unfortunately for the non-agiles, Hart and Holstrom won the 2016 Nobel in Economics for pointing out the futility of the idea of a complete contract.

What’s the alternative? Hirschman remarked that your voice sounds loudest when you are closest to exit. What if every contract had a maximum term of one year, one month, one day? What if we treated contracts as an iterated stream instead of an immutable invariant? For example, think about how “no-contract” phone plans have made the telco market more competitive, to the benefit of the consumer. Power imbalances might be reduced precisely because nobody’s locked in: it’s a lot easier to break up when you’re just dating. After the marriage you might let yourself go.

Software is eating law, but “law is code” is only the first step. Just as the historic transition from proprietary to opensource informs ideas like “Github for law”, the historic transition from waterfall to agile will find its analog in the legal and business domains by changing the way we develop and deploy contracts, ultimately driving changes in economic relations.

Think about how agile development means less software project failure, and less software project failure means less litigation between client and outsourced development vendor. That’s just one example. If better tools and languages mean that we can better transform our intent into specification, we might be forced to be clearer about what we actually do and don’t agree on, we might be more honest in our dealings, there might be an actual “meeting of minds”, and when things don’t turn out the way we expect, rather than blaming the other party, which seems dysfunctional, we embrace change together, and agree to consciously work on the relationship, to improve the next iteration of the contract … which is due to be revised and renewed anyway, next month, not next decade.