TCG principles and the meaning of control
The comments on TCG's best principles document that I wrote for EFF are now up on the EFF site.
Here is a passage I wrote that didn't make the final cut. I was talking about what it means to have "control" of a computer.
Presumably there is a continuum here, in the sense that someone could argue that "control" of a computer shouldn't stop at the mere option to program it, but should extend to redesigning the functions implemented in its hardware. Such a person would presumably complain that AMD, Intel, and Transmeta know how to alter the microcode inside CPUs after the point of retail sale, but refrain from sharing all the details with the public, even though doing so would expand computer owners' control over the instruction sets their microprocessors implement. In a layered system, it is true that owner control will always be partial at some layer -- if only because computers are implemented in the physical world and our control over that world is subject to fundamental limitations.
This reminds me of the question of "equivalent access to modify" that I and others brought up in a discussion some time ago about the GNU GPL and embedded software. The GPL uses an ingenious concept when defining source code: "The source code for a work means the preferred form of the work for making modifications to it." That definition is ingenious because it isn't at all specific to the technology used to create the work. The source code to my TCG principles comments, for example, is a LaTeX file (and an Adobe Illustrator file and an OmniGraffle file, which were both converted to EPS and then to PNG before ending up inside the PDF above).
Now, this is pretty amazing. The GPL's broad definition of "source code" automatically implies that the source code for that PDF includes the two OmniGraffle files, even though OmniGraffle hadn't even been written when the GPL was drafted (and even though the GPL was meant to apply to software works rather than to other kinds of literary works).
The GPL's defintion of "source code" is a structural definition: it suggests that there shouldn't be anyone who has more privileged access to modify a software program than any of the software program's end-recipients does. Some people then worry about how this principle extends to embedded software. When embedded software is published under the GPL, vendors may provide CDs of source code along with the devices that contain object code -- or sometimes they provide written commitments to provide such CDs, or make downloads available (which FSF doesn't think constitutes a "medium customarily used for software interchange").
The result is that you can modify the software, but not necessarily the software within any particular device. So you might say that embedded devices tend to erase the structural equality between all parties that the GPL establishes for software published for computers. There is somebody who has a more privileged kind of access to modify the software within a device than even the owner of the device does. So for example, you might ship a PVR that contains only GPL-covered software, but the PVR might contain some kind of secret key or secret handshake that's needed in order to perform software upgrades. You publish all your source code, but nobody can actually install a modification without your help. (In my TCG comments, I discussed a related example involving the video game Netrek, which is, in fact, free software, but which different people have very unequal access to modify usefully, because of the use of secret keys to try to authenticate client software versions to servers.)
I remember having several discussions about whether the GPL could be amended to say that a manufacturer of a device that incorporates GPL-covered software -- and involves the exercise of a section 106 copyright right in that software! -- must provide "equivalent access to modify" that software. (Equivalent to what? One possibility is "equivalent to the manufacturer's own ongoing access" and another possibility is "equivalent to that conveyed by the manufacturer to any other party".) Another question is whether this would even be a good idea.
One obstacle to that suggestion is the general problem of computer security. Implementations of computer security usually rely on not giving all parties equivalent access to modify software; only some parties get that kind of access. The existing GPL has a clear rule that is not incompatible with traditional computer security: anyone who exercises certain exclusive rights of the copyright holder must provide source code access. But source code doesn't include things like passwords, cryptographic keys, and configuration files, which cause particular instances of software to treat different people unequally even though the underlying software program itself, as a literary work, might well be equally available to them.
A broad rule about providing equivalent access to modify software seems like something that would create a lot of mischief with various computer security policies. I think this is just an illustration of another comment of mine in the TCG comments: that Bruce Schneier is right to say that all security systems shift power from someone to someone else, and that the value of a security measure is something that different observers will disagree about. If you like some security policy, you may be grateful that the enforcement of that policy isn't hampered by an "equivalent access to modify" rule; if you hate it, you may wish there were such a rule.
Most people accept -- in some sense -- that their CPU vendors have not published the means of changing the microcode inside CPUs. But they don't necessarily approve of that decision, and they may well believe (as against the CPU vendors) that the world would be a better place if that information were revealed. And part of what drives them to that concern may just be a long-established concern with assymetries of power. If CPUs were elementary particles, and nobody had ever taken one apart, that would be one thing; instead, there is somebody who knows how to change how your CPU works, and that person won't tell you. So the sense of control seems to be, in a way, a question of jealousy: is there somebody else in the world who can make changes and achieve results that I can't? It isn't an absolute question of what you can do or what you can't do, but a question of who's preventing you, and what that person is keeping secret from you.
One really funny thing about this is the way that different people develop different intuitions about which things are properly under their control. For example, not many people say that they should be able to control somebody else's e-mail client, or the rain, or the Pentagon's web server. But many people have developed an intuition that they should be able to control software that runs on their computers. And other people have developed an intuition that they should be able to control programs that they write, even when they're running on someone else's computer. "The prayers of both could not be answered. That of neither has been answered fully."
I want to think more about the idea of control as arising out of jealousy. (I should probably say contrast rather than jealousy.)
