The always interesting James Grimmelmann has a new paper, Regulation by Software (.pdf), on how software relates to law. He starts by dissecting Lessig’s “code is law” argument. Lessig argues that code is a form of “architecture” – part of the environment in which we live. And we know that the shape of our living environment regulates behavior, in the sense that we would behave differently if our environment were different.
Orin Kerr at Volokh wrote about Grimmelmann’s paper, leading to a vigorous discussion. Commenters, including Dan Simon, argued that if all designed objects regulate, then the observation that software regulates in the same way isn’t very useful. If toothpicks regulate, and squeaky tennis shoes regulate, what makes software so special?
Which brings us to the point of Grimmelmann’s paper. He argues that software is very different from ordinary physical objects, so that software-based regulation is not the same animal as object-based regulation. It’s best, he says, to think of software as a different medium of regulation.
Software-based regulation has four characteristics, according to Grimmelmann. It is extremely formal and rule-bound. It can impose rules without disclosing what the rules are. Its rules are always applied and cannot be ignored by mutual agreement. It is fragile since software tends to be insecure and buggy.
Regulation by software will work best, Grimmelmann argues, where these four characteristics are consistent with the regulator’s goals. He looks at two case studies, and finds that software is ill-suited for controlling access to copyrighted works, but software does work well for managing online marketplaces. Both findings are consistent with reality.
This is a useful contribution to the discussion, and it couldn’t have come at a better time for Freedom to Tinker book club members.
I’m not convinced that Grimmelman’s distinctions between code-as-regulator and other-things-as-regulators are accurate. I suspect that many other designed objects could be argued to have each of the properties Grimmelman attributes to code.
But let’s put that issue aside for a moment, and assume that Grimmelman’s distinctions are accurate. I still don’t see what these particular distinctions have to do with the utility (or, in my view, the utter non-utility) of thinking about code as a regulator.
Remember, my (and others’) point was that lots of things, apart from code, can be thought of as regulators–but we generally don’t bother to think of them that way, because there’s no use in doing so. We don’t harp, for example, on the regulating properties of the design of tennis shoes. We think of tennis shoes as consumer items designed to please customers, or perhaps as fashion items designed to fit within an evolving stylistic culture, or as market products via which competing firms attempt to win market share. Sure, it’s possible to think of them as objects whose design “regulates” their wearers and sellers–as, indeed, it does. But that thinking just doesn’t lead to very interesting or useful conclusions.
Now, along comes Grimmelman to argue that code is different from tennis shoes in important ways. For example, Grimmelman points out that code is fragile and buggy–perhaps more fragile and buggy than other things, such as tennis shoes. Well, perhaps. But why would that lead anyone to find it more useful to think of code as a regulator?
The other properties may seem, on their surface, to offer more compelling arguments. For example, the idea (putting aside, for the moment, whether it’s true–I’m skeptical) that code “regulates” more surreptitiously than other designed objects might suggest that its regulatory effects deserve more attention than those imposed by other things. But a little further reflection reveals that this argument simply begs the question. After all, if the blatant regulation imposed by other designed objects is not worth discussing, then why would the subtle, hidden regulation imposed by code be any more worth discussing? The argument that these hidden regulating effects of code need to be exposed only works if you assume in advance that once exposed, they’ll be important. Otherwise, they’re curious but useless knowledge.
More generally, the whole discussion of code as a regulator–from Lessig’s book on–seems to me to be a huge exercise in question-begging. If you already accept the premises–and I think the real premises are a collection of concrete positions on social-political-legal issues such as intellectual property, open source software, internet architecture and a few others–then the “code is law” argument is a compelling “case” for your premises. But if you don’t accept the premises in the first place, or are undecided about them, then the whole argument simply collapses into earnest haranguing.
Grimmelman’s paper seems very sensible, but I can’t figure out whether he undercuts or reinforces his argument by pointing out that software works well for online markets in part because the software’s decisions can be overridden by mutual agreement (and in fact that the overall software architecture contains provisions for such overrides).
What seems to distinguish DRM and markets here is a factor that he mentions only tangentially, namely transaction costs in relation to the cost of goods. Few people will invoke eBay’s rollback procedures for a $5 or $10 transaction, because the cost of doing so is more than the value of the item. It’s only in the context of the low-cost software-mediated market that such transactions make sense at all. On the DRM side — at least for music and video — the value of any given piece of entertainmen purchased is generally so low that no mutual-agreement negotiation procedure would be cost-effective. Hence people’s decisions to either live with the DRM or to eschew purchase.
(Methods for overriding DRM software, whether by mutual consent or not, that apply to many pieces of entertainment in one shot are, of course, much more attractive from a transaction-cost point of view.)