IEEE Technology and Society Magazine - March 2020 - 72

their own, or to prevent end-users making modification or
repairs [8]. Of course such laws are moot if rival manufacturers and tinkerers are not able to perform reverse engineering or modification in the first place, as is the intent of
a trusted system. For their part, companies taking such
action argue that this is to prevent substandard parts or
repairs being inflicted on the company's product.
Suppose a smart contract requires possession of
some device capable of fulfilling the conditions of the
smart contract, and that this device is only available from
one manufacturer. This was, in fact, the case for Apple's
iTunes prior to 2009, when most music sold on it was
protected by Apple's "FairPlay" digital rights management
system that could only be found in Apple's iDevice ecosystem. Such a contract forces parties to the contract to
buy this device even if they prefer one from a different
manufacturer. (In 2009, Apple and record labels agreed
to sell music without digital rights management.)
It may be observed that so-called "public" blockchains
like Bitcoin and Ethereum are specifically designed to
work around the need for these sorts of closed ecosystems. A public blockchain can in principle be extended
and verified by anyone, so that control of the blockchain
is famously said to be "decentralized" amongst anyone
who chooses to be involved. In principle, anyone ought
to be able to participate in a public blockchain so long as
they have a device capable of performing the operations
required to extend and verify the chain.
Of course a company could build its own ecosystem
around a so-called "permissioned" blockchain, which can
be extended only by entities given the permission to do
so by the operators of the chain. Maybe customers would
join this ecosystem if the company's products were
appealing enough to them, as they did for Apple. Blockchain purists might dismiss such closed ecosystems as
not being true to the blockchain spirit, but the company's
customers would be stuck in them nonetheless.
Even for a public blockchain, however, control of the
blockchain is not really the point: it's control of the contracts. Consider the example mentioned earlier in which
Alice agreed to pay Bob for a service. In order to verify
that the service has been completed to Alice's satisfaction, she requires Bob to demonstrate his success to
some device that she has manufactured herself. This
device has a lot of power - and not only will a public
blockchain fail to stop it, the blockchain will abet it.

Practical Problems of Digital
Rights Management
Aside from philosophical objections, rights management
systems struggled to compete with the convenience of
printed books, CDs, and DVDs to which readers, listeners, and viewers had become accustomed. Not all of the
reasons for this have any obvious bearing on smart

contracts, since smart contracts might be deployed for
purposes other than selling copyrighted goods. There
are nonetheless several problems that digital rights
management might have avoided - but didn't - for
which there are clear counterparts in agreements made
by smart contracts for other applications.
Firstly, panic amongst copyright owners led to relatively crude rights management systems being deployed
to combat what they saw as an overwhelming and immediate threat from file-sharing.
As of now, smart contracts have not been proposed
as a solution to a pressing problem of the kind that copyright owners saw themselves facing with the rise of filesharing networks. This ought to give smart contract
developers time to reflect, and be sure that smart contracts are deployed only when the technology is ready.
The more likely risk is that smart contract enthusiasts
lose themselves on Gartner's "Peak of Inflated Expectations," overselling the abilities of smart contracts and
deploying them in circumstances for which they are not
really adequate or appropriate.
Secondly, the market for digital rights management systems was dominated by a variety of non-interworking proprietary systems. Worse, the core requirement of digital
rights management that it execute on a trusted system
works against interoperability because it means that each
device within a proprietary ecosystem can trust only other
members of the same ecosystem. A procession of initiatives including MPEG-21, the Digital Media Project, the
Open Mobile Alliance, the Coral Consortium and others did
recognize lack of interoperability as a severe barrier to the
adoption of digital rights management, and proposed standards intended to overcome it. But these standards were
unable to supplant the proprietary systems.
There are already numerous blockchain-based cryptocurrencies and smart contract systems in existence,
none interworking. Suppose Bob offers services under a
smart contract, but keeps his accounts in ether while
Alice keeps her accounts in bitcoin. A cryptocurrency
exchange might be able to transfer the currency, but on
which blockchain will the smart contract execute?
As already noted, public blockchains are supposed to
avoid the problem of closed ecosystems. The experience
of digital rights management suggests that the mere
existence of an open standard - or, worse, several of
them - is not enough to guarantee that everyone will
move to it. Smart contracts may have a head start on
interoperability in that systems like Ethereum already exist,
giving smart contract users the opportunity to start with an
open system rather than build their own proprietary systems. The foregoing example, however, illustrates a pitfall
that is yet to be addressed to the best of my knowledge.
Finally, there was little if any market incentive to
improve the quality of digital rights management

IEEE TECHNOLOGY AND SOCIETY MAGAZINE

∕

MARCH 2020

IEEE Technology and Society Magazine - March 2020

Table of Contents for the Digital Edition of IEEE Technology and Society Magazine - March 2020