The Commission, wisely one may add, opted not to
define the term “computer program” in the Software Directive, in order to
refrain from accidentally excluding future technological developments[51].
The Green
Paper put forward a broad working definition: “A computer program is a set
of instructions the purpose of which is to cause an information processing
device, a computer, to perform its functions”[52].
This broad definition, as it was mentioned above, is entirely in line
with Article 1(2) of the Directive which states
that the Directive is applicable to computer programs regardless of the form in
which they are expressed. In other
words, prior to the Software Directive and based on the general applicable law,
Emulators are infringing rights because the necessary acts that one has to
perform in order to write one fall within the restricted acts, subject of course
to any particular exclusions. The
Software Directive however has “reinvented” law with regards to computer
programs and thus one should examine it thoroughly in order to comprehend the
current legal status quo[53].
The
easier way to explain the law in relation to Emulators is by adopting a reverse
approach. It is more convenient to
examine first the exceptions of the law and then search for any inconsistencies
with the rights conferred to the copyright holder, but for Article 1 which we
shall refer to first.
Article 1 of
the Software Directive, titled “Object of Protection”, is a repetition of
the general applicable legal framework with the necessary references to computer
programs. Article 1(1)
states that computer programs are to be protected by copyright as literary
works, as those are defined by the Berne
Convention, including their preparatory design material, while Article 1(3)
states that protection is afforded to original programs, in the sense that the
program is the author’s own intellectual creation, no other criteria being
applied to determine the eligibility for protection[54].
The dichotomy between expression and idea is expressly made in Article 1(2)
where “Protection in accordance with this Directive shall apply to the
expression in any form of a computer program.” continuing that “Ideas and
principles which underlie any element of a computer program, including those
which underlie its interfaces, are not protected”.
Recital 11 explains that interfaces are
called those parts of the program which provide with interconnection and
interaction between elements of the software and hardware.
To this definition one should give an explanatory note.
There are two kinds of interface; the Technical Interface and the User
Interface. The Recital defines the
Technical Interface as it explains the interaction and interconnection between
software and hardware, that also including the interaction and interconnection
between software and software. Examples
of Technical Interface are the “compatibility” between Windows 98 and
“Pentium based”[55]
Personal Computers and Adobe’s programs such as Acrobat with Microsoft’s
Windows 98. On the other
hand, User Interface refers to, as the term suggests, the interaction between
human and an application program such as a word processor.
For obvious reasons, only Technical Interface is of relevance to us,
since the User Interface of an Emulator, by virtue of its nature, does not bear
any similarities with that of the emulated program[56].
What constitutes however the precise nature of an interface in legal
terms? According to Downing[57],
“An interface will be reflected in program code because the way in which that
code is written will be determined by the interface rules or specification.
For example, the interface specification might state that data must be
sent at a particular speed or to a particular place.
The interface specification does not necessarily have to dictate the
actual code which is required to implement the interface”.
This however leads back to the question as to what is protected and what
it is not, i.e. the expression/idea dichotomy stated in Article 1(2).
It can be argued, by reason of Article 1(2), that the interface
specification is outside the scope of copyright protection.
With regards to the code implementing those specifications, the views
differ. Although one could say that the code is an expression of an idea one
could argue, this being the case for most Emulators to the best of my
understanding, that there is a merge of idea and expression, meaning that this
code is the only way of expressing that idea and thus it is not protected by
copyright[58].
This uncertainty makes it imperative for us to proceed, assuming that the
interface is copyright protected.
Article 6
of the Software Directive, titled “Decompilation”[59],
is perhaps the single most important provision in the Directive with regards to
Emulators. As it has been earlier
submitted as a technical fact, most Emulators, e.g. VGS,
are depended on the study of the original program, and this program, software or
firmware, is supplied by companies in object code form.
Furthermore, again in accordance with what has been previously contested
under the general law principles, for a software-based emulator[60],
such as all the Videogame Emulators, to be a direct copy of all the instructions
comprising a copyrighted program would be in violation of copyright.
Given the considerations above, Emulator programmers are opting for the
exercise of reverse engineering[61]
which enables them to reproduce the functional elements of a program, while at
the same time not infringing the copyright of the program, if of course they
manage to “reverse engineer” successfully[62].
There
are many ways for reverse engineering to be conducted, including[63]:
b)
Observing the program in operation by using it on a computer
c)
Performing a static examination of the individual computer instructions
contained within the program
d)
Performing a dynamic examination of the individual computer instructions
as the program is being run on a computer
According to Article 6(1),
“the authorization of the rightholder shall not be required where reproduction
of the code and translation of its form within the meaning of Article 4
(a) and (b) are indispensable to obtain the information necessary to achieve the
interoperability of an independently created computer program with other
programs”. Surely, this provision
poses no problems for it describes the very nature of Emulators which is to
achieve interoperability between a game console, for example, and its software
with a computer Operating System, such as Windows9x, LINUX and Macintosh OS7.
This right however, or better say exclusion from restricted acts, goes as
far as obtaining information in relation to the Technical Interface and is
subjected to the fulfillment of some further conditions.
Article 6(1)(a)
states that these acts, i.e. reproduction and translation must be “performed
by the licensee or by another person having a right to use a copy of a program,
or on their behalf by a person authorized to do so”. Again, this is not of immediate relevance to Emulators
because most programmers either own the hardware or are given the hardware by
owners for that particular reason. One
however should note the following example; Connectix, in Sony
v Connectix, contested that at an early stage of their effort they
downloaded an Image of the Papillon chip, the name of the Playstation BIOS, from
the Internet. Had they based their
study upon this copy, they would have been outside the scope of Article 6.
For their good fortune, the Image turned out to be from a Japanese
language version Playstation and was thus useless to them; the next day they
bought a console, thus becoming rightful users. Article 6(1)(c)
serves as a reminder, stating that “these acts are confined to the parts of
the original program which are necessary to achieve interoperability”.
Having obtained by decompilation the necessary
fundamental information, an Emulator programmer builds the basic skeleton of his
Emulator that behaves in a similar manner with the original system.
The transition from the skeletal program to the final program is done by
loading appropriate for that system software in his Emulator, e.g. a NES game
for a NES emulator, and then studying the Emulator’s behaviour, mainly relying
on the visual display of his monitor and some general principles of programming.
Since creating an Emulator has as a prerequisite that one knows the
behaviour of the system’s software in the first place, one understands that
his Emulator has an error, referred to as bug, when for example he receives a
blue background colour on a game that he knows that it was meant to be green.
He then tries to “debug” his Emulator until the picture in his
monitor looks exactly the same as it would look in the original system.
If an Emulator performs correct with one software, it will perform
correct with all the software designed for that particular system[66].
This process cannot be deemed to infringe copyright for the result
pursued maybe the same, i.e. the same response, but the process, and thus the
expression, is different. One would hardly accept that a car for example is a
“copy” of another car, simply because both cars can drive at the same speed
with the same fuel consumption. Such
a technique seems to be compatible with Article 6(2)
which deals with effective conditions on the resulting program, i.e. the
Emulator. A programmer may not use
the information obtained for purposes other than to achieve the interoperability
of his Emulator[67], nor pass this
information to others but for where it is necessary for the interoperability of
his program[68].
Emulators that are not open source, such as the UltraHLE,
VGS and up until recently
RAINE [69],
are not distributing any information at all while open source emulators, such as
MAME and Callus
[70],
serve as providing information necessary to achieve interoperability between
independently created programs, i.e. Emulators and potential “ports”, e.g.
the Windows port MAME32, or
utility tools. Accordingly[71],
the resulting program, i.e. the Emulator, must not infringe the copyright of the
original program, i.e. include portions of original code not relating to the
interface, if this code is protected by copyright.
The same of course would apply for translated code etc.
A very useful legal illustration regarding the
legitimacy of the acts stated above is provided by the US case Sega
Enterprises, Ltd. v. Accolade, Inc.[72].
The facts of the case were that Accolade, a game software manufacturer,
wanted to built cartridges for use with Sega’s console “Genesis”. Sega was the sole author for software for the Genesis
console. Accolade, in order to manufacture cartridges compatible with the
Genesis console needed to find out the interface of the Genesis console, in
order for its cartridges to be compatible with it.
Sega was not granting the needed information to Accolade and so Accolade
decided to obtain this information by the process of disassembly[73].
The court approved this practice on the grounds of fair use, reasoning
that disassembly constitutes fair use if it is the only means available for
accessing the ideas and functioning concepts within “operating
systems, system interface
procedures and other programs that are not visible to the user when operating”[74].
Bearing in mint that the US law does not provide with a provision similar
to that under Article 6(1) of the Software Directive and thus a substitution
between the “fair use” principle and the decompilation right is necessary,
it is difficult to perceive how could a European court reach a different outcome
regarding Emulators, especially when this decompilation right, by virtue of
Article 9(1)
[75],
cannot be derogated by contract, since the reasoning given by the US court fits
the Directive’s provisions so well[76].
Having seen the effect of the decompilation
provision, we must now proceed accordingly to the other relevant provisions
under the Directive in order to address any potential inconsistencies or
problems that they might give rise to.
Article
4, titled “Restricted Acts”, follows
the same pattern with the general law of copyright. According to the preamble of Article 4,
subject to the provisions in Articles 5 and
6 a copyright holder has the exclusive
right to do or authorize:
4(a)
“the permanent or temporary reproduction of a computer program by any means
and in any form, in part or in whole. Insofar as loading, displaying, running,
transmission or storage of the computer program necessitate such reproduction,
such acts shall be subject to authorization by the rightholder”.
4(b)
“the translation, adaptation, arrangement and any other alteration of a
computer program and the reproduction of the results thereof, without prejudice
to the rights of the person who alters the program”
Article 5,
titled “Exceptions to the Restricted Acts”, has a similar effect with its
equivalent in general copyright law, as one can assume from its title.
As we discussed above, Article 5(1) serves as an exception to Articles’
4 (a) and (b) restricted by authorisation acts, proviso to specific contractual
provisions. Our interest now then,
should focus upon Article 5(3) which states
that “the person having a right to use a copy of a computer program shall be
entitled, without the authorization of the rightholder, to observe, study or
test the functioning of the program in order to determine the ideas and
principles which underlie any element of the program if he does so while
performing any of the acts of loading, displaying, running, transmitting or
storing the program which he is entitled to do”[80].
In the process of writing the Emulator and finalizing it, a programmer
will have to do most, if not all, of the above but that poses no problem, as
Article 5(3) states that such actions can be performed without the authorisation
of the rightholder and a similar proviso to that of Article 5(1),
i.e. “in the absence of specific contractual provisions”, is not present. This right of study of course, similarly to the right of
decompilation, cannot be derogated by contract, since a contractual provision
contrary to that right would be null and void[81].
In essence, one could say that as Article 5(1) serves as the “excuse”
for a user to copy a program into his computer’s RAM in order to use it “in
accordance with its intended purpose”, i.e. to “run” the programme,
Article 5(3) serves as the excuse for an Emulator programmer to copy the
program, e.g. the BIOS instructions, into his computer’s RAM, in order for him
to “to observe, study or test the functioning of the program…”.
Having
discussed the above, one concludes that by writing an Emulator, a programmer
does not infringe any of the rights of a copyright holder, provided of course
that the resulting program does not contain infringing elements.
As we have discussed, the programming of an
Emulator can be based on obtaining the necessary information by decompiling the
“program” of the original system. This
does not mean however that this is the only way that an Emulator can be
programmed, and in fact the views of Emulator programmers and respected
webmasters[82] are contrasted as to
which techniques are more frequently used.
This kind of distinction however was deliberate on our behalf for it
facilitates the legal analysis of Emulators.
The alternative technique that we shall now elaborate upon is
“document-based” and it does not necessarily require the decompilation of a
program[83].
As we have previously discussed, the program
contained in the hardware is decompiled in order to obtain information.
What happens though when the needed information are already known or can
be obtained somehow without decompiling the program?
It is after all true that if you have the needed information in paper,
you can simply program your computer to behave in a given manner.
If a programmer knows that CPU A, when connected with pin X in the given
manner Δ
performs Ψ, he can virtually
recreate the whole process of a system in program.
Unfortunately, it has been submitted to me that
the method used, i.e. decompilation or documentation, is often a matter of
preferable style and not of availability of means. This choice however, when information is available, is not an
advisable act as we shall now see.
Consider the following two situations:
The comprising parts of a system are all generic
components such as the Motorola M68000, Hitachi’s SH-2 and Zilog’s Z80 CPUs,
and thus their functions are considered as common knowledge.
The Service Manual, containing schematic diagrams and other important
information regarding the configuration of the particular system can also be
obtained by legal means.
The
components of the system are proprietary and thus their function is not common
knowledge but information can be obtained legally by purchasing the
Programmer’s Manual which contains every detail regarding the system, be it
functions or configuration.
Some systems, especially old Arcade cabinets,
use generic components widely available in the market. Since of course those
components are not proprietary, i.e. custom made, it is to the best interest of
the manufacturer to make the specifications of their products available[84],
in order to promote their sales. The behaviour of those components will then
depend upon their configuration on the board, the analysis of which is provided
by the schematics. Most of the old Arcade cabinets were supplied with such
Service Manuals. Having knowledge of both function and configuration is all the
information a programmer needs. Similar
is the situation with proprietary components, more common in Game consoles, but
for one difference. A custom-made
chip, as the word defines it, is manufactured for a specific purpose and thus it
is not to the best interest of a company to make this information available to
the public, since it is not for sale. In
some instances however, such information have been made available as in the case
of the Atari 2600
console and a cartridge called “Magicard”, which allowed one to program the
2600. The Magicard came with an extensive programming manual for the 2600
console, which proves to be useful also with the Atari 5200 console due to the
similarities between the two systems[85].
There is however a legal implication to
address here, as I foreclosed earlier.
Under Article 6(1)(b),
decompilation is allowed as long as “the information necessary to achieve
interoperability has not previously been readily available” to the programmer.
This means that copyright holders can effectively remove the right to
decompile by making the information available, and may also be entitled to
charge for providing this information even when disclosure is mandatory[86].
Having seen the provisions of Article 6(1)(b), one understands that there
is a clash between the Article and programmers’ practices, the Article’s
provisions of course prevailing. For
a programmer to decompile for his sheer convenience when the appropriate
information is or has been made available to him, constitutes a copyright
infringement and so does the resulting program, i.e. the Emulator.
The position is less clear when decompilation is conducted under those
circumstances but in order to clarify matters which are not clear in the
documentation. Common sense
dictates that decompilation in order to clarify vague information is
permissible, but the most orthodox view would perhaps be to do so after attempts
to clarify the point with the company issuing the information have failed.
Since Article 1 protects also
“preparatory design materials”, the abovementioned documentation being such,
the “rules” of Emulation remain the same regardless of the technique used.
Having elaborated on how Emulators are written
and the legal issues rising in relation to these programs, we shall now
investigate two recent US jurisdiction cases where Emulators as such is the
subject of litigation.