I get to spend a lot of time with software engineers and we often compare legal drafting (laws and contracts) with software code. These disciplines are closer to each other than what you may think.
In a recent discussion with a friend about a complex contract, I was pointing at how multiple conditional provisions were badly interacting with each. My friend – who is an engineer and a business owner – explained me that software engineers used to experience similar issues with engangled loops and conditions, and found methods to mitigate them by switching from “imperative programming” to “declarative programming”.
From what they claim, declarative programming allows the code to be comparatively more concise and easier to read, maintain and reuse. These promises cannot leave a contract lawyer indifferent, so I wanted to give declarative drafting a try.
What is declarative programming?
This article helped me a lot figuring out what declarative programming is about. In a nutshell, it consists of instructing a program on what needs to be done, instead of telling it how to do it. This is a fairly empirical definition and the difference between declarative programming (what) and imperative programming (how) is best understood through examples.
Suppose that you have a database of all orders placed by clients around the world and you want to extract a list of all orders placed by male clients living in Mexico.
Declarative code:
Extract ALL from [Orders] where country is « Mexico » and client_gender is « Male »
Imperative code:
Open [Orders];
Read line 1;
– If the value in Column « country » is « Mexico »:
— If the value in Column « client_gender » is « Male »:
— Copy line 1 in a temporary table;
— Otherwise, continue;
– Otherwise, continue;
Increase line number by 1 and repeat from “Read” until you reach the last line;
Send me the temporary table.
This is not actual software code (I am not a programmer), but it should give you a decent idea of what it may look like. The declarative example focuses on describing the result that you are aiming for, whereas the imperative code describes the intermediary steps to get there. Imperative code typically includes loops and conditions, and the end result is constructed through iterations and branches.
Even without knowing the context, the reader may get a good idea of what the program is trying to do simply by reading declarative code. Imperative code, by contrast, is much harder to read. It forces the reader to imagine the outcome of all loops and conditions to get an idea of what the result will look like. You don’t get a good idea of what the program is achieving until you reach the very last stage of the process.
The limitations of declarative code
Describing what you want to achieve only makes sense if someone, somewhere, knows how to do it. In our example above, a database system would have a hard time answering our declarative request if it doesn’t know what “Extract” means and all it can do is read one line at the time when specifically asked to do so.
In other words, declarative code needs an underlying system that is capable of understanding its objectives and constraints and that translates it into a series of lower-level operations. Declarative code shields the user from the nitty-gritty details of low-level implementation.
Is any of that relevant for contract drafting?
Today’s world seems increasingly frustrated with traditional contracts. They take ages to draft and longer to modify. As the Harvard Business Review points out, for the most part, the contracts used in business are long, poorly structured, and full of unnecessary and incomprehensible language.
Contracts have a lot in common with software code. Both are structured documents, written in a somewhat technical language. Both contain series of instructions that aim at producing defined outcomes when certain situations happen. Both dislike ambiguity or contradictions that result in errors (software) or disputes (contracts).
So when programmers develop a method to make software code more succinct and overall easier to write, read and reuse, it should catch the attention of the contract drafters and users alike.
Furthermore, the contracting field meets the prerequisites for using declarative drafting. Remember how declarative software code needs an underlying system containing all necessary lower-level instructions for its successful implementation? Well, contracts don’t come to life out in the void. They exist inside a comprehensive legal system that, allegedly, contains the concepts, rules and methods allowing for the interpretation and enforcement of any human language that parties have decided to make binding. In other words, there is an implementation layer that we can build upon.
An attempt at declarative drafting
A declarative clause should describe what it aims to achieve without describing how to get there. This is fairly vague and empirical, so I gave it a try with a real-life example: a pre-emptive right from a shareholders’ agreement.
Article 5 – Right of first refusal
5.1. Right of first refusal.
Any holder of shares who desires to transfer all or part of its shares (the “Transferor”) to any person (the “Prospective Transferee”) shall give prior written notice of such desire to all other Shareholders (the “Beneficiaries”, the list of which, including their addresses, will be provided by the Company to the Transferor within five (5) calendar days following the Transferor’s request) and to the Board of Directors by e-mail and by registered letter with acknowledgment of receipt prior to entering into any commitment in respect of such transfer (the “Transfer Notice”).
To be valid, the Transfer Notice must contain:
– the type and number of shares being offered (the “Offered Shares”);
– the full name and address (or registered office) of the Prospective Transferee;
– a complete copy of the offer of the Prospective Transferee to the Transferor;
– the effective date of transfer and payment, if any, agreed upon with the Prospective Transferee, which may not be earlier than forty-five (45) calendar days after the date of transmittal of the Transfer Notice (the latter date hereinafter referred to as the “ Effective Date”);
The Transfer Notice shall constitute an irrevocable offer by the Transferor to each of the Beneficiaries to sell to them, for the same consideration per share as the Offered Consideration and subject to the same terms and conditions as the Offered Conditions, all of the Offered Shares.
5.2. Acceptance.
Any Beneficiary wishing to purchase Offered Shares pursuant to the Transfer Notice must notify the Transferor of its acceptance by e-mail and by registered letter with acknowledgement of receipt addressed to the Transferor, with a copy to the Board of Directors (the “ Acceptance Notice”) within ten (10) calendar days after such Beneficiary’s receipt of the Transfer Notice (the “Exercise Period”). The postmark constitutes the date of exercise of the Acceptance Notice. If no Acceptance Notice is provided during the Exercise Period, the relevant Beneficiary shall irrefutably be deemed to have waived its right of first refusal pursuant to this Article 5 (the “Right of First Refusal”). Notification of an Acceptance Notice shall also constitute consent to the provisions of this Article 5, in particular, the allocation powers of the Board of Directors under Article 5.3 of this Agreement.
In order to be valid, the Acceptance Notice shall state (i) the number of the Offered Shares which the relevant Beneficiary is willing to acquire, (ii) the consideration in cash which the Beneficiary agrees to pay for such Offered Shares, which shall not be less but may be more than the Offered Consideration and (iii) any conditions to which the Acceptance Notice is subject which shall not be less favourable but may be more favorable than the Offered Conditions.
5.3. Consequences of non-compliance.
Any Person who has acquired shares in violation of the Right of First Refusal of the Beneficiaries, shall not be recognized as holder of shares by the Company, notwithstanding its rights towards the holder of shares from whom it has acquired the shares. The foregoing is without prejudice to the right of the Beneficiaries to claim compensation for damages actually incurred or to challenge the transfer carried out in violation of their Right of First Refusal under general principles of law.
The clause is drafted in a typical imperative way. The preemption process is described step-by-step, in chronological order. At each step, different options are considered and their possible consequences are described. You might not realize, however, that I simplified the clause quite a bit to keep the example readable. The original provision is a hefty 2124 words long and spans over 2,5 pages. Our example is 4 times shorter.
This example confirms that imperative clauses are hard to read. If a shareholder in this company wonders “can I sell 20% of my shares to my wealthy uncle?”, she must browse the whole provision to collect the essential pieces of information that I highlighted in the text:
- There is a restriction on the transfer of her shares
- The other shareholders must be able to purchase the shares at the same price and conditions that are offered by her uncle;
- The other shareholders have 10 days to exercise this right;
Remarkably, the first element is not even stated explicitly. It results from the context (in particular, from the nullity sanction stated at the very end of the clause).
To determine what is essential (the what of the clause), I used the idea that declarative code should be able to delegate the implementation to the underlying legal system. Everything that the legal system can figure out without massive hesitations while keeping the clause effective, is not essential. Note I use the term ‘legal system’ in a loose way: it could mean the parties themselves, with or without the help of a lawyer, or a court having to decide on the application of the clause according to the applicable contract law.
Another way of looking at it is the following test: can a party defend before a court, with reasonable chances of success, a behaviour that contradicts the intended purpose of the clause, on the argument that any element is missing from the clause? If yes, this element is essential. If not, it isn’t.
- Example 1: The contract does not specify a validity period of the right of first refusal. A potential transferor allows his co-shareholders to preempt shares in the next hour, arguing that the potential acquirer is in a hurry and his offer is only valid during two hours. Does this situation defeat the purpose of the clause? Arguably yes. Is it reasonably defensible in court? I would say yes as well, at least in the absence of bad faith from the acquirer. The validity duration of the preemptive right is an essential element to make it effective.
- Example 2: The contract doesn’t describe a notification process. A shareholder sells shares to her uncle without informing the other shareholders. Can she argue in court that she had no obligation to notify the others in the silence of the contract, with reasonable chances of winning? I think not. The contract prevents her from selling shares unless the other shareholders have a preemptive right, she has a duty to make this right somewhat effective.
Please note that I am using this as a method – you are not obliged to agree with my assessment of what is essential or not in this specific example.
Now, here is a declarative version of the clause, which only states what it is trying to achieve and does so in 69 words:
Article 5 – Right of first refusal
A Shareholder ( the “Transferor”) shall not transfer Capital shares ( the “Offered Shares”) to any person ( the “Prospective Transferee”), unless all other Shareholders have an option to purchase all the Offered Shares, by preference over the Prospective Transferee, at the same terms and conditions as those offered to the Transferor by the Prospective Transferee. That option (The « Right of First Refusal ») is valid during 10 business days.
Obviously, this is not the exact same content ; many elements from the initial provision are absent from this one. Some might say that I didn’t rephrase the same clause but merely cut most of it out. All of that is true, but my point is precisely that declarative drafting allows the removal of all that content without depriving the clause of its intended purpose, because they merely describe how to reach that purpose.
Should we get entirely rid of the implementation parts?
In an ideal world, yes. Contract language would be limited to short, carefully crafted legal principles: creation or transfer of rights, obligations and prohibitions. No one would feel the need to describe how these principles are implemented or enforced. The answers to the how questions would be situational, depending on the country, the parties or other circumstances; it wouldn’t matter too much and everyone would trust that, in the end, the goal will be achieved.
We are not living in an ideal world and, arguably, there is still value in describing in a contract how to implement certain principles. There are situations where relying on the implementation prescribed by the applicable law would not be satisfactory, for instance because of known controversies or bad precedents. There are also cases where relying on the good faith of the parties would be naive at best.
Declarative contract language does not require to eliminate all implementation provisions but allows it if you want to. At the very least, it offers a useful method for grouping and prioritizing the information.
In the example above, it is absolutely conceivable to repeat, from the original clause, the paragraphs about notification, acceptance and sanctions. These paragraphs should be separated from the declarative clause and come after it. They should also avoid repeating any element already provided in the declarative section (this is a general contract drafting rule, not specific to the declarative approach). Here is my attempt at re-drafting the full clause in a more declarative way, while keeping the original content to the largest possible extent:
Article 5 – [Declarative] Right of first refusal
5.1. Right of first refusal.
A Shareholder ( the “Transferor”) shall not transfer Capital shares ( the “Offered Shares”) to any person ( the “Prospective Transferee”), unless all other Shareholders ( the “Beneficiaries”) have an option to purchase all the Offered Shares, by preference over the Prospective Transferee, at the same terms and conditions as those offered to the Transferor by the Prospective Transferee ( that option, the “Right of First Refusal”). The Right of First Refusal is valid during 10 business days (the “Exercise Period”).
5.2. Offer and acceptance
The Transferor shall notify the conditions of the prospective transfer to the Beneficiaries and to the Board of Directors (the “Transfer Notice”). The Exercise Period starts on the date of that notification (the “Transfer Notice Date”). To exercise the Right of First Refusal, a Beneficiary notifies the Transferor (the “Acceptance Notice”) before the end of the Exercise Period, with a copy to the other Beneficiaries and to the Board of Directors
The Transfer Notice must state:
– the type and number of Offered Shares;
– the details of the Prospective Transferee;
– a complete copy of the offer of the Prospective Transferee to the Transferor.
– the effective date of Transfer, if any, agreed with the Prospective Transferee, which may not be earlier than forty-five (45) calendar days from the Transfer Notice Date.
The Acceptance Notice must state:
– the number of Offered Shares that the Beneficiary is willing to acquire;
– the price that the Beneficiary offers to pay per Offered share, which may not be less but may be more than the price offered by the Prospective Transferee; and
– any conditions to which the Acceptance Notice is subject, which may not be less favorable but may be more favorable than the conditions offered by the Prospective Transferee.
All notices must be sent by registered letter and by email. The postmark on the registered letter is deemed the date of the notice. The Board of Directors must provide the Transferor and the Beneficiaries with the details of all Shareholders within 5 calendar days from their request.
5.3 Sanctions
A Beneficiary who does not exercise the Right of First Refusal before the end of the Exercise Period will be deemed to have waived the Right of First Refusal.
Any transfer of Capital Shares made by a Shareholder in breach of this article is null. A person who has acquired Capital Shares in breach of this Article will not be recognized as shareholder by the Company.
Initial observations
From this initial experience, I see a lot of potential for using declarative drafting in contracts. It helps the drafter and the reader alike and is good for reuse and automation. I can think of the following benefits:
Declarative drafting offers a concrete method for an 80/20 approach. Yes, this means getting 80% of the legal effectiveness of a traditional contract while keeping only 20% of its volume. There is immense value in doing that in most transactions. The fact that all clauses of a contract are equally binding doesn’t mean that they are equally important for the parties. Declarative drafting helps cutting less important information in a systematic and meaningful way.
Declarative clauses are easier to read and review. Declarative language makes it easy to understand accurately what a clause is doing by reading it from the beginning. The reader may read further if she is interested in how to apply the provision or move on to the next section. This is very useful for most business users who read contract with a specific question or situation in mind.
Reviewing contract templates of suppliers and clients is a notorious pain for in-house lawyers, especially for projects of minor importance. The lawyer who wants to prioritize her time can either drop the review entirely (and take the risk of missing something completely unacceptable) or read everything as fast as possible, trying to spot important information scattered all across the contract. Declarative clauses offer a satisfactory alternative, allowing the reviewer to focus on the material sections and ignore most of the implementation.
Declarative clauses are self-summarizing. Declarative contract language contain all essential elements. Keep only the “declarative” sections and you will obtain an excellent summary of a long contract. This feature is more useful than it looks, as lawyers usually have a hard time summarizing complex provisions (because “everything is important” or “the devil is in the details”).
Declarative writing favors synthetic thinking. Lawyers are notoriously very strong analytical thinkers. By describing what the clause does instead of following its (chrono)logical path of execution, the drafter focuses on extracting the essential elements (synthetic thinking) rather than describing what distinguishes all possible cases and making sure to cover them all (analytical thinking). As a result, declarative writing forces the drafter to change her thought process and helps to avoid being overly analytical.
Declarative clauses are easier to reuse and automate. Imperative software code is notoriously hard to reuse; more often than not, the entanglement of context-dependant conditions imposes substantial rewriting. A similar argument can be made for contract provisions. Declarative clauses contain all essential elements they need, which makes them less context-dependent and easier to adapt. The same applies to ‘implementation’ provisions: a paragraph describing a notification process can be re-used in conjunction with multiple ‘declarative’ provisions with minor adaptations. This is much harder when the description of the notification process contains material elements of the right or obligation that it applies to. In the current environment where lawyers are expected to do more with less and start leveraging document assembly and automation solutions, declarative drafting offers the substrate to build efficient contracting processes.
Of course, declarative drafting is no silver bullet and won’t solve all issues with modern contracts. In the coming days, I’ll keep on experimenting and will add more examples.