Software engineers and the law

Never ask a lawyer a boolean question

(Like this article? Read more Wednesday Wisdom!)

Many of you will know that I hold a (Dutch) law degree. This came about as follows: When I was younger and started studying computer science, many people told me that toying with computers was all well and good, but eventually one would get sick and tired of that and what are you going to do then? With that in the back of my mind, I was always slightly worried that I would eventually need a second career.

Then, in the early 2000s, I was attending a conference where the head of the cybercrime division of the Dutch national police was giving a presentation. As he told it, they typically spent more time explaining the case to the prosecutor than they spent solving the case in the first place.

And at that time half the cases were people selling stolen goods on the Dutch eBay clone. As the cybercrime czar explained it, they found these cases by doing searches for “fallen from the back of the truck” and “without VAT invoice.”

A light bulb went on in my head: Surely there must be a market for a lawyer with an in-depth knowledge of computers! Holding on to that thought, I registered for the introductory course of the law faculty of the Dutch (distance learning) Open University and started my legal education.

Pretty soon after starting I figured out four things:

1. The law is really interesting! 👍

2. I still liked toying with computers. 👍 

3. I didn’t really like the parts of the law that were money spinners. 👎

4. The parts of the law that I liked were not money spinners. 👎

So all in all I never made the career switch and instead I use my law degree to help friends and family get married and divorced.

The name of my informal law firm is “May divorce be with you”.

I did get to use my computer science knowledge during my master thesis which was about the fascinating topic of Predictive Policing.

One of the things I learned during my legal education is that software engineers could be good at law but are typically bad at it.

They could be good at it because many concepts of law come back in computer science and the other way round. For instance our system of law is a hierarchy of rules where a lower set of rules (e.g. municipal bylaws) typically cannot overrule a higher set of rules (like the constitution). This neatly maps onto the concepts of layers in the operating system (like hypervisors, virtual machines, and containers) where code running at a lower layer cannot break out of it to influence things at the higher level. 

The law is also full of common definitions and pointers. For instance in the basic Dutch administrative code there is a common definition of a decision made by an organ of the state. This definition applies throughout the administrative code and the rules relating to a decision (such as how to appeal, where to appeal, within what timeframe to appeal) are enforced in the same way everywhere. So the Dutch law on the implementation of the GDPR can simply state that a decision (or lack thereof) of the Supervisory Authority is a decision as defined in the administrative code, and we automatically pull in all the relevant rules without a need to specify them again.

All of these are things that programmers can deal with really well because in many ways these are also the principles that govern our field.

However programmers are often bad at law because once they understand the law as a system of rules, they take it to the logical extreme and forget that at the end of the day, the life of the law is experience, not logic (quoting Oliver Wendell Holmes Jr).

For instance many software engineers seem not to understand that proof in a court of law is something else than proof in mathematics. In math, proof means that you have an irrefutable line of argumentation that supports your statement. If you have some of the reasoning but not 100% a solid argument, you might have a conjecture, but no evidence and therefore no proof. In law on the other hand “proof” often just means that you managed to convince a judge or a jury. Uncertainty is often allowed, and the two major standards of proof in the US legal system specifically allow for that uncertainty. For instance when my wife was on jury duty recently the judge specifically explained that “beyond reasonable doubt” did not mean there was no doubt. In US civil trials the situation is even more dire because the standard there is “preponderance of the evidence”, which just means that it is more likely than not.

I regularly come across software engineers who argue some legal point from the perspective of an absolute standard of proof. For instance, during a conference some time ago there was a panel discussion about the (then) latest proposal from the government to ban encryption.

They try this with disconcerting regularity.

One of the questions was how to prove that a data stream was encrypted. A well-known Dutch computer scientist got up and made the point that it is impossible to prove that a data stream containing seemingly random data is encrypted, since it might as well be a set of random “bridge hands” (a set of randomly shuffled cards in a client/server bridge game). This argument fundamentally misunderstands how courts work; the fact that it is not possible to disprove a statement does not mean that the court will reject it as true.

Another thing that I regularly come across is engineers making bold statements about what the law is based on (at best) a limited understanding of some specific rules.

When reasoning about code we are greatly helped by crisply defined interfaces. When debugging my little program that runs on Unix I can typically do so effectively without having an in-depth understanding of all the code of the kernel and the C libraries that my program is using. In decent code I can often limit my analysis to just the function or the module I am looking at. In law on the other hand, it is hard to reason about some of it without knowing a lot about all of it. And “a lot” often also means having more than passing knowledge of any related court decisions, otherwise authoritative considerations, memorandums of understanding, and the record of the parliamentary debate where the law was voted on.

I regularly hear engineers make far-reaching statements on some legal topic that really need more research.

Here is an example: Some time ago I listened to a tech podcast where one of the podcast makers had parked his car without paying the parking fee. His parked car was subsequently scanned and he received a fine in the mail. In the ensuing conflict with the city he asked for access to these records (per article 15 of the GDPR). The city denied this because (according to them) your car license plate number is not personal data. This enraged the engineer greatly and he stated flat out that car license plate numbers are personal data. Full stop. 

These are the kind of questions that law students spend an entire semester on to learn the intricacies of when something is personal data and when not. It turns out that this is a really complicated question, the answer to which depends on many details that are not at all obvious and which require a thorough reading and understanding of the law and of European Union Court of Justice cases like C-434/16 (Nowak) and C-582/14 (Breyer).

One thing I still don’t understand is why the city just didn’t give access to the engineer’s data, since it cannot have been much more than they already sent in the citation: The car license plate number and the name and address of the car’s registration owner.

The problem that many software engineers have reading the law is that, in contrast to math and computer science, the law is full of so-called “open norms”, which is a cool legal term for being vague and nonspecific.  If I read the definition of the LDIR instruction I know exactly what it does and its meaning or execution do not depend on the unique circumstances of the case in which it is used. Law is completely different. We try to be as precise as possible when writing rules, but we also know that reality is so diverse and multi-faceted that it is impossible to write up a complete definition of pretty much anything. And consequently we regularly do battle to see whether Bitcoin is money, a mother can be a father, or a thumbs-up emoji is valid acceptance of a contractual offer. For an outsider there is little rhyme or reason to these discussions and results. Sometimes a list of grounds in the law is exhaustive and sometimes it is not. Sometimes a sentence in the law is parsed narrowly and sometimes it is not. Math and computer science nerds find this hard to deal with and often stick to a very narrow textual analysis of just the law and then taking that written text to its extremes.

Because of this, engineers are also terrible at asking lawyers for advice.

As an engineer I live in a binary world: When I ask another engineer for advice if something works or not, I am expecting a boolean answer. Something is true or it is not. An API supports a particular argument or it does not. An instruction sets the carry flag or it does not. For most code I can literally prove (mathematically) whether it works or not. Consequently, when an engineer asks a lawyer for advice, it is typically a yes/no question: “Is <X> allowed or not?”

That is a terrible question to ask a lawyer.

In the fuzzy world of the law it is really hard to know whether something is allowed or not. In his super funny video “Don’t talk to the police” and equally funny and even more informative book “You have the right to remain innocent”, law professor James Duane makes the point that the world’s laws are so dense, volumous, and vaguely specified that you are basically always doing something wrong. Really, the only reason that you haven’t been arrested yet is that you haven’t annoyed enough of the right people.

It is virtually impossible for a lawyer to say if something is allowed or not. In the words of the aforementioned Oliver Wendell Holmes Jr, the study of law is predicting what the courts will do and the best way to address that is never to get to the court in the first place. For that reason lawyers are bound to say “No” to whatever you ask them, thereby minimizing the risk that they find out that the courts actually disagreed with them, to the great discomfort of all involved.

So here is the boss tip at the end of this week’s Wednesday Wisdom: Never ask a lawyer a yes/no question. Instead, tell them: “I am going to do <X>, make it legal”, and then stick to your guns. After trying to convince you not to do it, the lawyer will have to respond with a contract, policy, memo, privacy statement, additional technical measure, or something, anything, to reduce the risk of what you told them you are going to do anyway. It might get you in court under the less than desirable moniker “defendant”, but you are doing lots of things wrong all the time anyway, so when that happens, just chalk it down to karma.