Featured Post

Linkedin

 These days, I mostly post my tech musings on Linkedin.  https://www.linkedin.com/in/seanmcgrath/

Wednesday, August 30, 2017

What is Law? - Part 16

Previously: What is :Law Part 15.

Now we turn to the world of contracts as it is a sub-genre of law that exhibits many of the attributes discussed in earlier blog posts in this series. In addition, it is a topical area as there is significant innovation activity in this area at the moment and the word “disruption” features prominently. There is a sense that the world of contracts is (or may soon be!) utterly transformed by IT and terminology such as Smart Contracts and Blockchain are being used around water coolers of law firms and IT firms alike.

The excitement around contracts as an IT area is understandable given the volume and importance of contracts in the modern world. Businesses are essentially legal entities that create and enter into contracts. Private individuals cannot get very far in the modern world without entering into contracts either. Everything from filling your car with fuel at a self service fuel pump, to getting married to getting a mortgage to buying life insurance is basically contracts, contracts and yet more contracts.

Contracts have a long, long history as a paper intensive activity. An activity replete with complex language, expensive and time consuming processes. Many people involved in contracts in these digital days – both producing and consuming them – harbor a niggling feeling that maybe it is all a bit arcane an unnecessarily complex for the digital age. Perhaps, (surely!) there is a better way? A way that ceases to use computers as fast typewriters and starts using them to do smart things with contracts, other than just write the up and print them onto paper.

Now along comes the term “smart contract”[1] Irresistible! Who could possibly want contracts to be anything other than “smart”, right? I too am in that camp as I see all sorts of ways in which contracts can be evolved – and in some cases revolutionized – with digital technology.

However, to get there, we have to start from a good understanding of what contracts actually are, and how they work, because for all its many flaws and inefficiencies, the world of contracts is the way it is for mostly good reasons. Reasons that tend to get glossed over in the understandable excitement and rush towards digital “smart” contracts.

The term “smart contract” is typically taken to mean a self contained legally binding agreement expressed purely in computer code, running on a blockchain so that its existence, contents and its actions are recorded in an immutable, tamper evident record for all time.

My primary concern with how the term “smart contract” is often interpreted is the idea that it can be fully self-contained. People and businesses have been entering into contracts for centuries, and for centuries, there have been disagreements and the need to arbitrate disputes over meaning in these contracts. A vast corpus of lore and arbitration machinery has built up over the centuries to handle this.

Why is this corpus of lore and arbitration machinery necessary? Because contracts are never self contained. This is because meaning cannot be “boxed” with the contract. As we have seen many times in this series, the crux of this problem of meaning is that it cannot be completely spelled out in words – no matter how many words you are willing to use!

It is, in my opinion, literally impossible to remove potential ambiguities when two humans are using a set of symbols/signs/words to capture a shared understanding such as happens all the time in contract drafting. Over this series I have given reasons ranging from linguistics to epistemology and there is no need to repeat those reasons again here.

In common law jurisdictions such as USA and UK, a major part of the contracting lore and dispute resolution machinery for contracts is case law and courts of arbitration. When a contract stipulates in a so-called “governing law clause/jurisdiction clause” that the laws of country/state X govern it, essentially what is happening is that the parties to the contract are agreeing to the use of all the laws in country/state X to resolve any disputes that arise about what their contract means.

As well as case law – law produced by the judicial function - there may also be statute – law produced by the legislative/executive function - that gets “pulled in” by the governing law/jurisdiction clause. Common examples are the UCC – Uniform Commercial Code (USA) and UNIDROIT (International). Although non-binding because it is not itself a law, the Restatement of Contracts (https://en.wikipedia.org/wiki/Restatement_(Second)_of_Contracts) is a commonly used single compendium of the law of contracts in the US.

The term “default rules” is sometimes used to refer to the idea that items that are not spelled out explicitly in contracts, may have external general rules applied in the event of a dispute. For example, let us say that I contract to deliver chickens to you. The chickens I deliver are not to your liking and we end up in a dispute about what we meant by “chicken”. Well, the world of contract law has lots and lots to say about how ambiguities like this should be resolved. Give it a few minutes thought and I am sure you can come up with all sorts of ways in which two parties can disagree about what a word like “chicken” means (Live chickens? Healthy chickens? Chicken flavored? Plastic chickens? Etc.) Is it possible to spell everything out in each contract to remove all ambiguity over a simple word like “chicken”? As we have seen over the course of this series of blog posts, the answer is “no”.

Now in classical software development of rules, we typically spell everything out. We bring everything down to numbers (In software, we would most likely model the chicken as a 1kg, sphere, at zero degrees Kelvin, in a vacuum[2]). This can indeed be done with some aspects of contracts but not others.

Lets take a simple example. Imagine a contract clause that says, that I give you the option of buying from me, a copy of the Beatles White Album, at fixed value X, for the next six months, starting on date DD/MM/YY in return for a non-refundable payment now of Y dollars.

This sounds simple enough to model right? We have the dates, the monetary values. all is good... Well, exactly what White Album are we talking about? What if I have two and I deliver the one with the scratch on it? What if I think we are talking about the album cover and you think it includes the vinyl record itself? What happens if it gets damaged between now and when you exercise your option? What happens if you think delivery is included and I think it will cost you extra? What if I think we are working in Australian dollars and you think American dollars?

This list of “what ifs” is essentially bottomless. Over many hundreds of years, countless scenarios like these have actually occurred and resulted in contract law developing a large corpus of material that “plugs the gaps” of meaning that are inevitable in real world contracts. the stuff that does not fit into tidy little boxes like dates and quantities etc.

This external corpus also provides rules/guidance that can be used to settle disputes about meaning. A good example is the so-called parol evidence rule[3] which speaks to how disambiguation of meaning can take place. There is also a well developed hierarchy of context information that has been established over the centuries to guide the disambiguation process e.g. the history of how the parties have acted to date (“course of performance”), the history of how they have interacted in the past on other contracts (“course of dealing”), general trade standards/conventions (“trade usage”) etc.

As you can see, there is a vast amount of material and arbitration machinery that sits outside each real world contract but is in effect “pulled in” to each contract by the jurisdiction clause. So much for “self contained” :-)

There is another important sense in which contracts are not self contained and it relates to the component pieces that must exist for a contract to actually exist between two parties in the first place. This is where we will turn to next.


Monday, August 28, 2017

The power of combinatorics, in, well, everything

It was late in the morning (around 5:30 a.m.) by the time Master Foo arrived at the training center.
"I am sorry I am late", he said as he sat down. "I had trouble finding Raw Sienna. It was hidden under my meditation box."
The students looked at each other askance from behind the screens of their laptops. "Raw Sienna? What is that and what has that got to do with developing 21st Century Web Applications using mashup technologies?." The students had paid good money to attend this training course and had lugged their laptops up Pentimenti Mountain the night before to be here. Not to mention the fact that they had risen from their freezing tent beds at 5 a.m. to suit Master Foo's schedule.
"Before we begin looking at the details of mashup application development, I would like to draw you a picture", said Master Foo.
From the countless folds in his robes he proceeded to extract a scroll of paper, a small vial of a clear liquid (presumably water), three artist brushes of varying sizes and 6 small tubes of paint.
"It will be a landscape. Please pay close attention to the mixing of colors."
Over the next twenty minutes, Master Foo created a landscape watercolor painting of the view from the top of Pentimenti mountain. It had a brilliant blue sky created with Cerulean Blue[1] for the lighter parts and Ultramarine[2] for the darker parts. Beneath the sky there were many - perhaps dozens of shades of green used for the trees, bushes and grass. As he worked, Master Foo picked up colors one at a time on his brush and mixed them deftly in small plastic containers.
"Master Foo", one of the students asked, "you have used two types of blue and you sourced them directly from individual tubes of paint. Yet, you have used many shades of green but they are all mixed from other colors. Why is that?"
"How many different greens can you count in my picture?", asked Master Foo.
"I cannot count them exactly, there are many."
"How many types of green did you see on your hike up Pentimenti Mountain?"
"I do not know. A countless number I guess."
"Indeed so.", Master Foo replied. "Now tell me, how many types of application do you envisage building on the Web using mashup technologies in your career?"
"A countless number!", blurted one of the students over the top of his iBook.
"Indeed so.", Master Foo replied, grinning as he again turned his attention to his painting.
"Color mixing is a limitless universe of potentiality. Out of these 6 tubes of paint I can make a limitless number of colors given enough time and creativity. By learning how to use each color both on its own, and in combination with the other colors, my color palette is unlimited."
"The true key to expressive power - in any medium including computing - is combinatorics.", he continued. To the relief of the still baffled students, he also switched on his laptop and Ubuntu sprang into life.
"Now tell me," began Master Foo as he logged in, "what is a mashup really? What is its true nature?"
"It is an exercise in combinatorics!", blurted an eager student. "The power of the mashup concept lies in the ability to combine bits of existing website screens into new website screens."
"Yes and no", said Master Foo, grinning again.
"The true nature of a mashup is indeed combinatoric but not at the level of website screens. A mashup that grabs bits of existing website screens and puts them all on the same screen is just a collection of portlets. A mashup is a deeper integration. It involves grabbing data and grabbing functionality from existing websites to create a brand new website whose functionality is more than the visual sum of its component parts."
"If that is so Master Foo", why have you shown us how to paint a watercolor picture?"
"I have done so because it is an excellent illustration of how not to think about mashup Web applications. An anti-pattern by analogy."
"Ah. So you are saying that we should look deeper than the screens. Look at the data and the functionality that needs to be integrated first. Then worry about creating the visuals of a website?"
"Precisely. Unfortunately, very few developers will bother to do that."
The room fell silent.
"What can be done about that sad situation Master Foo?"
"I do not think anything can be done, I'm afraid. After all, it is fun just to paint pictures! That is their great attraction in Web application design and their great limitation. It is important to note that the term 'mashup' is nothing more than a modern twist on the phrase 'application integration' with all that that involves. Until today's army of young web designers realizes that, we will see a lot of pictures being drawn with nothing but thin white paper underneath them."
The room fell silent again.
"Enough of that sadness", said Master Foo, clapping his hands together. "Let us begin our study of the true route to our salvation which will probably be called mashup 2.0 or something similar. REST is a software architectural style for distributed systems[3]..."