Showing posts with label code is law. Show all posts
Showing posts with label code is law. Show all posts

05 July 2010

Welcome to Open Source Law

Since, as Larry Lessig famously pointed out, "code is law" (and vice versa), it's natural to try to apply open source methodologies in the legal world. Indeed, a site called Openlaw existed ten years ago:


Openlaw is an experiment in crafting legal argument in an open forum. With your assistance, we will develop arguments, draft pleadings, and edit briefs in public, online. Non-lawyers and lawyers alike are invited to join the process by adding thoughts to the "brainstorm" outlines, drafting and commenting on drafts in progress, and suggesting reference sources.

Building on the model of open source software, we are working from the hypothesis that an open development process best harnesses the distributed resources of the Internet community. By using the Internet, we hope to enable the public interest to speak as loudly as the interests of corporations. Openlaw is therefore a large project built through the coordinated effort of many small (and not so small) contributions.

Despite this long pedigree, open source law never really took off - until now. As this important post points out:

The case of British Chiropractic Association v Simon Singh was perhaps the first major English case to be litigated under the full glare of the internet. This did not just mean that people merely followed the case’s progress on blogs and messageboards: the role of the internet was more far-reaching than this


Crucially:

The technical evidence of a claimant in a controversial case had simply been demolished - and seen to be demolished - but not by the conventional means of ­contrary expert evidence and expensive forensic cross-examination, but by specialist bloggers. And there is no reason why such specialist bloggers would not do the same in a similar case.

The key thing is that those bloggers need to be engaged by the case - this isn't going to happen for run-of-the-mill litigation. But that's OK: it means that when something important is at stake - as in the Singh case - and their help is most needed, they *will* be engaged, and that wonderful digital kraken will stir again.

Follow me @glynmoody on Twitter or identi.ca.

14 February 2008

Code is Law is Code

Code and law have been inextricably mixed ever since Richard Stallman drew up the first GNU GPL. Indeed, in many ways, the logical processes for crafting both are similar - which is probably handy. Nonetheless, law does present special problems that hackers need to be aware of.

To provide some help, the Software Freedom Law Center has just put together a useful legal issues primer for open source and free software projects:

This Primer provides a baseline of knowledge about those areas of the law, intending to support productive conversations between clients and lawyers about specific legal needs. We aim to improve the conversation between lawyer and client, but not to make it unnecessary, because law, like most things in life, very rarely has clear cut answers. Solutions for legal problems must be crafted in light of the particulars of each client’s situation. What is best for one client in one situation, may very well not be best for another client in the same situation, or even the same client in the same situation at a later date or in a different place. Law cannot yield attainable certainty because it is dynamic, inconsistent, and incapable of mastery by pure rote memorization. This is why we do not provide forms or other tools for “do it yourself” lawyering, which are almost always insufficient and, in fact, can be very harmful to a project’s interests.

The specific topics addressed herein are:

1. copyrights and licensing,
2. organizational structure,
3. patents, and
4. trademarks.

They are presented in this order because that most closely aligns with the life-cycle of the legal needs of a typical FOSS project. When code is written, copyrights immediately come into being. The terms under which the owner of those copyrights allows others to copy, modify and distribute the code determine whether it is considered “free” and/or “open source.” Once a project gains speed, many benefits can be achieved by the creation of an organizational entity for the project that is separate from the project’s individual developers. After successful public release of a project, patent and trademark issues may arise that need attention.

11 December 2006

Larry's New Code

As the author of two books with the word "code" in the title, I naturally gravitate to other tomes that also draw on this word. But Larry Lessig's Code is rather special: it's one of the definitive texts of the Net age. I remember reading version 1.0, when it came out; and now, following a suitably wikified genesis, here's Codev2. (Via Michael Geist's Blog.)

10 December 2006

Code is Law, Code is Power

Yup:

Ministers were today urged to consider abandoning the multi-billion pound Joint Strike Fighter project unless the United States agrees within weeks to share sensitive technology.

...

Ministers have previously threatened that the UK could pull out of plans to buy up to 150 of the military planes for the RAF and Navy unless America agreed to transfer secrets about its software that Britain argues are needed in order to operate and maintain them independently.

07 January 2006

Code is Law, Code is Politics

As Lawrence Lessig famously noted, Code is Law. Which means that Code is Politics, too, since laws are drawn up by politicians. But the intimate relationship between code and politics is becoming manifest in a rather different context (pity about the yellow on black text).

The issue here is about the software used in voting machines. Since, one day, all voting will be carried with such machines (unless we decide to go back to using ostraca), now is the time to consider why free access to the code that runs them is indispensable for political transparency.

It comes down to this: if you are dealing with a black box, you can have absolutely no faith in the results it produces. It might just make them up or - worse - change them subtly, or perhaps be pre-programmed to crash if a particular party gets too many votes, requiring a complete re-run, with knock-on effects on voting patterns.

If you have the source code you can run it and examine what it does with various voting inputs, and check that it has no nefarious sub-routines. However, even this is not enough for full confidence in the voting machine: paper audits are also indispensable for checking on the consistency of the outputs, and allowing for the ultimate fall-back - counting by hand.

Still, this is a clear instance of where, in a literal rather than metaphorical sense, closed source jeopardises the very basis of democracy. Looks like RMS was right.