🚀 go-pugleaf

[mod- from the UK LPF - may be of limited relevance to others]
	Attached find for information a submission that ECSR are
making on the consultative draft of the new UK copyright law. If
you want to make comments on the new law you must do so before
the end of September. I would particularly draw the attention of
academics to the proposed removal of the right to "decompile"
programs for research or private study.


				Alan

<--------------------------cut here--------------------------->

\documentstyle[12pt,a4]{article}

\title{Comments on \\ 
The Copyright (Computer Programs) \\
Regulations 1992}
\author{Edinburgh Computer and Social Responsibility
Group\thanks{These comments were drafted by a working group
consisting of Alan Bundy (convener), Mandy Haggith and Ehud
Reiter and discussed at an ECSR meeting on 14th September 1992.
We are grateful for feedback  from Bill Cornish, Lilian 
Edwards, Hector McQueen, Sam Nelson and Richard Stallman.}} 
\date{\today}

\begin{document}
\maketitle

\section{Introduction}

In May 1991 the Council of the European Community issued a
Directive on the ``Legal Protection of Computer Programs''
(91/250/EEC). EC member states were required to transpose this
Directive into law by January 1993. To realise this obligation
the UK has now drafted the Copyright (Computer Programs)
Regulations 1992.

The ECSR has been concerned about the European Directive because
of a fear that it might move European law in the direction
recently taken by US software copyright law. In particular, we
feared that it might make possible ``look and feel'' disputes, in
which software vendors claimed copyright in the
interfaces of their programs. Following its earlier
representations to the UK government, ECSR was asked to comment
on the draft UK law. This is our response.

The Copyright (Computer Programs) Regulations 1992 mainly consist
of amendments to the Copyright, Designs and Patents Act 1988. We
will refer to these below as the 1992 Regulations and the 1988
Act, respectively. The 1992 Regulations deal exclusively with the
copying and translation of programs, and not with the interface
issue. We have commented below on both these aspects.


\section{Computer Interfaces}

The 1992 Regulations make no reference to the interface
issue which has caused such controversy in the USA. 
Article 1(2) of the European Directive says:
\begin{quote} 
``Ideas and principles which underlie any element of a computer
program, including those which underlie its interfaces, are not
protected by copyright''
\end{quote}
There is no mention of ``ideas or principles'', or any similar
concept, in either the 1992 Regulations or the copyright part of
the 1988 Act. Thus this part of the European Directive seems not
to have been complied with.

It might be claimed that the 1988 Act covers only the
``expression'' of a work, and that this is well known to exclude
``ideas and principles''. However, the concept of ``expression''
seems to be particularly difficult to define in the case of
computer programs. On the one hand it needs to be sufficiently
abstract to cover representations in different media, {\em e.g.}
discs, tapes, paper, {\em etc.} and in different programming
languages, but on the other hand it must not be so abstract as to
cover the algorithm, which is a mathematical concept which cannot
be copyrighted or patented. There is no technical concept in
computer science which corresponds to the legal concept of
``expression''.

We therefore argue that the 1992 Regulations should clarify the
concept of ``expression'' of a computer program.  In particular,
it should be made clear that software copyright covers only the
encoding of a program and not the {\em rules and conventions
whereby a computer communicates with another entity.} This is
especially important because many of these rules and conventions
are or may become the subject of information technology
standards. The preamble to the European Directive makes clear
that there should be no prejudice to ``Council decisions relating
to standardization''.

Note that many of the rules and conventions in common use are
quite humble items, {\em e.g.} the keywords of a programming
language, the icons of a window system, the layout of a
spreadsheet. It must be made clear that these count as ``ideas
and principles'' and not ``expression'' and are, therefore,
excluded from copyright.

It places an unnecessary and unwanted burden on program users to
learn a new set of ``rules and conventions'' for different
products of similar functionality.  The interests of program
users must be given more prominence in the development of
copyright law.  Program developers must not be forced to inflict
unfamiliar rules and conventions on users, in order to avoid
violating copyright.

\section{Translation of Code}

Section 3 of the 1992 Regulations proposes a rewording of section
21(4) of the 1988 Act. 
It drops the last phrase:
\begin{quote} 
``otherwise than incidentally in the course of running the
program'' 
\end{quote}
The effect of this removal is to disallow a previously legal form
of program translation. Presumably, this removal is to meet
article 4(b) of the European Directive which gives exclusive
translation rights to the author.

Unfortunately, this omission has the (presumably unintended)
effect of making illegal the use of a compiler or interpreter on
the source code of the licensed program. It is commonplace to do
this as a prerequisite to running a program supplied in source
code form. Presumably, the omission is meant to close a loophole
in the existing law which  would allow someone to translate a
program provided it was done while the program was running.
However, this loophole can be closed without making compilation
illegal, by rewording the offending phrase. We suggest, for
instance: 
\begin{quote} 
``otherwise than as required in order to run the program.''
\end{quote}
This still meets the European Directive because the author can be
assumed to have given implicit permission to translate if this is
essential in order for the program to be used as intended. It may
be felt that this implicit permission is so obvious that it does
not need to be made explicit, {\em e.g.} by a phrase such as the
one above. However, the drafters of the 1988 Act seem to have
felt it worth making explicit, and our suggested rewording would
preserve their intention while avoiding the loophole.


\section{Decompilation for Study and Research}
\label{study}

Section 5(b) of the 1992 Regulations removes the right to
decompile a program in the course of research or private study.
We concede that it is necessary to remove such blanket rights as
a prerequisite to granting the more specific rights permitted
under the European Directive. Unfortunately, this removal will
seriously damage the legitimate interests of academic researchers
and teachers. Their specific requirements {\em are} catered by
article 5(3) of the European Directive, but this article has not
found its way into 1992 Regulations

Note that ``decompilation'' is defined in a much wider sense in
the 1992 Regulations (section 6 29A) than its technical sense in
computer science. Its definition includes any translation or
reproduction of the program code, {\em i.e.} not just translation
>from object code to source code. Thus rational reconstruction of
a program written in one high-level language into another
high-level language or compilation from a high-level language
into a low level one are both violations of copyright.
Incidentally, the definition of ``decompilation'' in section 6
29A is pretty opaque. The second half, particularly, is almost
unreadable.

The understanding of programming techniques is a vital part of
education and research in computer science. Decompiling programs,
especially in the wide sense used in the 1992 Regulations, is one
way to discover such techniques. Decompiling is also a vital
skill to teach to computer science students who may have to debug
or interface to programs during their professional life. This
point will restrict the ways in which they can be taught that
skill.

Note that, in the UK, all programs are automatically copyrighted,
not just commercial systems. Thus this law could interfere with
the study and analysis of experimental programs built in academic
research.

Article 5(3) of the European Directive allows a user to
``observe, study or test'' a program to determine its ``ideas and
principles''. This would certainly include decompilation in the
wide sense used in the 1992 Regulations. However, this right has
not found its way into the 1992 Regulations. We propose that this
be rectified, and the needs of academics be catered for, by the
inclusion of a new clause after section 6 29B(2)(a) of the 1992
Regulations.
\begin{quote} 
``Or the decompilation is to be used only as a tool in the
observation, study or testing of the functioning of a program in
order to determine the ideas and principles which underlie some
element of it.''
\end{quote}


\section{Authorship of Computer Generated Programs}

The possibility of computer generated programs has created a new
kind of legal problem: who is the author of such works? The
European Directive demands that authors be ``natural persons''
(Article 2(1)), so this rules out computer authorship. However,
there is still ambiguity between the author of the generation
program and the user of the generation program. At one extreme
the generation program might be a general purpose, interactive
theorem prover synthesising programs from logical specifications.
In this case the user puts in the major creative effort:
designing the specification and guiding the prover. There is
little doubt that this user is most entitled to the benefits of
authorship. At the other extreme the generation program might be
an application generator in which the user's role is restricted
to setting a few parameters, {\em e.g.} the sizes of various
data-structures. In this case the author of the generation
program has defined a narrow class of programs from which the
user is merely choosing. There is little doubt that this original
author is most entitled to be regarded as author of all the
programs in this class.  We can imagine a program generator
occupying every point between these two extremes. There is no
obvious place to put a boundary.  In many cases one would want to
have some form of joint authorship.

The first draft of the European Directive (article 2(5)) tried to
overcome this difficulty by awarding the authorship to the
generation program user, unless the contract specifies otherwise.
This solution neatly finesses the problem by leaving the issue
open to negotiation between the parties. In subsequent drafts of
the European Directive no solution was proposed. Similarly, the
1992 Regulations propose no solution, so the 1988 Act solution
will remain unchanged.

Section 9(3) of the 1988 Act defines the author of a
computer-generated work, as 
\begin{quote} 
``the person by whom the arrangements
necessary for the creation of the work are undertaken''
\end{quote}
This definition seems to be highly ambiguous and could be used to
grant authorship to a wide range of people. To take an absurdly
extreme case, someone who stole a generation program and then
used it as part of a computer generation service might claim to
be the author of its products under this definition. This 1988
definition has been widely considered to be so ambiguous as to be
worthless. In practice the assignment of authorship in
computer-generated works has been left to the courts to determine
on the basis of case law. We suggest that this de facto situation
be recognised by the deletion of section 9(3) from the 1988 Act.
This would both remove an ambiguous and worthless section of the
1988 Act and bring it into line with the European Directive,
which is now silent on this point. Alternatively, the 1992
Regulations could adopt the solution, mentioned above, in section
2(5) of the first draft of the European Directive.

\end{document}