A “right” is a legal entitlement – something that the law says you are allowed to do. But the term is often misused to refer to something else.

Consider, for example, the use of “digital rights management” (often abbreviated as DRM) to describe technologies that restrict the use of creative works. In practice, the “rights” being managed are really just rules that the copyright owner wants to impose; and those rules may bear little relation to the parties’ legal rights. Cloaking these restrictions in the language of “rights” makes them sound more neutral and unchangeable than they really are.

DRM advocates often put forth arguments that go roughly like this:

(1) we have built technology that doesn’t let you do X;

(2) therefore you cannot do X;

(3) therefore you do not have the right to do X;

(4) therefore you should be required to use technology that doesn’t let you do X.

The trickiest part of this argument is getting from (2) to (3). Using the term “digital rights management” in (1) and (2) makes the leap from (2) to (3) seem smaller than it really is.

There is at least one more common misuse of “rights” in the copyright/technology debate. This is in the use of the term “rights holder” to refer to copyright owners (but not to users). When someone says, “Content is shipped from the rights holder to the consumer,” the implication is that the rights of the copyright owner are more important than those of the user. There is no need for this term “rights holder.” “Copyright owner” will do just fine, and it will help us remember that both parties in the transaction have rights that need to be protected.

A “standard” is a technical specification that allows systems to work together to make themselves more useful. Most people say, for good reasons, that they are in favor of technical standards. But increasingly, we are seeing the term “standard” misapplied to things that are really regulations in disguise.

True standards strive to make systems more useful, by providing a voluntary set of rules that allow systems to understand each other. For example, a standard called RFC822 describes a standardized way to format email messages. If my email-sending software creates RFC822-compliant messages, and your email-receiving software understands RFC822-compliant messages, then you can read the email messages that I send you. Compliance with such a standard makes our software more functional.

Crucially, standards like RFC822 are voluntary and nonexclusive. Nobody forces any email-software vendor to comply with RFC822, and there is nothing to stop a vendor’s product from complying simultaneously with both RFC822 and other standards.

Lately we have seen the word “standard” misapplied. For example, the Broadcast Protection Discussion Group (BPDG) calls its proposal a “standard,” though it is anything but. Unlike a real standard, BPDG is not voluntary. Unlike a real standard, it contains prohibitions rather than opportunities. Put the BPDG “standard” in front of experienced engineers, and they’ll tell you that it looks like a regulation, not like a standards document. BPDG is trying to make its restrictive regulations more palatable by wrapping them in the mantle of “standards.”

A more subtle misuse of “standard” arises in claims that we need to standardize on DRM technology. As I wrote previously:

In an attempt to sweep [the technical infeasibility of DRM] under the rug, the content industry has framed the issue cleverly as one of standardization. This presupposes that there is a menu of workable technologies, and the only issue is which of them to choose. They want us to ask which technology is best. But we should ask another question: Are any of these technologies workable in the first place? If not, then a standard for copy protection is as premature as a standard for teleportation.