Software Engineers as Legislators: Is Code Law?

The other day someone (perhaps a publisher's representative, or a colleague who thought I'd be interested in it) put in my mailbox a copy of David G. Post's new book In Search of Jefferson's Moose: Notes on the State of Cyberspace. Whoever did it was right to think I'd be interested. But rather than review the whole book (which tries to tie together cyberspace, Thomas Jefferson, a stuffed moose he went to great trouble and expense to have shipped to him from the U. S. to France, and a great variety of other matters), I would like to cogitate on just one idea from it: the notion that in cyberspace, "code is law."

The word "law" has at least two distinct common meanings. If I say, "You can't drive over 40 MPH on this street, it's against the law," the word means the set of rules enacted by a duly authorized governmental body. In a democracy the laws are presumably made by representatives of the people. In a dictatorship they're made by the dictator. But in either case they are human constructions. And when I say "can't" I'm not being strictly accurate. It's not physically impossible to drive faster than 40 MPH on that street, but if you do, you are liable to get caught and pay a fine.

The other important meaning of "law" is what we mean when we talk about the law of gravity, for instance: a natural principle that governs how the universe works. Try as you might, you simply can't defeat the law of gravity. It's part of the structure of the physical world. Obviously, we can do something about human laws—debate them, even change them if necessary—but all we can do about physical laws is try to understand them better so we can work within their constraints.

Which of these two meanings applies better to the idea that in cyberspace, "code is law"? That's actually a quotation in the book from Lawrence Lessig, a law professor who has written extensively on intellectual property in cyberspace. What he means is perhaps best illustrated by an example.

It turns out that embedded in the underlying "HTTP protocols" on which all web browsers run is a requirement for what is called a "referrer field." This is how Google gets paid for sending people to its advertisers' websites. The referrer field tells the advertiser that the visitor came from a Google site, and Google can collect their fee by using this information. The only way Google can do this, though, is by means of the "law" that allows for the referrer field.

If, way back in the beginning of hypertext and browsers in the 1990s, the engineers who wrote the HTTP protocols had neglected to allow for the referrer field, Post points out that Internet commerce would be very different. More specifically, millions of common transactions we are used to doing today would be impossible. What kind of law would make them impossible?

If you say that it's a physical law, like gravity, I will point out that the code enabling or disabling the referrer field was written by ordinary (more or less, anyway) human beings calling themselves software engineers.

But if you say it's just like a law on the books of a state or country, I will point out that unlike such man-made rules, it's not, strictly speaking, illegal to break "code laws"—but it just won't work. If you pretend there's a referrer field that isn't there, something very much like physical law intervenes to stop you, since you are denying a part of reality.

So the constraints and allowances imposed by the software structure of cyberspace borrow characteristics from both physical law and legislative law. This fact is underappreciated by at least two groups of people.

The first group is the software engineers themselves. I don't know why the early HTTP code warriors put that referral field in there, but making the founders of Google fabulously rich was probably not foremost in their minds. It probably served some minor technical function that paled into insignificance once the commercial possibilities of its use came to the fore. No one can foretell the future with perfect accuracy, but it would be nice if software engineers working in fields that are likely to influence the behavior and freedom, even, of millions of people, would at least realize that they are playing the part of legislators, usually without realizing it. Maybe a few of them do realize the broader implications of what they're doing, but it is a rare engineer who has even an average legislator's appreciation for the needs and wants of the public. That is one reason why so much software has annoying habits that make you want to go hunt up the guy who wrote it and give him a piece of your mind before you lose it on account of the software.

The second group, which includes practically everybody nowadays, is the public at large who uses, deals with, or is (sometimes) victimized by, software. You need to know that it is possible, at least in principle, for things to change, even in software. Unfortunately, when you look at the governance systems erected by those in charge of the Internet and allied software standards, they are typically as complicated as the software is. I have noticed that whenever engineers are left to themselves to design an organization, whether it's a five-person committee or something as large as the 300,000-member Institute of Electrical and Electronics Engineers, they will typically devise a legislative monstrosity with interlocking boards, districts, criss-crossing lines of authority, and other features that leave the outside observer with a general sense of not knowing quite who is in charge. It's hard even for technical people to get anything useful out of such organizations, and as for the general public—well, "forget it" is a tad discouraging, but the systems are usually not designed for ease of access by non-experts.

But as with any problem, people of good will can at least try to make things better. For you software engineers out there, try to think outside your little code box and consider the wider implications of your work, especially if you're fooling with stuff that millions of people will use. And as for the rest of us, if you ever get a chance to have some input on software design, take it and run. You stand a good chance of making cyberspace a better place.

Sources: In Search of Jefferson's Moose: Notes on the State of Cyberspace by David G. Post was published in February 2009 by Oxford University Press.