The point is simple, but its implication is profound. To the extent that code is open code, the power of government is constrained. Government can demand, government can threaten, but when the target of its regulation is plastic, it cannot rely on its target remaining as it wants.
Say you are a Soviet propagandist, and you want to get people to read lots of information about Papa Stalin. So you declare that every book published in the Soviet Union must have a chapter devoted to Stalin. How likely is it that such books will actually affect what people read?
Books are open code: They hide nothing; they reveal their source — they are their source! A user or adopter of a book always has the choice to read only the chapters she wants. If it is a book on electronics, then the reader can certainly choose not to read the chapter on Stalin. There is very little the state can do to modify the reader’s power in this respect.
The same idea liberates open code. The government’s rules are rules only to the extent that they impose restrictions that adopters would want. The government may coordinate standards (like “drive on the right”), but it certainly cannot impose standards that constrain users in ways they do not want to be constrained. This architecture, then, is an important check on the government’s regulatory power. Open code means open control — there is control, but the user is aware of it.[25]
Closed code functions differently. With closed code, users cannot easily modify the control that the code comes packaged with. Hackers and very sophisticated programmers may be able to do so, but most users would not know which parts were required and which parts were not. Or more precisely, users would not be able to see the parts required and the parts not required because the source code does not come bundled with closed code. Closed code is the propagandist’s best strategy — not a separate chapter that the user can ignore, but a persistent and unrecognized influence that tilts the story in the direction the propagandist wants.
So far I’ve played fast and loose with the idea of a “user.” While some “users” of Firefox could change its code if they didn’t like the way it functioned, the vast majority could not. For most of us, it is just as feasible to change the way Microsoft Word functions as it is to change the way GNU/Linux operates.
But the difference here is that there is — and legally can be — a community of developers who modify open code, but there is not — or legally cannot be — a community of developers who modify closed code, at least without the owner’s permission. That culture of developers is the critical mechanism that creates the independence within open code. Without that culture, there’d be little real difference between the regulability of open and closed code.
This in turn implies a different sort of limit on this limit on the regulability of code. Communities of developers are likely to enable some types of deviations from rules imposed by governments. For example, they’re quite likely to resist the kind of regulation by the French to enable the cracking of financial safety. They’re less likely to disable virus protection or spam filters.
Where This Leads
My argument so far has taken a simple path. In answer to those who say that the Net cannot be regulated, I’ve argued that whether it can be regulated depends on its architecture. Some architectures would be regulable, others would not. I have then argued that government could take a role in deciding whether an architecture would be regulable or not. The government could take steps to transform an architecture from unregulable to regulable, both indirectly (by making behavior more traceable) and directly (by using code to directly effect the control the government wants).
The final step in this progression of regulability is a constraint that is only now becoming significant. Government’s power to regulate code, to make behavior within the code regulable, depends in part on the character of the code. Open code is less regulable than closed code; to the extent that code becomes open, government’s power is reduced.
Take for example the most prominent recent controversy in the area of copyright — peer-to-peer filesharing. As I’ve described, P2P filesharing is an application that runs on the network. Filesharing networks like StreamCast are simply protocols that P2P applications run. All these protocols are open; anyone can build to them. And because the technology for building to them is widely available, whether or not a particular company builds to them doesn’t affect whether they will be built to — but demand does.
Thus, imagine for the moment that the recording industry is successful in driving out of business every business that supports P2P filesharing. The industry won’t be successful in driving P2P out of existence. This is because open code has enabled noncommercial actors to sustain the infrastructure of P2P sharing, without the commercial infrastructure.
This is not, obviously, an absolute claim. I am discussing relative, not absolute, regulability. Even with open code, if the government threatens punishments that are severe enough, it will induce a certain compliance. And even with open code, the techniques of identity, tied to code that has been certified as compliant, will still give government plenty of power. Thus, much of the argument from Part I survives this point about open code — if the world becomes certificate-rich, regulability still increases. The same conclusion follows if more code were burned into hardware rather than left to exist as software. Then, even if the code were open, it would not be modifiable[26].
But when designing an architecture for cyberspace, the margins matter. The values of a given space are not only the values of speech, autonomy, access, or privacy. They may also be values of limited control. As John Perry Barlow puts it, they are the values of a certain bug being programmed into the architecture of the Net — a bug that inhibits the power of government to control the Net perfectly, even if it does not disable that power entirely.
For some, the objective is to build code that disables any possible governmental control. That is not my objective. I certainly believe that government must be constrained, and I endorse the constraints that open code imposes, but it is not my objective to disable government generally. As I’ve argued already, and as the next part makes plain, some values can be achieved only if government intervenes. Government has a role, even if not as substantial a role as it would wish. We need to understand this role, as well as how our values might be advanced in the context of the Web.
One constraint seems clear in this account. As I argue more extensively later in the book, even if open code does not disable government’s power to regulate completely, it certainly changes that power. On the margin, open code reduces the reward from burying regulation in the hidden spaces of code. It functions as a kind of Freedom of Information Act for network regulation. As with ordinary law, open code requires that lawmaking be public, and thus that lawmaking be transparent. In a sense that George Soros ought to understand, open code is a foundation to an open society.
Even this is an important — some might say an essential — check on the power of government. But whether or not one is for transparency generally, my aim so far is just to map out the links. Regulability is conditional on the character of the code, and open code changes that character. It is a limit on government’s power to regulate — not necessarily by defeating the power to regulate, but by changing it.
25.
For an argument to the opposite conclusion, see Stephen M. McJohn_,_ "The Paradoxes of Free Software,"