council directive of 14 may 1991 on the legal protection of computer programs (91/250/eec)

8
4 } ..... .. ~ ~. .. ~; SO. 1. DIRECTI"V COUNCIL DIRECTIVE OF 14 MAY 1991 ON THE LEGAL PROTECTION OF COM PUTER PROGRAMS (91/250/EEC) TABLE OF CONTEiNTS I. :INTRODUCTION II. BACKGROUND III. THE SPECIFIC PROVISIONS 1. The object of prote~ion 2. Eligibility 3. Authorship 4. The bundle of exclusive rights 5. Exceptions to the exclusive rig~ 6, General ~ons to the restricted acts: Article 5 a) Mai:ntenanco b) The making of a back-up copy c) Black-box analysis 7. Decompilation 8. Secondary infringement 9. The term of protection 10, Continued application of the other legal provisions 11. Implementation IV,CONCLUSION THE SOFTWARE DIRECTIVE I. INTRODUCTION The EC Council adopted the Software Directive on May 14, 19911. It is a unique piece of legislation in several respects: (i) it was the first EC measure to harmonize aspects of national copyright law; (ii) it was the first piece of legislation specifically to address that the issue of access to interface information and (iii) it brought unprecedented Washington-style lobbying to Brussels and Strasbourg. The Commission had sounded out views on the need to harmonize the legal protection of computer software back in 1988. The feed-back suggested nothing untoward. Only after the Commission issued a draft Directive in January 1989, did the debate erupt. The following key issues emerged: interoperability of computer programs; the protection of interfaces; maintenance; and piracy. Software producers argued that the ease with which software can be copied - at the push of a button - called for a high level of protection. The Commission agreed. However, by ensuring robust anti-piracy measures in its draft, the Commission's proposal unwittingly threatened to deprive producers of compatible programs of their life-blood - interface information. Interfaces are the electronic 'pass- words' contained in the software, which producers of compatible products need to 'understand' if they are to write software which operates with the original program. In many cases, the password can consist of a handful of 0s and l s, and is of nominal intrinsic value. But knowledge of 'the code' can control access to a neighbouring market. Put simply, the issue was: Should the author's 'monopoly' over the original program be extended to: (i) programs which are intended to operate within the environment which evolves around the original program or (ii) products which operate with the original program? For example, should the author of an operating system have the right to monopolize the market for the application software running on the operating system? The Commission faced with a polarized split in industry, elected to promote the goal of interoperability. It proposed a narrowly circumscribed decompilation right so as to allow producers of interoperable products, as a last resort, the right to convert the program's machine code (or part thereof) into source code to enable them to discover the necessary interfaces. Its opponents retorted that the competition considerations rules could adequately redress any misuses of copyright which might occur, where interface information was not available on a case- by-case basis. It was wrong, they said, to incorporate competition into a copyright Directive. But this is exactly what the Commission did. It subsumed into the Directive a series of checks and balances to ensure that the extensive rights granted to authors in the Directive would not be exercised to frustrate the goal of interoperability. A further issue raised by the draft Directive was maintenance of the original program. The draft Directive granted rightholders a comprehensive bundle of exclusive rights, which extended to those acts necessary to maintain the program (reproduction, adaptation, alteration). Users complained that this would shift the balance in favour of suppliers: users would be prevented from carrying out their own maintenance or from relying on the services of third-party maintenance companies. The Directive makes a token gesture to users by allowing them to carry out error correction (although in the U.K., this right may be overridden by contract). However, notwithstanding the application of the EEC competition rules, there seems little doubt that the position of suppliers regarding the maintenance of their own products has been strengthened as a result of the Directive. II. BACKGROUND The Directive's roots can be traced back to the 1985 Commission Internal Market White Paper, which noted: "Differences in intellectual property laws have a direct and negative impact on intra-Community trade and on the ability of enterprises to treat the common market as a single environment for their economic activities." The White Paper identified the harmonization of a legal protection of computer software as a priority. This was endorsed in 1988 by the Commission's Green Paper. Software was singled out: (a) because of its economic importance, and (b) because of striking divergences in the way in which software was protected, if at all, at national level. In 1985, France adopted a modified copyright approach. It

Upload: mark-powell

Post on 21-Jun-2016

213 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Council directive of 14 May 1991 on the legal protection of computer programs (91/250/EEC)

4 } . . . . . . . ~ ~. . . ~ ;

SO. 1. DIRECTI"V

COUNCIL DIRECTIVE OF 14 MAY 1991 ON THE LEGAL PROTECTION OF COM PUTER PROGRAMS (91/250/EEC)

TABLE OF CONTEiNTS I. :INTRODUCTION II. BACKGROUND III. THE SPECIFIC PROVISIONS

1. The object of prote~ion 2. Eligibility 3. Authorship 4. The bundle of exclusive rights 5. Exceptions to the exclusive r i g ~ 6, General ~ o n s to the restricted acts: Article 5

a) Mai:ntenanco b) The making of a back-up copy c) Black-box analysis

7. Decompilation 8. Secondary infringement 9. The term of protection 10, Continued application of the other

legal provisions 11. Implementation

IV,CONCLUSION

THE SOFTWARE DIRECTIVE

I. INTRODUCTION The EC Council adopted the Software Directive on May 14, 19911. It is a unique piece of legislation in several respects: (i) it was the first EC measure to harmonize aspects of national copyright law; (ii) it was the first piece of legislation specifically to address that the issue of access to interface information and (iii) it brought unprecedented Washington-style lobbying to Brussels and Strasbourg. The Commission had sounded out views on the need to harmonize the legal protection of computer software back in 1988. The feed-back suggested nothing untoward. Only after the Commission issued a draft Directive in January 1989, did the debate erupt. The following key issues emerged: • interoperability of computer programs;

• the protection of interfaces;

• maintenance; and

• piracy. Software producers argued that the ease with which software can be copied - at the push of a button - called for a high level of protection. The Commission agreed. However, by ensuring robust anti-piracy measures in its draft, the Commission's proposal unwittingly threatened to deprive producers of compatible programs of their life-blood - interface information. Interfaces are the electronic 'pass- words' contained in the software, which producers of compatible products need to 'understand' if they are to write software which operates with the original program. In many

cases, the password can consist of a handful of 0s and l s, and is of nominal intrinsic value. But knowledge of 'the code' can control access to a neighbouring market. Put simply, the issue was: Should the author's 'monopoly' over the original program be extended to: (i) programs which are intended to operate within the environment which evolves around the original program or (ii) products which operate with the original program? For example, should the author of an operating system have the right to monopolize the market for the application software running on the operating system? The Commission faced with a polarized split in industry, elected to promote the goal of interoperability. It proposed a narrowly circumscribed decompilation right so as to allow producers of interoperable products, as a last resort, the right to convert the program's machine code (or part thereof) into source code to enable them to discover the necessary interfaces. Its opponents retorted that the competition considerations rules could adequately redress any misuses of copyright which might occur, where interface information was not available on a case- by-case basis. It was wrong, they said, to incorporate competition into a copyright Directive. But this is exactly what the Commission did. It subsumed into the Directive a series of checks and balances to ensure that the extensive rights granted to authors in the Directive would not be exercised to frustrate the goal of interoperability. A further issue raised by the draft Directive was maintenance of the original program. The draft Directive granted rightholders a comprehensive bundle of exclusive rights, which extended to those acts necessary to maintain the program (reproduction, adaptation, alteration). Users complained that this would shift the balance in favour of suppliers: users would be prevented from carrying out their own maintenance or from relying on the services of third-party maintenance companies. The Directive makes a token gesture to users by allowing them to carry out error correction (although in the U.K., this right may be overridden by contract). However, notwithstanding the application of the EEC competition rules, there seems little doubt that the position of suppliers regarding the maintenance of their own products has been strengthened as a result of the Directive.

II. BACKGROUND The Directive's roots can be traced back to the 1985 Commission Internal Market White Paper, which noted:

"Differences in intellectual property laws have a direct and negative impact on intra-Community trade and on the ability of enterprises to treat the common market as a single environment for their economic activities."

The White Paper identified the harmonization of a legal protection of computer software as a priority. This was endorsed in 1988 by the Commission's Green Paper. Software was singled out: (a) because of its economic importance, and (b) because of striking divergences in the way in which software was protected, if at all, at national level. In 1985, France adopted a modified copyright approach. It

Page 2: Council directive of 14 May 1991 on the legal protection of computer programs (91/250/EEC)

extended copyright protection to computer programs; but limited the term of protection to 25 years (Law of July 3, 1985). In Germany, software was protected as a literary work under the general 1965 Copyright Act. However, the most noticeable feature of the application of the 1965 Copyright Act to software was the high level of creativity required to be eligible for protection: programmers had to demonstrate that their programs were the fruits of personal intellectual creation. Many programs on the German market were bereft of protection as a result of this patent-like requirement. However, at least in Germany, programmers had a fighting chance of attaining copyright protection. This was not necessarily true in some other Member States, such as Greece or Portugal where the 'copyrightability of computer software had not been recognized by the courts. These broad discrepancies helped to push this issue up the political agenda. Two developments beyond the Community's jurisdiction also helped shape the Commission's approach. In Tokyo, back in 1984, a difference of opinion emerged between officials from the Ministry of International Trade and Industry (MITI) and the Cultural Affairs Agency (CAA) over the format for legislation to protect computer software. MITI, which does not lose many internal struggles, was rooting for a sui generis approach. However, it was the officials from the Cultural Affairs Agency, who emerged victorious. They argued in favour of using the copyright regime to protect computer software as 'literary works'. The US Government had reached the same conclusion some seven years earlier, and is believed to have actively supported the CAA in its battle with MITI. On 31 July 1978 Stanley Fuld submitted to President Carter the findings of the National Commission of New Technological Users of Copyrighted Works (~lthe CONTU Report"). This seminal document has influenced ensuing debate on this topic. The report recommended the protection of computer software by copyright. However, the report was not adopted, without dissent. The harshest criticism for the Commission's findings came from Commissioner Hersey:

"Programs are profoundly different from various forms of 'works of authorship' secured under the Constitution by copyright. Works of authorship have always been intended to be circulated to human beings and to be used by them to be read, heard or seen, for either pleasurable or practical ends. Computer programs in their mature phase, are addressed to machines."

Reservations were also expressed by the US copyright 'guru', Professor Nimmer:

"What is most troubling about the Commission's recom- mendation of open-ended copyright protection for all computer software is its failure to articulate any rationale which would not equally justify copyright protection for the tangible expression of any and all original ideas (whether or not computer technology, business or otherwise). If 'literary works' are to be so broadly construed, the Copyright Act becomes a general misappropriation law, applicable as well in what has traditionally been regarded as the patent arena, and indeed, also in other areas to which neither copyright nor patent law has previously extended."

However, the majority view within the CONTU was that, the anti trust laws could be invoked to combat problems created

by the extension of copyright protection to computer software. The Commission added, "To create.., a remedy on bald suspicion would indeed be unjust." The 1989 draft Directive broadly followed the CONTU approach, that is to say, copyright was preferred over sui generis protection, and no material safeguard mechanism was built into the proposal to prevent anticompetitive exercise of the extensive rights granted thereunder. The choice of copyright was also dictated by one other consideration: international protection. Through the Berne Convention, copyright protection could potentially be ex- tended to many of the EC's trading partners. The EC could more readily persuade other countries to extend copyright protection to software as a 'literary work' under the auspices of the Berne Convention, than to have them adopt a sui generis law ungoverned by any international convention. The Directive has, therefore, subsequently provided the basis for the EC's negotiating position in the ongoing negotiations within the World Intellectual Property Organization (WIPO) on a protocol to the Berne Convention on, amongst other things, the protection of computer programs. From the submission of the draft in January 1989, the Directive took 27 months to adopt. Given its degree of controversy, this was quick. However, like much EC legislation, it is characterized by a series of compromises, which may have assisted its adoption, but adds nothing to its coherency. The baton has now been passed to the Member States, who have had the task of transposing it into national law. At the time of writing, this has not been achieved by all Member States, even though the deadline was 1 January 1993. In those Member States where the deadline has slipped, arguably, national courts are nonetheless under a duty to interpret national law to give effect to the provisions of the Directive pursuant to the ECJ's ruling in Marleasing. 2

III. THE SPECIFIC PROVISIONS Below is a brief analysis of the specific provisions of the Directive.

1. THE OBJECT OF PROTECTION The Directive surprisingly provides no definition of what it is trying to protect - 'computer programs'. This was not an oversight. The Commission took the view that, given the rate of technological advances, any definition of what constituted a computer program would become obsolete. This decision not to circumscribe the Directive's scope may give rise to interpretative difficulties, especially since the draft Database Directive does not apply to computer programs protected under the Software Directive. Because the frontier between computer programs and databases is often spongy, it may not always be clear which set of rules will apply. Instead of providing a definition, the Commission made clear what was within and what was beyond the scope of protection. In: • Preparatory and design materials, such as flow charts or

descriptions of sequences of steps in plain langauge, provided that the nature of the preparatory work is such that a computer program can result from it at a later stage; and

• Programs incorporated within hardware.

Page 3: Council directive of 14 May 1991 on the legal protection of computer programs (91/250/EEC)

Current Development in European Information Technology Law

Out: • User or maintenance manuals generally; • Ideas and principles which underlie any element of a

program, including those which underlie its interfaces; and

• Logic, algorithms and programming languages under- lying the program to the extent that they comprise ideas and principles;

The thorniest issue relating to the object of protection related to the copyrightability of interfaces. Those promoting the cause of interoperability argued for a specific exclusion from copyright protection of interface requirements or specifica- tions on the basis that these are ideas and not expressions of ideas. Their opponents replied that introducing a blanket exclusion from copyright protection for interfaces, would have the effect of encouraging copiers to interpret broadly the term 'interface' to side-step copyright protection. This issue was finally resolved in Article 1(2), which repeats the general copyright mantra that ideas and principles, including those which underlie interfaces, are not protected by copyright. By implication, therefore, the expression of interfaces may be copyrightable. That being said, interface specifications and rules will typically be beyond the scope of copyright protection by virtue of the application of the merger doctrine 3. Paragraph 3.13 of the Commission's Explanatory Memorandum 4 explains:

"If similarities in the code which implements the ideas, rules or principles occur as between inter-operative programs due to the inevitability of certain forms of expression, where the constraints of the interface are such that in the circumstances no different implementation is possible, then no copyright infringement will normally occur, because in these circum- stances it is generally said that the ideas and the expression have merged." 5

The Merger Doctrine has recently been confirmed in the English courts in Richardson v Flanders 6. Analysing whether a computer program designed to assist chemists to auto- matically label prescriptions had taken substantial parts from an earlier program written in a different programming language, Mr. Justice Ferris held as follows:

"If displaying the minimum stock figure on screen or printing it on label is expression rather than idea it is, in my view, the adoption of the only practicable means by which the idea can be expressed .... As to the structure and organization, I am not satisfied that Mr. Ftanders has taken anything beyond the idea which underlies the system and certain characteristics which so far as they constitute expression rather than idea, amount to characteristics which must be present if the idea is to be used."

The Directive leaves the courts to decide whether an interface is eligible for protection on a case-by-case basis by applying the merger doctrine or a de minimus rule (i.e. applying a qualitative test which determines whether the elements copied amount to an insubstantial part of the whole program) 7.

2. ELIGIBILITY To overcome the discrepancies caused by divergent originality tests applied in the Member States, the Directive removes from consideration any qualitative or aesthetic merits of the program• The test now is more straightforward:

"A computer program shall be protected if it is original in the

sense that it is the author's own intellectual creation, No other criteria shall be applied to determine its eligibility for protection."

3. AUTHORSHIP Article 3(1) of the Directive gives Member States a degree of flexibility over the question of authorship. Article 2(1) provides:

"The author of a computer program shall be the natural person or group of natural persons who has created the program or, where the legislation of the Member State permits, the legal person designated as the rightholder by that legislation."

However, Article 3(3) explicitly provides that the exclusive economic rights in programs created during the course of employment shall be vested in the employer not the employee. While joint works are permitted (Article 3(2)), there is no specific provision dealing with commissioned software. In the absence of specific national legislation, authorship in the software will be attributed to the person creating the software, i.e. the independent software house commissioned to write the program. But, under UK law, for example, this does not necessarily mean that the author can exercise the exclusive rights in the program. In Richardson v Flanders, Mr. Justice Ferris found that although copyright subsists in the creator of a program, the author only holds the mere legal title to the software: the equitable interest may "in appropriate circum- stances" pass to the commissioner. Clearly, to avoid legal jousting over what amounts to 'appropriate circumstances', contractual provisions should stipulate how the rights arising from the contract are to allocated. A further interesting issue is that of moral rights. The Directive is arguably without prejudice to any moral rights which may subsist in a program (Article 9(1)). Article 3(3) - which provides the automatic conferral of 'economic rights' created by an employee upon his or her employer - implies that residual moral rights remain with the employee. The issue is not a problem in the UK where - arguably contrary to the Berne Convention - the Copyright Designs and Patents Act 1988 excludes moral rights in relation to computer programs 8. However, on the continent, things are different. In Henri Bodin v Agospap, the French courts, recently held that an independent software engineer, could rely on moral rights to prevent the adaptation of software by the commissioner of the software. That said, in the contract between the parties there was a provision which provided that only the software engineer was authorized to carry out such adaptations, tt is doubtful whether moral rights alone could have been invoked to prevent adaptation by Agospap. However, the moral is: although moral rights cannot be assigned, consideration should be given as to whether they should be waived in contracts of employment or contracts commissioning the development of software. The Commission's initial draft contained provision dealing with computer-generated programs. It provided that the natural or legal person responsible for the generation of the program was entitled to exercise all rights in respect of the program, unless otherwise provided by contract. In debates before the Parliament, this provision was considered to be ahead of its time. Consequently, it was dropped.

Page 4: Council directive of 14 May 1991 on the legal protection of computer programs (91/250/EEC)

.................................................................................... Curreni De~;eiopment in European Information TecIlnoiogi;i~a;;; .........................................................................................................

4. THE BUNDLE OF EXCLUSIVE RIGHTS The Directive grants to authors a generous bundle of exclusive rights, governing the reproduction, adaptation and distribution of the program. These include the following: (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, transmis- sion or storage of the computer program, necessitate such reproduction, such acts shall be subject to authorization by the rightholder;

(b) The translation, adaptation, arrangement and any other alteration of a computer program and the representation of the results thereof, without prejudice to the rights of the person who alters the program;

(c) Any form of distribution to the public, including the rental, of the original computer program or of copies thereof. The first sale in the Community of a copy of a program by the rightholder or with his consent shall exhaust the distribution right within the Community of that copy, with the exception of the right to control further rental of the program or a copy thereof.

It should be noted that the distribution right will only be exhausted upon sale of the program. It will not be exhausted by the licensing of the program.

5. EXCEPTIONS TO THE EXCLUSIVE RIGHTS The debate over the legitimacy of reverse analysis of computer programs was at the heart of controversy sparked off by the Directive. Briefly the problem is as follows. Copyright does not protect ideas, only the expression of those ideas. In most literary works discovering the underlying ideas does not involve copying: I can discover the impious thoughts buried in Salman Rushdie's Satanic Verses without breaching copyright (provid- ing I have bought or borrowed a legitimate copy of the book). For software, the situation is different. In order to discover the ideas, I must translate the series of 0s and ls (the so-called 'machine' or 'object' code) into human-readable form. This translation, known as 'decompilatian', is traditionally a restricted act. However, failure to allow an exception for this type of translation would mean that copyright would effectively extend to unprotectable ideas. Industry was divided into two camps over this issue. The Software Action Group for Europe (SAGE) led by IBM, Digital, Microsoft and Lotus argued that reverse analysis would amount to a pirates' charter. The European Committee for Interoperable Systems (ECIS), grouping companies such as Bull, Olivetti, Fujitsu and NCR, on the other hand, asserted that the protection of software as a literary work would have the effect of stifling innovative competition from interoperable products. To add to the confusion, the Commission services were frequently disunited. The compromise eventually reached is contained in Articles 5 and 6 of the Directive. Article 5 permits, so-called 'black box' analysis (the studying of the ideas underlying the program by loading and running it), as well as allowing users to undertake a limited degree of maintenance without having to seek the licensor's authorization. Article 6 allows for decompilation of computer programs, but on condition that this is done to achieve the interoperability of independently created pro- grams.

6. GENERAL EXCEPTIONS TO THE RESTRICTED ACTS: ARTICLE 5

A) MAINTENANCE Modification or adaptation of the expression of software is a restricted act, pursuant to Article 4(b). The economic justification for such protection is apparent: failure to protect the author from such adaptations would allow unscrupulous copying of the original program. By adding a few minor modifications and claiming the new program as his or her own, the modifier would free-ride the intellectual and financial investment of the author. However, licensees often need to be able to adapt their programs in order to use them. The rigid application of copyright law principles to functional works in these circumstances can have the effect of granting de facto monopolies for services beyond the scope of the right, such as maintenance or systems integration. The Commission's draft Directive recognized the problem. It thus provided exceptions to the exclusive rights so as to allow "acts necessary for use of the program". Whereas purchasers of software and shrink-wrap licensees could benefit from this exception, the exception did not apply where the software was made available by "a written licence agreement signed by both parties". The Commission thereby wished to encourage licensors to enter into agreements which would be read and signed at the point of sale; in return, licensors would be free to determine their terms and conditions. Users predicted grave consequences and lobbied heavily to have broader exceptions. Software producers resisted. The Commission reached a compromise. Unfortunately, the final text echoes both views. Indeed the Directive contains language which is diametrically opposed. Article 5(1) provides:

l/In the absence of specific contractual provisions, the acts referred to in Article 4(a) and (b) shall not require authorization by the rightholder where they are necessary for the use of the computer program by the lawful acquirer in accordance with its intended purpose, including for error correction." [emphasis added]

The first observation to make is that the Directive grants a bundle of exclusive rights to the rightholder under Article 4. It then provides that these rights may not be enforced in certain circumstances unless accompanied by a contractual provision. However, the language of Article 5(1) is at odds with Recital 18, which purports to limit the contracting out of the exception as follows:

"Whereas the exclusive rights of the author to prevent the unauthorized reproduction of his work have to be subject to a limited exception in the case of a computer program to allow reproduction technically necessary for the use of the program by the lawful acquirer; Whereas this means that the acts of loading and running necessary for the use of a copy of a program which has been lawfully acquired, and the act of correction of its errors, may not be prohibited by contract." [emphasis added]

Clauses excluding error correction by the licensee may be invalid under Article 9 of the Directive (or at least outside the specific subject-matter of the right and thus vulnerable under Article 85 of the EEC Treaty). In light of this uncertainty, licensors should determine their

Page 5: Council directive of 14 May 1991 on the legal protection of computer programs (91/250/EEC)

Current Development in European Information Technology Law

position on error correction. For some licensors, provided error correction is subject to reasonable constraints, e.g. an obligation upon the licensee to notify any corrections within a given time, allowing error correction may bring positive benefits: greater information about errors - especially valuable for producing up-dates; customer satisfaction; and, generally, greater legal certainty regarding the prohibition of other, potentially more prejudicial adaptations or modifica- tions. That said, in the UK, Recital 18 seems to have been overlooked in the transposition of the Directive. Thus, for contracts governed by UK law, licensors can presently exclude error correction (subject to the application of the competition rules).

B) THE MAKING OF A BACK-UP COPY The Directive explicitly stipulates that the making of a back-up copy by a person having the right to use a program cannot be prevented by contract, provided always that the back-up is necessary for use of the program.

C. BLACK-BOX ANALYSIS Article 5(3) provides:

"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." [so-called 'black-box' analysis] (emphasis added)

This exception, which was incorporated at the instigation of the European Parliament, allows the lawful user the right to analyse the performance of the software whilst carrying out non-infringing acts, which either by virtue of the Directive or by virtue of contract he is entitled to do. It is important to note that unlike the decompilation exception in Article 6, Article 5 (3) is not confined to the discovery of ideas and principles underlying interfaces: all ideas and principles can be discovered this way. To reinforce this entitlement, Article 9 provides that any contractual provisions contrary to Article 5(3) shall be void.

7. DECOMPILATION There was fierce controversy over the desirability of allowing decompilation. Once it became clear that the European Parliament and the Commission were in favour of a limited decompilation exception, the question was what form the exception should take, and for what purpose the exception should be allowed. As to the form, Anglo-Saxon commentators typically argued for the incorporation of a 'fair-dealing' or a 'fair-use' exception, thereby leaving it to national judges to determine, in the light of the circumstances, whether the translation of the code into human-readable form was fair or not. The Commission retorted that while such a pragmatic mechanism operated smoothly in common law systems, it could not be readily transplanted into civil law systems. The Commission therefore set about the task of codifying the fair use exception for decompilation.

As to the permitted objective of decompilation, there was and still is intense debate as to whether it can be undertaken for the purpose of creating substitutable, as opposed to merely attaching products. The Directive provides that the program's code can be translated where it is:

"..indispensable to obtain the information necessary to achieve the interoperability of an independently created program with other programs..."

The conventional definition of 'interoperability' as well as language in the Recitals, appears to allow decompilation for the purposes of creating a substitute product. Moreover, point 4(7) of the Commission's communication to Parliament 1° provides:

"Decompilation is permitted by Article 6 to the extent necessary to ensure the interoperability of an independently created computer program. Such a program may connect to the program subject to decompilation. Alternatively it may compete with the decornpiled program and in such cases will not normally connect to it...'/11[emphasis added]

A further debate, was whether decompilation could be undertaken to create interoperable hardware (as opposed to software). An analysis of the body of the Directive suggests not. However, the definition of 'interfaces' in the Recitals refers both to hardware-software interfaces as well as to software- software interfaces. So there remains an element of doubt. While decompilation may be relied upon to obtain interface information, potential decompilers should satisfy themselves that the three conditions laid down in Article 6(1) are met, namely: (a) [decompilation] is performed by the licensee or by

another person having a right to use a copy of the program, or their behalf by a person authorized to do so;

(b) the information necessary to achieve interoperability has not previously been [made] readily available to the persons referred to in subparagraph (a); and

(c) these acts are confined to the parts of the original program which are necessary to achieve interoperability."

For licensors who do not wish to have their programs decompiled, one solution is to make the information readily available. But, companies relying on this option to side-step Article 6 should be prudent. The term "readily available" is sufficiently vague to invite challenge. Licensees and licensors are likely to take opposing views of exactly when information is "readily available u. In addition: (a) the administrative burdens should not be overlooked: all

interface information must be available. There may be cases where licensees seek to interface their products at points which the licensor has not produced information;

(b) Article 6 talks about information "previously/" having been made available. Thus, to rely on this strategy, information must be already available when the licensee discovers the need for it;

(c) there should not be inordinate delay by the licensor in making available the information; and

(d) the information must, of course, be accurate. At the end of the day, the acid test will be: does the scheme frustrate the goal of interoperability contained in Article 6? This is a question of fact which may fall to be examined either by the national courts, or by the Commission. This test will also apply to any fee which a licensor may choose

6

Page 6: Council directive of 14 May 1991 on the legal protection of computer programs (91/250/EEC)

Current Development in European Information Technology Law . . . . . . . . . . . . . , . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , , , , . . . . . .

to raise in respect of the interface information thereby made available. While the Directive is silent on the issue of payment, some commentators suggest that Article 6(3) - which provides that the decompilation exception shall not unreason- ably prejudice the rightholder's legitimate interests - supports the view that a fee for the information can be levied. While reasonable administrative charges are unlikely to meet with strong opposition, supplementary royalties would need to be proportionate to the actual costs of developing the interface and not run counter to the Directive's objectives. Thus, royalties should not be so high as to deter the interoperability of programs written by small and medium-sized software houses. Because it may be difficult prior to translating the machine code of a program to distinguish those parts relating to the interface and those which do not, some commentators have been prompted to assert that decompilation will rarely be an acceptable means of discovering interface information. They argue, the third condition which requires the decompiler to confine his acts to the parts of the original program which are necessary for interoperability will not be met. This interpreta- tion seems counter-intuitive. Why would the Commission have gone to the trouble of constructing such a Byzantine derogation, in Article 6 if it could not be relied upon? In practice, the decompiler should confine the translation, as far as is practicable, to the parts he or she needs, and not use the process as an excuse to plunder the 'Crown jewels' of the original program. In other words, while decompilation can be used to discover a program's interfaces and their underlying ideas and principles, it cannot be used as a tool for exploring the ideas and principles underlying a program in their entirety. It is desirable to document the process of decompilation in the event of a subsequent challenge by the rightholder of the original program. Clean room procedures, while not required, are desirable. A further issue raised to dilute the impact of the decompilation exception is the requirement that the new program should be independently created. Those seeking to limit decompilation argue that the independent program must be in finished form prior to decompilation. In practice, this is not how programs are written. First, the parameters, such as the interface information and industry standards are established, then the details are added. So, the independent programmer will typically need to decompile early on in the process where the interface information is not available in publicly accessible materials. It would appear, therefore, that this condition is fulfilled if, once the final product emerges, it is not substantially similar to the expression of the original program. Once the information has been legitimately obtained, the Directive provides three restrictions on its use. The information: (1) cannot be used for goals other than those of achieving

the interoperability of the independently created pro- gram;

(2) cannot be given to others, except when necessary for the interoperability of the independently created computer program; and

(3) cannot be used for the development, production or marketing of a computer program substantially similar in its expression, or for any other act which infringes copyright.

These restrictions are designed to placate those who feared

that permitting decompilation would encourage misuse. In the same vein, Article 6(3) makes a superfluous reference to Article 9(2) of the Berne Convention (to which the Member States are, in any event, signatories), in order to reassure potential critics that Article 6 does not amount to a Pirates' Charter. While this provision is not intended to introduce further restrictions on decompilation beyond those contained in Article 6(1) and 6(2), it does lend weight to the proposition that a payment for the information voluntarily made available may be levied, always provided that the sum is reasonable. It is important to bear in mind that the Directive is without prejudice to the application of Article 86 of the EEC Treaty. This will be especially relevant where a dominant supplier refuses to make information available which is necessary for interoper- ability (Recital 27). Aware of the sensitivity of this particular topic, the Commission attached to the draft Software Directive guidance on its interaction with the competition rules 12. The Commission observed:

"Companies in a dominant position must not abuse the position within the meaning of Article 86 of the Treaty. For example, under certain circumstances the exercise of copyright as to aspects of a program, which other companies need to use in order to write compatible programs, could amount to such an abuse. This could also be the case if a dominant company tries to use its exclusive rights in one product to gain an unfair advantage in relation to one or more products not covered by these rights. Furthermore, the ability of a competing manufacturer to write an independent but compatible program often depends on his possibility to have access to the target program or to certain information relating to it. Access to interface information is not a matter of copyright law. Article 86 always applies where a dominant company abusively refuses access to such information or restricts unreasonably such access./~

Thus, irrespective of conditions restricting the application of the derogation in Article 6(2), the refusal by a dominant supplier to make available interface information to allow independent producers' products to operate and function in the same manner as the dominant supplier's own products may amount to an abuse under Article 86. In these circumstances, the exertion of intellectual property rights over the interface may constitute an attempt by the rightholder to extend the effects of the exclusive rights into neighbouring areas not covered by such rights. This is analogous to the US doctrine of patent or copyright misuse which condemns rightholders who project "the economic effort of [their] admittedly valid grant beyond the limits of [their] legal monopoly n13. It is also the pervading logic of the Court of First Instance's ruling in Magil114 .

8. SECONDARY INFRINGEMENT To prove it was not 'soft' on piracy, the Commission reinforced the provisions against secondary infringement. Thus, national laws have to provide 'appropriate remedies' against anyone who puts an infringing copy into circulation or possesses a copy for commercial purposes. In both cases, direct knowledge that the copy is an infringement is not necessary, an objective test is applied. Member States must similarly provide remedies against a person who puts into circulation or possession for

Page 7: Council directive of 14 May 1991 on the legal protection of computer programs (91/250/EEC)

Current Development in European Information Technology Law . . . . . . . . . . . . . , . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , , , , . . . .

commercial purposes, devices designed to circumvent technical means to protect a computer program from infringement. Article 7(2) provides that any infringing copy of a computer program shall be liable to seizure in accordance with national law. Unfortunately, procedures in the Member States are far from uniform. It is perhaps to be regretted, therefore, that these procedural aspects were not addressed.

9. THE TERM OF PROTECTION The term of protection provided in the Directive is 50 years after the death of the author or after the death of the last surviving author. In the case of legal persons, protection shall extend to 50 years from the time the program has been made available to the public. However, the 50-year periods will be extended to 70 years following the entry into force of the Term of Protection Directive is on 1 July 1995.

10. CONTINUED APPLICATION OF OTHER LEGAL PROVISIONS Article 9 of the Directive provides that the Directive does not prejudice any other legal provision such as patents, trade marks, unfair competition, trade secrets or semiconductor protection. In practice, therefore, rightholders may seek to reinforce copyright protection with other legal measures. In the US, the trend is towards a growing number of patent applications to protect software. There are signs that this trend is being mirrored within the Community (albeit with less intensity). In addition, rightholders may claim that the uncopyrightable ideas and principles underlying a program are protected by trade secrets, although the secrecy of the underlying interfaces is doubtful as a result of the decompila- tion right set forth in Article 6. Article 9(1) also provides that contractual provisions which purport to exclude the legitimate user's right to make a back- up copy, undertake 'black-box' analysis or decompile will be null and void. In addition, if such clauses are also caught by Article 85(1), and no individual exemption is granted under Article 85(3), then the licensor may be exposed to a fine from the Commission, (pursuant to Article 15 of Regulation 17~e). Article 9(2) provides that while the Directive shall apply to programs created before 1 January 1993 (thereby granting protection to German programs previously ineligible for protection), it does not prejudice contracts concluded before that date. However, where contractual restrictions on reverse analysis and decompilation (previously very common) have an anti-competitive effect, pre-1 January 1993 contracts may be caught by Article 85(1) of the Treaty. Article 85 will not prevented from applying as a result of a deadline contained in a Directive.

11. IMPLEMENTATION Member States had to implement the Directive before 1 January 1993. Not all Member States have yet done so. Those that have, have not adopted a consistent approach. While some Member States have carefully tailored their existing legislation to meet the requirements of the Directive, others have incorporated the text of the Directive into national law. The former approach carries greater risks. The UK, for example, chose to amend the 1988 Copyright

Designs and Patents Act, as opposed to adopting a new software-specific law. In so doing, one aspect of the Directive was omitted. Under the UK legislation, users do not have a right to correct errors, that is to say, licensors can prevent this activity by contract (provided always that such a prohibition is not deemed to be caught by Article 85(1) of the EEC Treaty). While this interpretation conforms with Article 5(1) of the Directive, it is inconsistent with Recital 18. Differences may, therefore, exist as between Member States. So when checking the level of protection available in each Member State, it is essential to refer to the national implementing legislation, as well as to the Directive which it purports to transpose.

IV C O N C L U S I O N Generally speaking, the directive has a significant impact for four main reasons: 1. It harmonizes software protection in the EC [and in the

EEA, since the Directive forms part of the acquis communautaire to be adopted by the EFTA states 17 (with exception of Switzerland)];

2. It constitutes the basis for Community negotiations to ensure equally high level of protection for software in third countries such as Hungary, Poland, Bulgaria, Romania, Albania and the Czech and Slovak Republics;

3. It forms a common legislative platform upon which the application of the EEC and EEA competition rules can be applied.

4. It necessitates a review of licensing policies. In particular, the following clauses merit attention: - clauses which unconditionally prohibit reverse analysis

or decompilation; -clauses which prohibit minor modifications (error

correction) by the licensee. - clauses which have the effect of tying maintenance to

the provision of the software. To sum up, the Directive was the first legislative attempt to address the threat to competition caused by the copyright protection of computer software as a literary work. The incorporation of the exceptions in Articles 5 and 6 is a laudable attempt to achieve a balance between the interests of right holders on the one hand, and those of creators of compatible products on the other. The solution is far from tidy and many of the outstanding uncertainties are only likely to be resolved by resort to litigation. That said, the Directive has made a positive contribution to the international debate on the issue of software protection and is likely to act as a model for other jurisdictions contemplating the adoption of similar legislation (particularly in central and eastern Europe). In addition, subsequent to the adoption of the Directive, two cases decided in the United States, namely Sega Enterprises Ltd. v Accodade, Inc. 18, and Atari Games Corp. v Nintendo of America, Inc. 19, have endorsed the general approach under- lying the Directive. Finally, it continues to form the basis of the Commission's negotiating mandate within the context of the WIPO discussions on the protocol to the Berne Convention on the protection of computer software. Mark Powell Forrester Norall & Sutton

Page 8: Council directive of 14 May 1991 on the legal protection of computer programs (91/250/EEC)

Current Development in European Information Technology Law

FOOTNOTES ~Coundl Directive 91/250/EEC on the legal protection of computer programs, OJ 1991 No. L 122/42. ZCase C-106/89, Marleasing SA de Alimentacion v La Commercial I ~ 1 6re0 [1990] ECR 4135. 3Article 1(2) of the Directive. 41989 OJ C 91/4. SSee Nimmer, Bemacchi and Frischling - nAnatyzing Substantial Similarity in Computer Software Infringement Cases" - 6 The Computer Lawyer, January and February 1989. 6John Ridlardson Computer Ltd. v Flanders and Chemtec Ltd., ruling of Mr Justice Ferris in the English High Court of Justice on 19 February 1993. 7See, UThe Development of lnteroperabte Products Under the EC Software Directive/~ Thomas C. Vinje, The Computer Lawyer, Volume 8, Number 11, November 1991. Mr. Justice Ferris held: "... where the author of a work creates that work in the course of his engagement as an independent contractor to another, any copyright in that work belongs in taw to the author and not to the party to whom he engaged himself to supply the services. But in appropriate circumstances it may appear that the author is regarded as holding copyright in trust to the person to whom he engaged himself. ~ SSection 79 (2) of the UK Copyright Designs and Patents Act 1988. 9Artide 46 of Law 85-660, 3 July t985 provides that "[un]less

otherwise stipulated, the author may not oppose adaptation of the software within the limits of the rights he has assigned nor exercises his right to correct or to retract." 1°SEC(91) 87 final - SYN 183. l~ln addition, Mr H.C. Overbury, Head of the Merger Task Force, addressing a conference on the Directive in March last year, delivered a speech entitled 'the Proposed EEC Directive on the Legal Protection of Computer Programs' in which he said: "The Commission believes that where necessary, therefore, it will be possible for competitors to extract interface information which is not covered by copyright by analysis techniques so as to develop interoperable products. These interoperable products may be attaching products or they may be competing products." lZOJ 1989 No. C91/16.13Panther Pumps & Equip Co v Hydrocraft Inc. 468 F. 2nd 225, 231 (7th Circuit 1972). l~Case %69/89, RTE v Commission [1991] ECR 11-485. lSproposal for a Council Directive harmonizing the term of protection of copyright and certain related rights, OJ 1992, No. C92/6. 16Council Regulation No. 17162 of 6 February 1962, OH 1962 13/ 204. 17Annex XVtl, point 5 of the EEA Agreement. 18977 F. 2d t510 (gth Cir. t992) amended 1993 US App. LEX is 78 (gth Cir. 1993) 19975 F.2d 832 (Fed. Circ. 1992).

9