Legal Code In a Version Control System?

coldmist writes "Sen. Thomas Carper (D-Del.) is on the Senate Finance Committee, which just finished work on the health care bill. The committee recently rejected an amendment which would have required them to post the legislation for public viewing for 72 hours before it went to final vote. Several senators felt that the actual legal code would be too cryptic and complicated to be useful. Carper himself said, 'I don't expect to actually read the legislative language because reading the legislative language is among the more confusing things I've ever read in my life.' So, why don't they put it in SVN (or some similar version control system) where people can tkdiff the changes (i.e. new legislation is in a branch) or output a patchset? If a bill is passed, it's merged into the trunk. It just seems so logical to me, yet I can't find any mention of doing this on the web. What do you think?"

Comments

Seems consistent with every issue

[cjfs]

If you can't convince them, confuse them. -- Harry Truman

Needs disipline

[MichaelSmith]

I have built a version controlled document management system around mercurial for my wife's architectural practice. I have found it very difficult to convince users to follow the conventions we use for software. They are too used to putting version and project information in file names. It means nothing for them to rename a file from a.dxf to a_new.dxf and commit it.

The formal structure of software tends to keep this behaviour in check. The environment we are talking about here may be formal and controlled enough for this to work, but it is going to take training and enforcement to get it to work.

The law is a kind of code, but ...

[Jacques Chester]

1. There's an enormous amount of existing code. Look at how much Slashdot talks about COBOL, which is around 50 years old. In common law countries (eg Britain, the USA and Australia), the law has code nearly a millennium old, written in a variety of languages.

2. Corner cases. There are lots of these. Much like software, they are usually discovered in "maintenance mode"; ie after the law is passed. As time goes on, legal draftsmen begin to include lots of standard boilerplate, which will only rarely actually be applied.

3. Legal draftsmen. Never heard of these? Who do you think actually sits down and writes the law? It's not the politicians. They give drafting instructions, which are translated into legalese.

Expecting politicians to read and comprehend legalese is a bit like expecting businessmen to read and comprehend assembler. It will never, ever happen. The idea of "plain english" law is a lot like "automatic programming". A total pipedream that will never happen.

The law is a semi-structured language. You can think of it as a distributed rule system created by a mix of engineered modules (Acts of Congress / Parliament) and reverse engineering.

The reverse engineered parts are case law. Lawyers feed in black-box test cases, then carefully record what the CPU (the judges) output. Over time they map out what the law "is". The reason legalese repeats the same phrases over and over again is because they have been proved, in court, to have specific and reliable semantics. "It ain't broke", so to speak.

I personally think there's enormous scope for borrowing software engineering practice and tools for legal drafting, but it's no panacea. I even used to think that we could treat legalese as a kind of assembler and develop a higher level language that "compiles down" to it. But it doesn't solve the problem, just moves it around.

Laws are flawed and problematic because they deal with humans. Humans who are complex and motivated and intelligent. No purely rule-based system will ever completely tame human ingenuity, just as no code will ever fully describe all subject domains.

Disclaimer: I used to be a law student, until I came to my senses.