zlacker

Law is a very, very, very hard task to tackle properly.

You may not know but there have been three big "generations" of law systems. Many parliaments are starting to use fourth generation systems. Third and fourth generation systems look a lot like a complex git, but there are many things that should and do work differently.

When I started dealing with these things I thought that it was a solved problem, just use SVN (the cool kid at the time) and everything will be solved. Well, none of the existing versioning models work well with law documents, especially acts. The general ideas do apply, but many of the details do not. For example, just think of a merge conflict: who are you so solve a merge a conflict? What you have to do is to just record the conflict and create two parallel universes, one in which the conflict has been resolved using branch A and another one in which the conflict is resolved using branch B. You then keep these two universes alive and apply all the later changes twice. You have to do this until a judge or a legal body declares one of the "branches" the correct one; this may take years and the decision reverted (even partially) many times.

A few links to relevant standards and systems:

* Legal XML: http://www.legalxml.org/ An OASIS working group that is merging all the relevant national standards into a worldwide standard. * Akoma Ntoso: http://www.akomantoso.org/ A UN/DESA-sponsored format for legal documents. * CEN Metalex: http://www.leibnizcenter.org/ a meta-format that acts as an exchange format between legacy formats and new systems. * LexML: http://projeto.lexml.gov.br/documentacao/resumo-em-ingles A huge Akoma Ntoso-based repository of Brazilian laws. * ICA/SPP: http://www.ica.org/792/about-section-for-archives-of-parliam... The groups of archivists that deals with all the fine points you have to deal with when archiving laws and dealing with legal documents in general.

The main international conference on Law and IT is Jurix, it started in 1988. Check out their proceedings to see how things evolved over time.

If you are interested in hacking something related to laws or legal documents (judgements, parliamentary debate records, historical versions of laws) just get in contact with me.

Disclaimer: I work in this field and I am related to some of these systems.

>>gioele+(OP)
What do you do about bills which refer to existing laws, with instructions to "strike blah" and "insert foo before x in section xxx of this chapter"?

Maybe it's possible to parse that and apply that sort of bill most of the time, but I'd be surprised if it were possible to do so reliably (unless natural language processing becomes a solved problem) (or perhaps I'm overestimating the complexity of legislative language and converting legislation into a patch against existing law is not a hard problem).

The first step, however, could be to do revision control of bills, blind to references to existing law.

Representing bills as patches to current body of law is the endgame, but I think simple revision control of bills as they wind through the legislative process would add a lot of value and would be relatively straightforward.

>>harshr+n1
My understanding of the legislative process is that a bill exists in a stand-alone form while it is being debated. When it is voted upon in its final form, however, lawyers working for the legislative branch convert the "human readable" form of the bill into what is, in effect, a "patch" to the existing law (i.e., "Paragraph B of subsection 2 of title 18 shall be amended to read ..."). My (albeit cursory) understanding is that these literal changes to the code are what are actually voted into law.

http://en.wikipedia.org/wiki/Congressional_Research_Service

Conceivably, changes to the US code could be tracked in the same way that changes to a bill are tracked, and every bill could be introduced as a branch of the US Code (i.e. a patch on the trunk), and every vote on a bill would be a vote to merge that branch.

>>gioele+(OP)
First of all, remember that git do branching a heck of a lot better than SVN. Secondly, the general answer to the merge question is that it should be up to the legislative body to add to the production branch of law. That includes the merge commits obviously, just like merge commits is the responsibility of whoever adds something in a production branch of code.

>>gioele+(OP)
Can you explain how a "merge conflict" arises? Surely something can only become law once it's voted in, and a specific revision of a document is what's voted on?

>>gioele+(OP)
In a GitLaw there won't be merge conflicts. There will only be merging to the trunk. The first one (by UTC time) to commit will be revised first and either merged or rejected. Then later entries processed in the same way. Trunk is a current working law. To prevent overworks there should be made freeze periods (180 days is sufficient I think) where no merges occur and merge periods (30 days max) when commits are processed. This leaves problem with system abuse with millions atomic commits to disrupt work process. Can be solved (probably) by setting penalties for abuse (fines etc.). System abuse is very hard topic overall, preventing it sufficiently will be hardest thing to make in all GitLaw project.

>>gioele+(OP)
I think this part about branching universes only applies to common law system (i.e. anglosaxon) ?

In law systems derived from roman law (like in my country) law doesn't depend on judges decisions.

But IANAL.

>>ajuc+dB
It happens on civil law systems as well. There are many courts whose only purpose is to check the compliance of new acts with more important acts. For example an ordinary act can be approved and later partially repelled by a revision court if found in contrast with the local constitution or basic law.

You also need multiple contemporary universes whenever a law system has _favor rei_, i.e. the most favourable interpretation or version of the law is used while judging.

>>lusr+km
"Merge conflicts" arise whenever you have modification acts, in other words acts whose only purpose is to change the text of another act. (Most US and EU acts are modification acts.)

The way modification acts are voted and then enter into force is quite complex and cumbersome. It is very common for a modification act to do things like removing a sentence from another act, a sentence that, in the meantime, has been changed by an urgent decree or another modification act. What is the final text of the modified act? How do you solve this? Or can you solve this? Or, which authority have you got to solve this?

This kind of "merge conflicts" require attention by a competent authority, either a court or a legislative body. Generally speaking, a resolution a merge conflict is an _authentic interpretation_ (http://en.wikipedia.org/wiki/Authentic_interpretation).

There are publishing houses that, for a quite big amount of money, will tell you "there is conflict here, these are the chances for interpretation A, these are the chances for interpretation B".

>>gioele+(OP)
That is exactly why gitlaw is needed. No act should be able to be voted into existence without merging with origin/master first. At last a new job for the Library of Congress.

>>harshr+n1
Go the opposite direction. Make changes to existing law, run a diff, convert the diff into "strike blah, insert foo" format, and that's your bill.

>>Dennis+UN
The EU parliament has an amendments systems that does exactly that: https://joinup.ec.europa.eu/news/european-parliament-share-a... .

>>gioele+(OP)
If there is a merge conflict isn't it the job of the legislators to actually resolve all the conflicts _before_ the bill is made law? Isn't this postponing of the resolution of problems an actual problem in the system that we have today? I would think it would be better to to have all conflicts resolved by the people who actually pass the law in the first place, and if there are unforeseen complications that have to be amended later by the courts, to have those legislators penalized in some form, or at least record it so we have a log of which legislators make bad decisions. If we had an easily trackable "git blame" it would go a long way to keep those people accountable and easily check this by the public.