Legal Code In a Version Control System? 334
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?"
Seems consistent with every issue (Score:5, Interesting)
Re:If the legal code is too confusing (Score:4, Interesting)
I would rather deal with complicated texts and have more power in the hands of the voters (theoretically) than which ever judge you happen to get. In small towns judges would have more power than anyone.
Needs disipline (Score:5, Interesting)
I have built a version controlled document management system around mercurial [selenic.com] 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.
legal 'diffs' exist in switzerland (Score:1, Interesting)
when swiss citizens vote if they want to change a law or not (switzerland has a direct democracy) they get a brochure with a summary of the proposal, questions and answers of both sides (yes because.. no don't, because..) a diff of what (raw) legal text would be added/deleted/exchanged to which law and a recommendation of the parliament and the government representatives. the recommendation sucks because it clearly biases people that don't have a clue and just want to have it done in 5 minutes. and the diffs are usually ignored by most people because it's raw undigestible legal text. not perfect but clearly the way to go..
The law is a kind of code, but ... (Score:5, Interesting)
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. [clubtroppo.com.au] 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.
Re:Too early yet (Score:3, Interesting)
I've worked on some large technical documents (several hundred pages) in this way. The document is built up from many smaller chunks which are stored in a version control system. Then to get the entire thing you need to 'build' it. It's actually a major pain in the ass because there simply aren't too many good ways to do this. Whenever anything breaks it's a pain in the ass for everyone.
When comparing this to an enterprise-level document management system, I don't see any advantages at present. The document management systems can include version control and diffing with file-format specific implementations. You wouldn't want to do a binary diff on a word doc for example. It's also usually smarter for these kinds of tasks workflow wise. I'm sure everyone working on these bills have access to some kind of document management system. They're not just passing around USB keys and checking their gmail. The systems they're using are probably perfectly suited for what's being done.
I expect better systems to evolve but simply trying to drop something in CVS has a lot of hidden costs.
Re:Well, we knew it all along... (Score:4, Interesting)
Have you seen the size of these bills? That size and the complexity of the language means that there is no way any congress person could have read the bill. Even the author of the bill, has probably not read the complete text.
That is not as big a problem as it sounds, though. Each congress person and the committees have staffers whose job it is to do just this type of thing. They have teams of technical experts (analogous to software developers) who understand the code of the law. This is one reason that policy debates often focus on reports from all sorts of obscure government agencies. You need highly technical experts to comb through this stuff and make sense of it. The policy debates get down to which set of experts you believe and trust.
I think a lot of us think of congress people as coders who are working on the law, but they are really more like vice presidents directing teams of coders in broad policy directions. In that sense, it is okay (and even preferable) that they not micromanage too much.
Re:If the legal code is too confusing (Score:2, Interesting)
Yep, that must be right. Maybe in OZ, or Wonderland.
Too bad you couldn't have said that a few days earlier. I would have tried to nominate you for one of those Ig Nobel prizes.
Off with your head.
Re:If the legal code is too confusing (Score:3, Interesting)
We're not really talking about writing to cover various loopholes. We're talking about writing in plain English, instead of jargon such as "the party of the first part and the party of the second part, on the first day of the seventh month of the procedural year (as defined in section 2.13.2) will be required..."
They could just say, "Party 1 and party 2 on July 1 of 2013 will..."
Lawyers write in complex language because it's job security... you can't read the law yourself; you have to hire a lawyer to translate. It's approximately-equivalent to a programmer who writes code that may be "brilliant" and work, but only he knows how to debug it or update it. I say we put-aside the jargon and demand that the law be written in 6th grade English. It can be as long as required to cover loopholes, but the average person with a 6th grade education ought to be able to read a sentence and understand what he just wrote.
I've been thinking about this for a while (Score:3, Interesting)
And I think there's a lot of value to it, especially if you use a distributed VCS, like git or mercurial.
In fact, I've even set up a github [github.com] project that tracks the US Code. I have a small Python script that retrieves the entirety of the code from uscode.house.gov and extracts and organizes the titles. There's a cron job that runs this process daily and commits any changes to the local repository, then pushes them to github. So you can use the github project to track the changes that are delivered into the final version of the law.
Where this gets really interesting, though, is if you use the DVCS in the process of crafting the law, not just to store it and track changes. The README file at the top directory of my github project describes some ideas. I have some more ideas about how the whole thing could be integrated with a sort of legislative social networking site, like github or launchpad, but with some important differences, and much more user-friendly. Here's the content of the README:
This repository contains the complete United States Code. Its purpose is to publish the federal code in a way that makes it easy for interested individuals to access both its content and its changes over time.
Another purpose for this repository is to explore some ideas around how to better facilitate the legislative process. Legislation comes in the form of bills which are essentially patches to the existing legal code. Many different versions of a patch may float around to be debated, discussed, amended, etc., before a final version is applied to the "trunk". The process is extremely similar to how developers manage software changes, particularly in the open source world.
I think it would be very cool if something like github were used to manage the actual law, all in the open and fully visible to everyone. I imagine the official code as sort of a master repository. Each legislator could fork this repository and hack on his own copy. Legislators could pull from one another as they massage the language to get it right. The House and Senate would each have their own forks, as would the committees. The president, too would have a fork of the official repository.
The legislative process would then be fully visible to anyone who cares to look. Congressman Blowhard commits a change to his code and pushes it to the public fork. Congressman Slick looks at it, likes it, pulls, commits a change and tells Blowhard about his change, etc. Eventually, the bill makes it to committee, and the committee may have several branches indicating the status of bills as they progress through the committee. Eventually, if the bill is voted for presentation to the House, it is pulled into the committee's "trunk".
If the House votes to approve the bill, then it's pulled to the House's trunk, available to be pulled by the Senate. The Senate can make its own modifications, and perhaps the result must pass through a House/Senate reconciliation committee, before being pushed to the "Passed" branch (or fork), with a message to the president.
Anyway, that's the idea. It may seem kind of silly, but if you've ever actually tried to track the progress of a bill through the existing web interfaces, it's horribly difficult, and there's a lot of information about the bill's movement through the process that simply isn't available. I think using revision management tools just might make the whole process both easier and more transparent.
And that's what I want to play with.
I fully recognize that many legislators may not WANT the sort of transparency that the system would facilitate, but I think that there are a crop of young reformers every year who would embrace it, and in another decade the "facebook generation" will start entering the legislative halls in a big way. It would take a long time to get something like this incorporated into the process, but the result would be a great improvement to our republic.
Bills are already written as a 'Diff' (Score:3, Interesting)
From HR 3200:
"Part A.--Section 1814(a) of the Social Security Act (42 U.S.C. 1395f(a)) is amended--
(A) in paragraph (1), by strikeing "period of 3 calendar years" and all that follows and inserting "period of 1 calendar year from which such services are furnished; and"; and
(B) by adding at the end the following new sentence: "In applying paragraph (1), the Secretary may specify exceptions to the 1 calendar year period specified in such paragraph."
The reason why these guys don't want to read the law is because they're reading a Diff; it takes additional work to dig up the original law and figure out what the diff actually means.
It's why there should be a legislative analyst (such as the one in California who interprets Initiatives for the voters) who can impartially summarize the actions the law will likely take, the potential costs or savings, and who can produce the original law with modifications, using strikeouts and italics to show where the changes take place.
And the output of that analyst should be made available to the public as well on forums such as Thomas.gov, so the lay public doesn't have to chase down the three or four dozen other laws (from Social Security to HIPAA) which laws such as the Health Care Reform Bill would touch.
Re:Too early yet (Score:2, Interesting)
Unfortunately lawyers LOVE loopholes/weak points; any law that lacks absolute ironclad specifics about implementation WILL be subverted immediately. This is how lawmakers can say "I did something about this" without actually changing anything.
Re:If the legal code is too confusing (Score:2, Interesting)
The main problem is not the legal language. The problem is that lawyers in general and politicians in particular are clueless about how an axiomatic system works. They do not understand the concept of a "basis", or why minimizing the number of axioms is important. Only someone ignorant of these things would come up with statements like "cats, dogs, squirrels, any type of llama, and any other mammal". A mathematician or logician would simply say "all mammals".
The problem is that they try to clarify law by increasing complexity, as in my above semantic example. Until they realize that you can only clarify law by increasing simplicity, they are doomed to failure, adding layer over layer of overlapping and contradictory rules.
You COULD create a very rigorous legal structure. But not if you're a lawyer. You need to be someone who at the very minimum has an intuitive understanding of how first order predicate calculus systems work. You start with tangible atoms that are not prone to misinterpretation, and throw out all the mumbo-jumbo slop language like "tort" and "vacate" whose meanings even lawyers can't agree on. Then you understand how change effects your system.
After you've done all that, a revision control system will make complete sense.
The problem is that lawyers are to justice what carpenters are to architecture. They can only be focused on the minutiae of how Blah v. Idaho affects their case, not on the system in general. As a result you get lawyers writing briefs on what the word "the" means. When's the last time you saw mathematicians arguing about what "integer" meant? The reason is not that they are smarter, it is because they understand where the Peano Axioms fit into the big picture.