This is one of those ideas that gets suggested on a frequent basis. Those who suggest it often think that the problem is one of complexity management, like managing source code changes.
The actual problem is one of power and intention. Yes, version control would make earmarks obvious. Yes, it would make tracking contributors (lobbies) easier. Yes, it would make tailoring tried and trusted legal documents easy.
All of these are reasons why version control will never be applied to the law. We want these things, but we are not the customer. The real customer is actively trying to prevent these things from ever happening.
The reality is that these tools are probably already being used for these exact purposes - in private, and for personal gain.
I've had similar thoughts, but I would never voice them.
I even registered gitlaw.us a few years ago and then let it expire because I couldn't bridge the impedance mismatch between the idea and the implementation.
But again, I would never voice such thoughts, for many reasons:
1. It's exactly the attitude that your 'real customers' want in the public - learned helplessness.
2. You start believing it, and there is an insidious, negative effect on your judgement, decisions, and life. I'm not saying be a rose-tinted-glasses optimist, but don't be the opposite extreme either.
3. It is possible to win. Remember Gandi, Mandela, etc. Imagine how bleak their outlook was, yet they remained committed, steadfast, relentless, constant as the dawn, and eventually the time came for their ideas and there was nothing more powerful or unstoppable.
4. Real hackers aren't like that. The bigger the problem, the bigger the opportunity for disruption and making the world better. There are few bigger than this.
It takes efforts like these to eventually make the time come for the ideas that change the world, so it behooves us all never to talk them down out of mere pessimism. Constructively criticize yes, but no shootdowns.
Remember, first they ignore you, then they ridicule you, then they fight you, then you win.
I agree 100%, but I think that's only the short view-- the extant governments aren't going to be around forever, and in the long run we need smart people to spend time thinking about how to structure a government that's learned from our mistakes.
Of course we won't see Congress outlaw lobbying, but there's definitely an opportunity today to try some of these concepts in an organization, community, or even willing local government.
Sure, you explain quite well why there would be resistance to such an idea as this.
However, in the 200+ year history of the United States Congress, no tool like this has existed that could bring the kind of transparency to the process that reformers have been pushing for for nearly as long.
It is one thing to say "We need more transparency!" It is another thing entirely to say "Publish all bill modifications with attribution using a public version control system!" Having something specific and concrete to push for, something the implementation of which can be said to be completed or not completed in definitive terms, can make the difference between a successful push for reform and an unsuccessful one.
Thank you for your cynicism, it's super productive. Let's not discuss or try to improve upon the idea. Let's just tell him why we think he's wrong.
/rant
Continuing with OP's thought. Making the legislator who introduces the bill commit the bill would be an awesome piece of information and might make some legislators think twice about what they introduce and how they title it. And all the statistics that could be run on a repo of laws would be a ridiculously useful resource.
Yes, the wizards are disincentivized to let the people pull back the curtain, but as stated here, that's no excuse for not trying.
A separate problem, however, is that this is essentially a process improvement, that doesn't generate much advantage to the person who makes it happen. A politician would need to use significant personal resources to push this type of reform through the system, yet the 'payoff' is probably minimal compared to substantive policy or constituent service activities. By raising the issue from process improvement to substantive issue, the chances of implementation improve. Discussing and spreading the idea is valuable in that light.
On a side note, once these types of distributed systems begin to take root, it becomes quickly apparent that co-location in Washington is of at least questionable value. (Look at the attendance records of members at Congressional hearings.) Virtually everything that Congress does can be accomplished without the need for the massive physical and personnel support system found at the Capitol. It would be interesting to see how government would be designed given the communication tools available today.
Except, you know, that all proposed legislation is publicly posted to the Thomas system with 24 hours of submission (i.e., prior to voting), all legislative hearings and regulatory hearings are open to the public, and...get this...legislative debates and major agency events have been publicly televised for more than two decades on not one, but 3 separate channels!
The reality is that most of the people who complain about the lack of transparency are those who put the least effort into finding the available sources.
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.
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.
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.
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.
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.
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.
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.
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.
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?
"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".
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.
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.
I've dreamed up something like this as well and realistically there isn't anything preventing us from using git to manage our laws. As a strawman to beat up, here is an example of how it could work:
git clone legislature/generalstatutes
s/marijuana/sugar/g
git commit -am "Turn sugar into a controlled substance."
git request-pull
Legislators
If interested, # git branch bill_12345
git pull nathanhammond/generalstatutes
// Continue editing the "Sugar as a controlled substance" bill.
Spin off to committee (read/write to committee members)
git clone legislature/generalstatutes
git checkout bill_12345
// Continue editing the "Sugar as a controlled substance" bill.
git commit -am "Committee updates."
Take a vote for leaving committee.
If successful, # git request-pull
General legislature takes a vote.
If successful, # git merge bill_12345 master --signoff (Legislators that voted for it.)
Benefits:
- Encourages broader participation in democracy.
- Cryptographically signed. We'll know if you voted for or wrote it.
- Tracks history of all changes (at least at the commit level). If something comes out of committee very different from how it went in you can easily find every change.
- Makes it easier for newspeople to identify how the law is changing.
- An interface like GitHub over top of the repository could hide all of the complexity, allow for line-by-line comments, and general comments.
- Registering to the interface with your voter ID could allow for representatives to identify or poll constituents.
Problems:
- Requires behavioral change for legislators who I would not necessarily classify as "early adopters."
- Still possible to "launder" the creator by having somebody else make the changes for you.
Won't change anything. It's proposing a technical solution to a people problem.
Right now laws are openly available, but people don't care enough to get look into them. Also, just because you have "git blame" doesn't mean you'll now magically be able to see what corporate lobbyist wrote the law, because they'd just ask the legislator to commit it instead. Wouldn't change anything.
but at the same time it is kind of a technical problem.
one big reason why people don't look at the laws is because they get changed all the time without a transparant way to see what ends up getting changed right before a vote. something like gitlaw would allow people, and lawyers, to track changes to laws much easier.
adoption is definitely the problem, but this can help lawyers make proposals and counterproposals with the speed of software developers, which may give lawyers a reason to sign on.
Unfortunately, the key challenge with the problem isn't architecting a DVCS-like service for legal documents (for an MVP, you could easily get by simply designing a novel frontend to git), it's an adoption problem. The current system is flawed, yes, but merely offering a superior product for less money isn't enough to make a dent in the bureaucratic nightmare of modern-day Washington.
Adoption isn't the problem. We don't need Congress to use such a system initially; we need bills, the US Code, etc. mirrored on Github. When it's there, people will get it. The information is out there, it just needs to be processed into a usable form so that it works with Git. And it'd take millions of dollars, and have no conventional ROI, so no one's going to do it.
>And it'd take millions of dollars, and have no conventional ROI, so no one's going to do it.
Your pessimism is unwarranted. There is already one user on GitHub that scrapes the US Code and mirrors it. He even tags
the changes so you can diff them quite easily.
It also wouldn't have $0 ROI because there are people who will pay for advanced services built around the law-making process.
Here's an example of a service built on Ontario laws (disclosure: I made it): www.ontariomonitor.ca. It emails people when a bill passes a committee or when new laws are introduced (+ lots of other stuff).
The question is how up-to-date the bill texts are. I doubt it can tracks in real time with changes/amendments voted on, etc. but then again any system bolted on the process as opposed to being fundamentally integrated into the process wouldn't be.
Adoption is the problem. The US Code already is on GitHub — https://github.com/divegeek/uscode — but it's only a mirror. There's also the Sunlight Foundation's OpenCongress http://www.opencongress.org/ which provides a nice way to track a bill and its participants. But without the authors actually using something like git in their process of writing the laws, this doesn't really help people participate directly.
In addition to this being first and foremost a political/people problem as many have pointed out, the technical challenges of applying standard CMS and document management solutions to legislation environments are pretty much unknown or underestimated by most of us. For those interested, Sean McGrath has posted a series of posts addressing some of these challenges: http://seanmcgrath.blogspot.com/2010/05/xml-in-legislaturepa...
May I suggest that code wins arguments? If this is a better way to do things, than starting with a small town that's about to incorporate could demonstrate that this could work.
I basically agree with everyone pouring cold water on this as far as reforming the statute law system is concerned. That is a much more entrenched problem than any computer system is going to solve overnight.
However, I do see a niche for DIY contract law. Sort of like Nolo Press on steroids. Where you can browse standard contracts and then modify them to suit your needs in a visible and traceable way. Or possibly for contract negotiations, where each party makes changes. This would keep track of history in a neutral and verifiable way. (Could save time and errors for individuals and small law firms....)
You can use GitHub for legal documents already. Just convert your documents to markdown. We put our TOS and Privacy Policy on Github from launch: https://github.com/everyme/everyme-legal
We haven't had any issues or pull requests recently but we would welcome them for sure.
This is a fine goal, however, beyond what other have said here, it's important to realize that a lot of "laws" or "rules" that impact individuals on a day to day basis are not created by Congress at all--in fact, they're created via administrative agencies through rulemaking processes (see http://en.wikipedia.org/wiki/Rulemaking). This is where the "rubber meets the road" of actually implementing broadly worded language that Congress has passed, and how these rules are promulgated can be vastly different from how Congress operates. For one, administrative agency rulemaking is almost always open to public comment and, by law, these agencies are obligated to take into considerations comments left by the public.
In a number of ways the process is more open and participatory than legislative law making, and, as mentioned, the regulations passed often have more of a direct impact on day to day life. There are a number of solutions out there that are attempting to make this process more transparent and participatory: for example, http://regulationroom.org/ (operated by a clinic at Cornell law school). In my opinion, informing the public of the importance and participatory nature of rulemaking (and getting more people involved) is probably a more realistically achievable goal than the proposed solution, and would likely have more tangible effect.
It makes a lot of sense for there to be a standardized, open framework for document management in general outside of source code. So many industries could improve their processes and transparency through tools like Git and services like GitHub, but they would need to be made a lot simpler than GitHub's UI. Their site has some great stuff going for developers, but scares away a few designers I know. I'd love to see a site/app like that get made.
Neat idea, but is it currently really a problem to tell who has written what part of a law? Isn't this public information already? If not, then this isn't a technology problem, and it will not be easy to convince our congresscritters to keep track of who writes precisely what. And what about sections of law with shared credit, or law that comes from a committee that didn't unanimously agree, etc.
I know very little about how law is written, but my impression is that most people who pay attention to it are more concerned about the large ideas than the exact wordings - that's how you have politicians voting on bills when they haven't read every word. How can they when it's thousands of pages long?
So this might be more useful to a small number of politicians and lawyers who are examining law closely, looking for loopholes, or concerned about the exact details of a particular statement's pedigree, but I don't really see the general appeal.
I would rather have a tool which provides similar information, but on a higher level. An independent overview in layman language, general information about how it came about, how it's significant historically or with respect to existing law, and with the option to drill down to the actual language and gritty details. Of course, this would take much more work to build and maintain. I've been a fan of opencongress.org but I've found that switching between opencongress and wikipedia is the most effective way to understand the context and significance of a bill.
Reading the actual text of a law is usually about as useful to me for determining its implications as reading the source code of a printer driver would be to my dad for figuring out how to install a printer.
Bills used to not be 1000 page tomes. Special interests usually cause that bloat by lobbying for exemptions or credits in special circumstances. There's no real reason it has to be 2000 pages, it's not going to be three pages either though.
GitLaw, if implemented, would be a significant improvement over law by gits -- which is what we have now.
Unfortunately, I don't think the problem (with Congress) is technological. If GitLaw were implemented, a lobbyist wouldn't be making a pull request directly, they'd influence someone to do it for them so it wouldn't be traceable -- which is pretty much the way it works now.
It hasn't morphed, we just don't market it on the homepage as "GitHub for Legal Docs" since lawyers and the general public have no idea what that is. But it is open-sourced legal docs, with versioning, diffs and a Github-style ownership/branching model.
"A distributed, open-source platform for the collaborative evaluation of information. It will enable sentence-level critique of written words combined with a sophisticated yet easy-to-use model of community peer-review. It will work as an overlay on top of any stable content, including news, blogs, scientific articles, books, terms of service, ballot initiatives, legislation and regulations, software code and more-without requiring participation of the underlying site.
"It is based on a new draft standard for annotating digital documents currently being developed by the Open Annotation Collaboration, a consortium that includes the Internet Archive, NISO (National Information Standards Organization), O'Reilly Books, Amazon, Barnes and Noble, and a number of academic institutions.
I've been eagerly waiting to see what comes out of this group for a while now. The principles seem great, but I think they should apply their 12 principles to the initiation phases, as well. It's currently hard to discern from their site what their short term goals are or even where they currently are in the process.
Seems like an enormously positive effort, but I'm remaining skeptical. I wish that they had more public dialogue of what they're doing and more demonstration of getting the general public involved early. Plus, I think their approach may be too grandiose and top down.
I would like to see it first applied effectively at the grassroots. For instance, can the model successfully be applied to a small collective? If that's possible, then try to scale it to city, state, nation, and globe. Also, do they really need funding first to start rolling forward toward some of their objectives? There seems to be a lot of passion in this space and a lot of smart people willing to work for free now, with the right leadership.
I don't see how hypothes.is has anything to do with this... that project seems to be about annotating any content. (And incidentally, universal annotation systems are paradigmatic chicken and egg problem; people keep trying to do this and it never reaches broad adoption).
Github for law is a much more modest and realizable idea, by comparison.
Hypothes.is annotations are great for legal content, and are similar to the stated goal of the GitLaw project -- namely to see how the laws are created, modified, debated, and by whom.
Abe, interesting idea and one I would like to run with. @nicholascloud, you make a good point about the “baby-sitting” of documents but I believe it can be resolved by crowd-sourcing the project with a “vested” membership interested in seeing the project succeed. This would also allow for controlling the abuse of the site by spammers. One part of the project would be converting the bloated material into something readable for the average participant. Because the material editor will be working on something he, or she is interested in then it would be a labor that they would happily engage in.
@michael, you make a valid point but I believe a crowd-sourced vested individuals like Wikimedia would work in keeping the problems at bay.
@tobi, I would suggest that the concept be kept private and not government controlled as any government initiative would only create a bureaucracy that would stifle innovation and open discourse.
My country, Mexico is going through a national referendum right now with the drug war as a backdrop and part of the drama. Although it is a national election I call it a referendum because the results will give an insight into what our country wants in terms of dealing with the narco-types. Will we continue with the strategy, increase the engagement or back-off and let them do as they please?
My original idea was to crowd-source political commentary/analysis but your post is making me expand the concept to include your idea.
The initial countries I would like to include are the United States and Mexico as I have a basic understanding of their political processes but I would love for it to include as many countries as possible.
I noticed that there is a lot of interest in this concept/idea and therefore I want to officially put out a call for those interested in forming such a site. I am willing to put up server space, domain name (polit.co) and initial programming. With Abe’s permission and hopefully, his participation I have a created a Twitter handle @polit_co to start the organizing. I look forward to everyone’s participation. Let’s get this going.
Great idea, and seems to be a relatively wide-spread one, at that. But, as others have mentioned, it faces steep adoption challenges.
I recommend taking a look at Rogers' 5 Factors of Adoption [1] as a starting point. It would be extremely challenging to get this approach adopted from the top down, especially in an entrenched democratic system. Instead, a less risky approach may be to first get it successfully applied at the small scale. For instance, can you get a small township/incorporation to adopt this method?
I'm working on a project called http://makeyourlaws.org. It's open source and non profit. Simply put, it's a practical project that aims to completely replace existing legislatures with online liquid democracies, through incremental steps within the existing legal system that have real teeth all the way. No waiting for a revolution and no begging. Read the site & its G+ page for details.
In particular having a git for laws is going to be a necessary backend system — along with e.g. pretty diff, blame, mass import, in-browser editor, simple markup language for laws, etc.
MYL is not git-based as it were — the policy authoring process is discussion- and voting-based, as it's a fundamentally different process than code authoring — but once it does get to being about laws, git is a good model.
There are of course also a number of other subprojects within MYL, like legal identity verification, empathy-creating discussion systems, factchecking, privacy-preserving voter-verifiable auditable-in-aggregate cryptographic vote proofs, etc etc.
I've been doing version management of law for 10 years. As Gioele said, (Hi Gioele!) it is a very very hard task to tackle. The problem is the 200+ years of tradition that you must drag along. In a prior life I've done version management for CAD data and software data. Those are both much simpler problems, largely because changes in procedures are so much easier when you don't have such a large legacy. As someone said, legislation is all about patching the law - although the more polite term is "amending" the law. While I have built and deployed a system to automate the generation of amendments and the compilation of law, building such a system to the more general case is mind boggling. For this to be accomplished, there is going to have to be a lot of buy-in from the legislatures themselves for they are going to have to be willing to change. That is the challenge - change at that level is a bit glacial. In the meantime, I am writing an HTML5 based legislative editor to at least get some substance behind the idea - it's at http://legalhacks.org. I'll post a video on how it works tomorrow. It's still a bit fragile too - this stuff is hard.
Why don't we instead build a "Startup Law Standard" kind of thing that can get network effects in the startup scene. Get all the big firms law firm / VCs / angels / etc. signed on to these standards.
How would this look? I've read a lot of contracts, and you see some similar stuff. In many ways, it's kind of like programming:
VARIABLE DEFINITIONS: at the top - like: "'Company' shall be XYZ, Inc., a Delaware Corporation located in 100 Main St.", and so on.
TESTS: These are normally "Warranties and Representations" - these are often quite boiler-plate like: "Assignor is owner of all Intellectual Property", etc.
AUTHENTICATION: Signatures, etc.
I bet that 80-90% documents could be generated by a set of 500 boiler-plate sections with fill-in-the-blank type of stuff. There could be built into these something that'd figure out the incompatibility (i.e. "exclusive" in one section wouldn't work with "non-exclusive" in another).
Term Sheets are pretty standardized now with a couple made forms that are considered modern. Why can't we do the rest?
Call me crazy, but couldn't this at the very least reduce law costs, and at best be the first step down a road of nearly full-auto law?
I hate to break it to you, but most of the legal documents you pay for are already standardized. They have been for years (or decades, depending on the area of law). You're paying for the customizations that are specific to your situation.
Obviously, standardized language has done nothing to reduce costs. The problem is supply-side: despite the glut of (new) lawyers, there are still not enough lawyers that people are willing to trust with their business.
Well I know that - I'm asking why can't it be codified more so it's more consistent and able to be interacted with. The issue with lack of "trustable" lawyers could perhaps be improved by such a tool?
This can be done, and in fact there is a business in it too: an open source competitor to Lexis and Westlaw. Data entry is bound to be a problem, as no-one is going to want to give up electronic data, but I for one would be willing to spend a few hours a week transcribing documents at the local courthouse.
You might enjoy the free legal data service offered in Canada that has most of the cases that you can find on Westlaw/Lexis: canlii.org. It could be more open, but it's free and works well.
I like the idea. I've been wanting to do something similar for the laws here in Denmark, but getting good data is tricky.... Strangely enough.
My reasoning is that I feel that politicians are constantly filling with existing laws and the changes are conveyed via strang legal terms, e.g. "This changes "they to us in paragraph five, section 2, line 3". This is a complete bullshit way of informing the public about the changes to our laws. If laws where tracked the same way we as developers track our code, hiding even minor changes would be impossible. Just imagine getting a daily / weekly change log for the laws passed by your government. Even our lazy journalists should be able to dig up something in appropriate every now and then if they knew what changed.
For anyone interested in this idea, check out legalhacks.org and join us for a hackathon at UC Hastings on May 19, to mark up legislation and discuss metadata standards for legislation. internationallegislation.eventbrite.com
Having legislative markup is necessary for any git-like system, because of the complex ways that amendments are currently made.
We'll be joined at the hackathon by Grant Vergottini, a member of the LegalXML OASIS committee, and the person who built the legislative editor that California uses.
As many people here have commented, adoption by legislatures of
How do we start doing this? Is anyone willing to put some time to build this? Of course this would be non-profit. Maybe if we get enough people interested, we can start pressuring different organization to help us (Wikimedia comes to mind).
There would be a need for people writing the laws into text and coders for implementing different aspects. Maybe crowdfunded. I don't know, just throwing ideas to see if anyone is interested.
We don't need the government to do this. We have the data (or most of it). We need to start changing it from the outside.
We're missing the point I think. A site like this wouldn't be a way to combat lobbyist. It would be a way for citizens to become the lobbyists. If a site like this did pop up, it would eventually be dominated by a voice leaning a certain way. So, this is not a one-site-fixes-all type deal. This format could be a way for citizens to collaborate with other like-minded citizens and write legislation of their own.
In 2007, New Zealand experimented with a public wiki to collect input for a revision to the Policing Act laws. In 2008, the wiki would be reviewed by a parliamentary committee. I'm not sure what the outcome was, but the wiki itself is now offline.
> It looks like there is an existing project
> called Legal-RDF that was created to add
> semantic data to digital legal documents,
> but it’s XML and therefore not very readable.
RDF has several other formats besides XML (turtle being one of the more human readable formats).
I volunteer at the Public Knowledge Foundation (an Israeli version of The Sunlight Foundation), we develop and maintain oknesset.org (like opencongress.org). For the past couple months we've been researching the possibility of representing Israeli law as a git repository, so that oknesset.org can visualize the diff to a law a bill proposal represents, and track it as a branch until it is merged into law. Since Israel is a relatively young and small country the number of laws and changes is orders of magnitude smaller than most western/democratic countries which publicize the legislative process. Israel's legislative branch is unicameral so the process itself is relatively straightforward; supposedly we'd be a good test case. We already have quite a lot of insight but in general it seems that git (and generally, any VCS) has significant impedance mismatch with the legislative process, specifically regarding the ability to compile/link all the different laws into one comprehensive database representing the law. One prominent example is the existence of multiple timelines of ratification. There are at least three dates relevant to the ratification of bills:
1. Date of third (and final) vote = the date the parliament has voted a bill as law
2. Date of publication (for technical reasons this might not coincide with the vote date)
3. Date of validity - a bill is usually passed with a date of validity, between the date of publication and validity the bill is not formally law yet. Sometimes there are separate dates of validity for separate parts of the bill. To make matters more complicated, dates of validity can be changed when the bill designates government ministers with the authority to change them (the dates).
Also, in Israel many laws never "make it" to their date of validity since the yearly Law of Arrangements (http://www.knesset.gov.il/lexicon/eng/hesderim_eng.htm) decides which laws passed in the previous year have proper funding, such that officially some laws get "punted" into the future, possibly indefinitely. It gets quite confusing because from a legal point of view, the dates that are relevant to the justice system (as in, when a bill is relevant or not to the court) are usually the date of voting, whereas when it comes to government the third date is the important one.
We are still moving forward with our initiative, but it seems that for now there are no version control systems which are a good solution to the law management problem.
Having worked on actual legislative and regulatory amendments, this would be useful simply for collating input of stakeholders. One example would be regulatory comment periods.
Not very (I maintain a nice iPhone app that front-ends the data on legislation.gov.uk): the data on legislation.gov.uk is useful for Joe Public, but when it comes to the actual practice of the law is woefully incomplete. This is purely down to a lack of interest and funding on the Government's part, as well as vested interests by people who publish law and charge for it.
There is no free source of up-to-date UK law: many of the statute on legislation.gov.uk is not guaranteed to be up to date, and if you're looking to practice this is obviously no good at all. This is in itself very sad. The people who run legislation.gov.uk do a fantastic job, and hopefully access will get much better in the future.
I think there will come a time when people will look back and find it quaint and impractical that we tried to interpret our massive legal system by hand, rather than leaving that sort of thing to computers.
or how about Lojban? That way it can be machine readable, unambiguously queried, culturally neutral and actually be a language designed for human communication.
The actual problem is one of power and intention. Yes, version control would make earmarks obvious. Yes, it would make tracking contributors (lobbies) easier. Yes, it would make tailoring tried and trusted legal documents easy.
All of these are reasons why version control will never be applied to the law. We want these things, but we are not the customer. The real customer is actively trying to prevent these things from ever happening.
The reality is that these tools are probably already being used for these exact purposes - in private, and for personal gain.