Книга: Code 2.0
Responses for Code
Responses for Code
A second challenge is confronting the law in code — resolving, that is, just how we think about the regulatory power of code. Here are a number of ideas that together would push us toward a world where regulation imposed through code would have to satisfy constitutional norms.
Here again is the link to open code. In Chapter 8, when I described a kind of check that open code would impose on government regulation, I argued that it was harder for government to hide its regulations in open code, and easier for adopters to disable any regulations the government imposed. The movement from closed to open code was a movement from regulable to less regulable. Unless you are simply committed to disabling government’s power, this change cannot be unambiguously good.
But there are two parts to the constraint that open code might impose; one is certainly good, and the other is not necessarily terrible. The first part is transparency — the regulations would be known. The second part is resistance — that known regulations could be more easily resisted. The second part need not follow from the first, and it need not be debilitating. It may be easier to disable the regulations of code if the code is in the open. But if the regulation is legitimate, the state can require that it not be disabled. If it wants, it can punish those who disobey.
Compare the regulation of seatbelts. For a time the federal government required that new cars have automatic seatbelts. This was the regulation of code — the car would be made safer by regulating the code to force people to use seatbelts. Many people hated seatbelts, and some disabled them. But the virtue of the automatic seatbelt was that its regulation was transparent. No one doubted who was responsible for the rule the seatbelt imposed. If the state didn’t like it when people disabled their seatbelts, it was free to pass laws to punish them. In the end the government did not press the issue — not because it couldn’t, but because the political costs would have been too high. Politics checked the government’s regulation, just as it should.
This is the most we can expect of the regulation of code in cyberspace. There is a trade-off between transparency and effectiveness. Code regulation in the context of open code is more transparent but also less binding. Government’s power to achieve regulatory ends would be constrained by open code.
There is another benefit. Closed code would make it easier for the government to hide its regulation and thus achieve an illicit regulatory end. Thus, there is no simple defeat of government’s ends but instead a trade-off — between publicity and power, between the rules’ transparency and people’s obedience. It is an important check on government power to say that the only rules it should impose are those that would be obeyed if imposed transparently.
Does this mean that we should push for open rather than closed code? Does it mean that we should ban closed code?
No. It does not follow from these observations that we should ban closed code or that we must have a world with only open code. But they do point to the values we should insist on for any code that regulates. If code is a lawmaker, then it should embrace the values of a particular kind of lawmaking.
The core of these values is transparency. What a code regulation does should be at least as apparent as what a legal regulation does. Open code would provide that transparency — not for everyone (not everyone reads code), and not perfectly (badly written code hides its functions well), but more completely than closed code would.
Some closed code could provide this transparency. If code were more modular — if a code writer simply pulled parts off the shelf to plug into her system, as if she were buying spark plugs for a car — then even if the code for these components was closed, the functions and regulation of the end product would be open. Componentized architecture could be as transparent as an open code architecture, and transparency could thus be achieved without opening the code.
The best code (from the perspective of constitutional values) is both modular and open. Modularity ensures that better components could be substituted for worse. And from a competitive perspective, modularity permits greater competition in the development of improvements in a particular coding project.
It is plausible, however, that particular bits of code could not be produced if they were produced as open code, that closed code may sometimes be necessary for competitive survival. If so, then the compromise of a component system would permit something of the best of both worlds — some competitive advantage along with transparency of function.
I’ve argued for transparent code because of the constitutional values it embeds. I have not argued against code as a regulator or against regulation. But I have argued that we insist on transparency in regulation and that we push code structures to enhance that transparency.
The law presently does not do this. Indeed, as Mark Lemley and David O’Brien argue, the existing structure of copyright protection for software tends to push the development of software away from a modular structure. The law prefers opaque to transparent code; it constructs incentives to hide code rather than to make its functionality obvious.
Many have argued that the law’s present incentives are inefficient — that they tend to reduce competition in the production of software. This may well be right. But the greater perversity is again constitutional. Our law creates an incentive to enclose as much of an intellectual commons as possible. It works against publicity and transparency, and helps to produce, in effect, a massive secret government.
Here is a place for concrete legal change. Without resolving the question of whether closed or open code is best, we could at least push closed code in a direction that would facilitate greater transparency. But the inertia of existing law — which gives software manufacturers effectively unlimited terms of protection — works against change. The politics are just not there.
- Parsing Responses
- Forced writes - палка о двух концах
- Forced Writes
- Системные переменные ROWS_AFFECTED, GDSCODE, SQLCODE, TRANSACTIONJD, CONNECTIONJD
- Chapter 15. Graphical User Interfaces for Iptables
- Appendix J. Example scripts code-base
- What NAT is used for and basic terms and expressions
- Information request
- SCTP Generic header format
- System tools used for debugging
- FORWARD chain
- How to use this License for your documents