Programming has become so much more productive during the last decades. The sheer amount of tools available has enabled programmers to focus more on their code, and not on reinventing the wheel.

Starting a new project? You have thousands of templates covering your every need. You can start a new blog, a new web app, a new online shop… just reuse existing and vetted code and tweak it for your needs. There’s so much code out there that even AIs have been trained to produce code.

Now, try to do the same for a legal agreement. You will quickly find blockers. Chances are you won’t find the template you are looking for, unless you are looking for a very popular kind of agreement. And if you do, what jurisdiction was it written for? Probably not the one you are looking for.

Law hasn’t had its open source moment yet. Law is still hard to grasp for most, and most law firms still have the same closed source mindset that software corporations had decades ago. Some firms say that they keep documents closed source for security purposes, but security through obscurity is not a good design pattern.

Moreover, having hundreds of different jurisdictions with rapidly changing legal environments doesn’t make it easier.

The closed source minsdet coupled with the lack of one canonical jurisdiction makes the system weak and fragmented. Weak because legal agreements cannot easily be reused, leading to having to reinvent the wheel each time. Imagine if each software developer would have to write their own cryptography libraries for encrypting user credentials. It doesn’t end well.

Similarly, fragmentation further undermines reusability, since agreements written for one jurisdiction cannot be easily reused for other one.

Reusability, and other properties like composability, are what really made open source software stand out. Reusability is what allowed humankind to amass knowledge, share it, reuse it and then build upon it to evolve, survive and thrive.

So why isn’t reusability engrained in the very fabric of our society, the legal system?

GitHub, but for legal agreements

Imagine a GitHub for legal agreements. Legal professionals open source their agreements and keep improving them. Other professionals can open issues to flag possible problems, or even pull requests to suggest improvements. The end user has access to a wide, vetted set of legal definitions and agreements, and can use them for free.

There are a couple ways that legal professionals can also benefit. In case of special needs, the end user might contact them for paid services. Or maybe we can leverage cryptoeconomic incentives so that legal professionals get paid for their contributions. In any way, the result would be the same: more robust, vetted, freely-accessible legal definitions and agreements.

Markdown, but for legal agreements

Chaotic DOC files, highlighted PDFs… we have all been there. These formats were just not developed for collaboration. Markdown is. Markdown allows for git-style version tracking.

Standard definition format

However, Markdown and git aren’t the only components we need for a new legal documents format. Legal documents often have definitions. They can define the parties in an agreement, the price of a transaction, important deadlines… and currently tracking those references is done, well, by Ctrl + F. What if we could have a canonical way of writing legal definitions in an agreement? So that you can see the definitions at a glance, and hover over any of their mentions to see their value.

Linked definitions

Now that we have a canonical way of creating definitions… why not link them?

In this example, the purchase price in this domain name sale agreement is 12 NATION. What is NATION? Well, it’s a token in the Ethereum blockchain living at the address 0x333A4823466879eeF910A04D473505da62142069. Maybe it will soon be bridged to more blockchains, and so the definition will get way longer.

Today, the best case is that we could copy and paste that definition in our agreement. The worst case is that we would need to write it from scratch. Both are not ideal. What if we could import it? If we could reuse an existing, vetted and maintained definition of what NATION is?

Similarly, we can hover the definition to see its value. This definition can be maintained by the Nation3 DAO, which has an interest in improving it to grow the token’s adoption.

The maintainer can enhance the definition over time, and publish new versions. We can freeze the version in our legal agreement to remove unwanted externalities, but we can upgrade the version from time to time as it improves and leverage a more secure, more specific definition.

A knowledge graph

As more legal definitions and agreements get published and link each other, a knowledge graph will start to form. We can then see which definitions are more depended upon, what each legal agreements depends on, etc.

This can be valuable in multiple ways. First, a definition that is a popular dependency can be considered more vetted, as it has more eyes reviewing it. Second, it can be used to reward the legal professionals maintaining them.

Third, knowledge graphs are powerful because in the future, coupled with natural language processing, they can help us understand the side effects of legal clauses or different pieces of legislation. Why? Let’s imagine a government passing a piece of legislation to alter the wealth tax amounts, for example. They could just publish a new version to the NaturalPersonTax package, changing the WealthTax definition. The side effects are isolated to that definition changing, no need for verbose text around it at all. It’s also machine friendly, so you could literally create a Twitter bot that watches changes in the wealth tax introduced by the government.

Almost more importantly, if a new complex legislation gets introduced, knowing which definitions it depends upon acts as automatic categorization in a way that suits an organic ecosystem. Imagine a piece of legislation that abolishes wealth tax for cryptoassets. Instead of putting such legislation into a bucket (e.g. tax bucket or cryptocurrencies bucket), the text itself can reference packages that it depends upon, such as WealthTax or Cryptocurrencies. Again, this is machine friendly, so if you are into crypto, you could be the first to know each time the government plans to introduce a new bill that could affect you.

This is all technically feasible, and an early first iteration is already working — it’s called Linked Markdown, and it incorporates a superset of Markdown with the features mentioned above. It’s easy to write, easy to visualize and machine friendly. Major changes will still be introduced, but it’s a good starting point.

If you are interested in knowing more or helping build this, subscribe to this publication or join our Discord.