Open Source Contracts: Part 3

Imagine if lawyers from different firms collaborated on standard documentation for everyday legal transactions, e.g. loan agreements, wills, conveyancing etc.  What if it was all freely available to their clients too? We call this open-source contracts (“OSC“). 

This is part 3 of a 4 part series of posts exploring whether the legal industry could and / or should adopt an open source contract approach to legal documentation.

Part 3 explores whether and to what extent the legal industry already does adopt many of the ideas we suggest for open source contracts.

Check out the full series: part 1; part 2; part 3; and part 4.

As lawyers, much of the job is modifying your firm’s, your client’s or the other side’s internal templates and precedents for new transactions.  Rarely do you start a legal document from scratch nor finish one without collaboration.

But how so?  The answer: everything produced benefits from OSC to a greater or lesser degree.

1. Knowledge Management

Teams of knowledge managers identify, organise and curate a firm’s internal knowledge base.  They create and maintain accessible repositories of templates, precedents and expertise memos.  These are constantly updated by knowledge managers and lawyers to:

• fix errors (i.e. like a developer submitting a pull request to fix a bug); and
• enhance the documents in line with latest case law, regulations or market practice (i.e. like a developer improving the software or its ability to remain innovative, interoperable with other systems and in line with the latest thinking).

Internally firms are also massively reliant on externally and independently curated knowledge management sources, e.g. Practical Law Company (“PLC“).

Sources like PLC curate a rich set of precedents, know-how and Q&As. 

Practising lawyers at law firms contribute to this platform and their contributed content is stewarded by PLC.  These documents can be downloaded, amended, extended or individual clauses used as building blocks for custom versions of the same.

Whilst it’s not free, it does provide a means by which to collaborate and share templates and know-how between firms.

2. Document Management Systems (“DMS”)

Like OSS, documents and know-how are maintained in a version control system, typically a DMS, like iManage Work or NetDocuments.  A DMS functions somewhat like GitHub and Git (tools used to version control, collaborate, organise and share code).

Similarities

For instance, a DMS shares these qualities with tools such as Git and GitHub, e.g. the ability to:

• create new documents (like committing and pushing new code to GitHub);

• copy a version of a document (like cloning a repository of code or code branch from a codebase);

• create a new version of an existing document (like versioning up with Git);

• merge a new version with an earlier version of a document (like rolling back an earlier version in Git / GitHub); and

• view editing histories (like the ability on GitHub to see a delta view of all changes to the code with each new version).

One key difference: branching – the missing link for collaboration

However, a key difference is branching. A DMS does not typically allow for branching in the same way Git and GitHub permit.

The latter allows multiple users to create parallel versions of the same code, in turn permitting selective merging of branches back into the master branch. This allows one or more developers to work on a particular feature without disturbing the work of other developers focussed on different features. Once everyone is happy these branches can be merged back together.

For example the below diagram illustrating this concept:

In law, this feature would expedite collaboration. For instance, on a large deal with multiple lawyers, it would be useful to allow each reviewer to branch off the master document, make their changes (e.g. to a single clause or several discrete clauses) and then mechanically merge those changes back into the master branch as desired by the relevant document owner to ensure it all hangs together.

Doing so would allow easier collaboration vs. the current approach for DMS. The current approach via DMS only permits an entire document to be “checked out” to a single user, preventing all other users from collaborating on that particular document version until it is checked back in by the user who first checked it out. This is the same no matter how significant or insignificant the required contribution of the second contributor.

True, this is possible right now but incredibly suboptimal. It is only possible through a lot of fiddly workarounds, principally some poor lawyer – usually a junior lawyer – coordinating over email and telephone the collection of conflicting Microsoft Word mark-ups – that sit outside the version control of the master document – and manual copying and pasting of changes into the master version.

This is time-consuming, costly and error-prone. It’s also soul-destroying work inevitably done under huge pressure.

Git style branching via software means would massively improve the status quo. The challenge would be the UX: making it easy and practical for lawyers to adopt and use these concepts to collaborate.

One final point: this style of collaboration could be adapted inter-firm, although the challenge would become political vs. technical as firms typically don’t like to share software nor cede too much control in terms of document editing rights.

This highlights a key distinction between OSS and OSC. In OSS goals are broadly aligned and non-adversarial in the sense that the end products – software – aren’t intended necessarily to be used in opposition depending on who adopts them. In OSC, the same might be said except that the end products – contracts – are to a greater extent necessarily used in opposition depending on who adopts them: contracts will always reflect a negotiated balance of interests.

In the strict sense, one word describes inter-firm OSC: non-existent.  Law firms don’t collaborate on the creation, maintenance and innovation of legal documents that are then shared publicly for others (e.g. clients) to use, enhance and contribute. 

Instead, contracts are generated within the four walls of each firm and negotiated at arm’s length with other lawyers at other firms.  Lawyers don’t collaborate, they negotiate.

That said, many things law firms already have elements of OSC, even inter-firm.

The nature of negotiation

As you can see from the above, although the means may be similar, the motivations, and therefore the ends, are divergent.

The elephant in the (negotiation) room

Flowing from the foregoing, the world’s largest law firms work on the same transactions, with the same / similar types of clients and, subject to conflicts clearances, frequently alternate for which side they act (e.g. buy side on Deal A and sell side on Deal B etc). Likewise, many of the individuals involved law firm and client side are the same deal to deal.

The result? Each firm gets to see each other’s documents.  Although one firm won’t see the other’s internal template from which the first draft evolved they will over time gain a pretty good idea of that document’s contents. 

Further, when lawyers leave one firm to join another they invariably take with them huge volumes of their prior firm’s precedents, templates and other materials (despite being contractually prohibited from doing so by their previous firm!).

As a result, firms naturally curate collections of rival firms’ content. This inevitably results in the ‘war of the precedents‘, i.e.

Law Firm A: “Please find attached our legal opinion.”

Law Firm B: “I think you’ll find the last legal opinion you [Law Firm A] issued, included a capacity opinion with wording X.  Why can’t you provide wording X now?”

Law Firm A: “This deal is different.”

Law Firm B: “No it’s not.  It’s exactly like the Mega Acquisition Deal from 2016.”

Law Firm A: “We’ll have to circle back internally.”

A few hours later…

Law Firm A: “Please find attached our legal opinion with the wording you [Law Firm B] requested.”

Law Firm B: “Thanks.”

In other words, big firms largely have access to each other’s documents and therefore can decide how to sensibly negotiate them within the parameters of past practice.

The closest thing to inter-firm OSC in the sense of collaborative enhancement of documents to satisfy a legal requirement (rather than advance a client’s interests alone) is possibly the industry-driven attempts to standardise certain documentation.

For instance, in the European loan market, there is the Loan Market Association, formed by over 500+ law firms, banks, information and systems providers and other market participants.  

These members collaborate on the development and maintenance of a standardised suite of loan documents for the likes of large corporations, investment banks and private equity funds to finance acquisitions and other obligations (the “LMA“).

Provided you pay for a membership, like OSS the LMA documents:

• can be downloaded and edited as the user sees fit;

• are modular by design allowing users to add / remove modules where necessary to tailor the documents to their client’s transaction;

• are accompanied by supporting documentation; and

• are continually updated in line with legal developments and market practice via collaboration between LMA members.

Also like OSS, the LMA hosts a variety of events and conferences, much like those organised as part of large OSS projects / communities.  The aim of this is to streamline the creation and maintenance of these documents whilst reducing the negotiation necessary to agree on the most common elements of these documents and engender best practices and common structures for such transactions.

The International Swaps and Derivatives Association (“ISDA“) is another great example. 

ISDA is a trade organisation of participants in the market for over-the-counter derivatives.   ISDA creates and curates a standardised contract (the ISDA Master Agreement) that the world’s largest financial institutions and law firms (on behalf of their clients) use to enter into derivatives transactions.   

Users can download these documents to create new versions, amend and extend them to fit their transactions.  The standardisation reduces the complexity of negotiation substantially and helps streamline the legal process as a result.  In addition to legal and policy activities, ISDA manages FpML (Financial products Markup Language), an XML message standard for the OTC Derivatives industry.

Taking things further still, ISDA is creating a common domain model to digitally map the processes, events, and documentation thereby facilitating digitisation of the entire ecosystem through technology.

By doing so, ISDA hopes to enable better search, analytics, machine learning, interoperability with trade reporting systems and distributed ledger technologies.

In either case, each market identified a need to come together and standardise the process, documentation and terminology to reduce negotiation, create consistency and enhance the delivery of legal and financial services.  Rather than each participant building up its own proprietary versions of the same sorts of documents, structures and processes it made sense to come together. Granted parties often prefer their own precedent versions of these documents, but they are still starting far closer together than if they started without any standards at all.

As a result, the collaborative focus and standardisation of a solution to a domain specific problem (loan transactions or OTC derivatives) have led to widespread adoption of the LMA and ISDA documentation and processes among the main participants in those markets. 

To our mind, this has significant parallels to OSS – many interested parties working together to create a homogenised solution to a domain specific problem.  The LMA and ISDA are to our mind a controlled version of OSC, albeit in narrow but significant domains.

If the world’s biggest financial institutions, law firms and other market participants can and have come together to standardise certain documents in certain situations why not apply this open source contract paradigm across other legal documents and transactions? 

Open source contracts could be especially beneficial in the markets with the highest churn of routine legal work, e.g. real estate, employment, wills and any transactional documentation or process that is largely the same from deal to deal etc.

Next time

In the next article, we’ll discuss whether law firms and legal practice could and should adopt open source contracts. We also explore the extent to which open source contracts are already starting to happen, including the means and organisations behind adoption of open source contracts. 

Jump to the next article in this series by clicking part 4.

Check out the full series: part 1; part 2; part 3; and part 4.