Journal of Law, Information and Science
|
|
Home
| Databases
| WorldLII
| Search
| Feedback
Journal of Law, Information and Science |
|
by DANIEL HUNTER[*]
This paper discusses two aspects of the recent Copyright Law Review Committee’s Draft Report on changes to the Copyright Act necessary to protect computer software. It focuses on the two different types of non-literal copyright as analysed in the USA, and upon reverse engineering. Its thesis is that the CLRC has made a number of confusing recommendations in relation to these matters. As for non-literal copyright, this paper argues that the CLRC has failed to recognise adequately the special nature of non-literal copyright and has confused the two different types. In relation to reverse engineering, the paper suggests that the CLRC is correct in creating its purposive test for infringement by reverse engineering, but notes that the provisions of the Circuit Layouts Act have been ignored. It concludes with some scenarios which the author suggests show the inconsistencies between the CLRC Draft Report and the technology which it addresses.
I come not to praise the CLRCaesar, but to bury it.
(With apologies to William Shakespeare)
This paper examines some aspects of the recent Copyright Law Review Committee’s Draft Report on Computer Software Protection.[1] In particular I wish to present some limitations on the recommendations contained in the report in relation to non-literal copyright and reverse engineering of computer software. My thesis will be that the Copyright Law Review Committee (CLRC) has made some recommendations which are unsustainable, fraught with danger should they be implemented, and in certain respects technologically naive. This paper reflects the scope of my topic, and is divided into two main sections: the first section discusses the two types of non-literal copyright, and the second section examines the recommendations on reverse engineering.
The starting point of an examination of copyright in non-literal elements of computer software must be what we mean by ‘non-literal elements’. I have suggested previously, on it seems innumerable occasions,[2] that we must divide what we consider non-literal components into two categories—copyright in program structure and copyright in program ‘look and feel’. I will first describe what I mean by the two terms before looking at why we need to divide them in order to properly assess whether either of them is worthy of copyright.
The concept of program structure refers to the structure of the computer program as a literary work. That is, the organisation of the program code, the order in which it is placed, and the modules or functions which go together to make up the program code. It includes what operations each function is supposed to perform, how the functions/objects/modules communicate with each other, and so forth. The ‘look and feel’ of a computer program is a dangerous word which really means its user interface; the way in which it presents the data to the user, and the way in which the user perceives the displays of the program.
So, why must we divide them? First, the two elements are entirely independent. The CLRC initially recognised this fact. It adopted the argument of Professor Randy Davis, a noted artificial intelligence researcher who runs the Artificial Intelligence Lab at Massachusetts Institute of Technology and who was the court appointed expert in a recent influential American computer copyright case.[3] Davis wrote a number of papers based on his report to the judge in that case[4] where he argues that program code is independent of the way in which the program appears on the screen. On the basis of Davis’ argument, the CLRC quite properly accepted that the two are not necessarily related.[5] I will return to what Davis has argued as a consequence of this, and what the CLRC said on program structure shortly.
Another reason what we should not confuse the two is, as a consequence of them being unrelated, they deal with differing aspects of software. Program structure is simply concerned with the textual elements of the program, albeit at a higher level of abstraction than mere code. The ‘look and feel’ of the program is concerned with the presentation of the user interface and the use of the computer, and has no aspect of textual copyright involved in it. It is concerned, at its most fundamental, with visual appearances.
In the past, courts have confused the two types of non-literal expression. As soon as courts begin to merge the two types we end up with an unholy mess, where textual copyright considerations are imported into a visual context, and vice versa. The cases which have merged these concepts have been so confusing as to make the decisions virtually meaningless.[6] As a consequence, in the United States where the courts have dealt with these questions for some time, the cases make clear that there must be a distinction made between the non-literal element which we call program structure and the non-literal element called ‘look and feel’.[7]
What then did the CLRC say about this dichotomy? It is somewhat difficult to determine whether they do distinguish between the two forms of non-literal expression. After discussing Randy Davis’ distinction between the two, the CLRC first said:
‘The Committee regards these behavioural aspects of a computer program [ie the look and feel] as its non-code or non-textual (“non-literal”) elements.’[8]
At this point, it seems that program structure is not expressly identified as a non-literal element. But no, the next paragraph modifies this,
‘As such, the “non-literal elements” of a program will include both the structure, sequence and organisation of a program’s behaviour [ie the look and feel] and the structure, sequence and organisation of its underlying code [ie the program code structure]’[9]
A couple of comments immediately occur to me. First, why did the CLRC add notions of structure into their definition of ‘look and feel’? This is the kind of reasoning which lead to some unfortunate US decisions early in the development of this area. One might have hoped that the CLRC would have learnt from these cases. Secondly, why did it use ‘structure, sequence and organisation’ when what it was describing was program ‘structure’? Readers familiar with the case of Whelan v Jaslow[10] will recognise the words. It is the concatenation of these words which has caused concern on the part of commentators. The problem is that the words are not synonymous. The ‘structure’ and ‘organisation’ of a computer program comprise the ‘skeleton’ of the work. It is the basic way in which the modules/functions/objects are set out, how they communicate with each other, how they are divided up, and so forth. The sequence can really only refer to the order in which the programmer places the lines of code, or perhaps the order of placing the modules. Thus, ‘sequence’ works at a lower level than either ‘structure’ or ‘organisation’, and as Professor Davis has argued, is irrelevant to the eventual program operation.[11] In order to avoid these concerns I would argue that we should use the expression program structure, or program code structure, and no technical inconsistency occurs.
But enough of these word games, what did the CLRC decide?
‘The Committee considers that the “non-literal” elements of computer programs comprising the “structure, sequence and organisation” of the program code lend themselves to protection by copyright in the same manner and to the same extent as traditional literary works.’[12]
Although its reasoning is confused and it seemed unable to make a clear distinction between program structure and ‘look and feel’,[13] it seems that the CLRC advocated a ‘hands-off’ approach on the question of copyright in program structure.
While I have no difficulty with the CLRC’s apparent conclusion that copyright does protect program structure, I am somewhat more troubled by the fact that the CLRC did not bother to discuss the issue in any more depth. It merely said that program structure was the same as traditional literary work copyright. This point I think is worthy of some further discussion
It is I believe important to consider two aspects of copyright in program structure: first the notion of a program as text, and second the reasons why program developers care about program structure.
Andrew Christie argues very cogently that some aspects of computer software do not lend themselves to copyright protection, and he is no doubt absolutely correct.[14] However, I would argue very strongly that program structure is one feature of software which shares many of the same features as traditional literary works.[15] A comparison between features of program structure and book structure is given in figure 1.
Figure 1
Though there are a number of features which software structure has which book structure does not, the similarities are sufficient to argue that we may use traditional literary work copyright concepts in examining this area. Indeed, this is the (unreasoned) argument of the CLRC.
Randy Davis, in his papers previously mentioned argues that program structure cannot be copyright and cannot be analogised to book structure because the order of code is largely irrelevant to the operation of the program. For example, a program may be ordered in the two ways represented in Figure 2, and there will be no difference in the output.
Figure 2
This, Davis argues, distinguishes program structure from, for example, book structure. I would argue that it makes no difference. Let us say that a textbook (the closest thing to a utilitarian article in books[16]) is ordered as shown in figure 3. What happens if someone comes along, rewrites the textbook in slightly different form but retains the same ideas in each chapter, paragraph, and even sentence. Precisely this occurred in an American case[17] and the court had no problem finding that copyright subsisted in the structure of the book, and that an infringement had occurred. Would this be any different if the order of presentation of the chapters were swapped in the plagiarist’s book, as shown in figure 4? I suggest not. It would be a largely immaterial difference and the courts have never allowed a plagiarists to profit in this manner by such immaterial differences.
Figure 3
Figure 4
A further criticism of protecting computer program structure rests, as so many of these arguments rest, upon the idea/expression dichotomy. We protect the expression of an idea but not the idea itself. This, the pundits say, means that program structure cannot be protected because it is just the idea of the program. This argument can be dispatched simply by recognising that there is a continuum which runs between the concrete expression of code at one end and the unprotected idea of what the program does.[18] Just because the structure might be more abstract than the clearly protected code should not mean it is necessarily an idea, it may still be expression. As I have previously argued, program structure is clearly a form of expression, and I would go further and argue that it is the most important type of expression in these days of structured programming techniques, object oriented languages, and computer aided software engineering tools.[19]
Given that program structure is not so different from book structure, it is instructive to consider why the original developers of computer software are interested in protecting their program structure. The reasons are shown by reading the two US cases which have dealt directly with the issue, Whelan v Jaslow[20] and Computer Associates v Altai.[21]
The developers wish to stop appropriation of their program structure for two reasons:
1. to stop others from porting their program to another system (Whelan v Jaslow); or
2. to stop others from developing competing products by using the original developer’s structure. (Computer Associates)
Both these matters have in fact been dealt with by the CLRC, in its discussion of reverse engineering. It postulated a series of reasons why a competitor might want to reverse engineer another’s program. One type of reverse engineering involves reverse engineering of a competitor’s program structure. The CLRC (quite rightly in my opinion) indicated that reverse engineering for the purposes of porting or for creating a competing copy were not those which it thought were permissible ends and for which exceptions to copyright should be made.[22]
I will make some comments in relation to reverse engineering shortly, but before doing so wish to discuss briefly that other component of non-literal copying—look and feel.
The term ‘look and feel’ is a problematic one. At times it has been used to describe the user interface, the sequence of displays of a computer program, the test for infringement for both, and a range of other formulations. The questions here should be, ‘What did the CLRC decide was meant by “look and feel” and is it right?’
The CLRC thought that the term ‘look and feel’ conflates to the expression ‘behavioural aspects of a computer program.’[23] While the expression ‘user interface’ was preferred by a number of vendors and I would argue more accurately describes what it is we are fighting over, the CLRC seems to have rejected its use.
Having found a definition, the CLRC then examined the various arguments for and against protection. Its conclusion was that the ‘behavioural aspects’ were not protected,
‘Copyright protection should be confined to the expression of ideas in a material form and not extend to protection of behavioural aspects of programs...The protection of function is not and should not be an object of copyright protection.’[24]
Then the Committee did a curious thing: having dismissed copyright protection for ‘look and feel’ it felt somehow compelled to discuss the economic considerations of whether we should protect ‘look and feel’. This strikes me as curious, because the CLRC had no need to discuss this—it had already said that the ‘look and feel’ was just the unprotected idea. Its conclusion on the economic issue was interesting:
‘...[W]here such [copyright] protection, if it did extend to behaviour, would impede or cause a developing industry to become less efficient, consideration must also be given to the underlying goals and fundamental principles of copyright...[W]here copyright would not advance the overriding “public welfare” it should not be granted.’[25]
I do not have time to develop my arguments against the CLRC’s reasoning in very great detail, so I will simply make a few comments in relation to it.
First, I believe that the CLRC is wrong in labelling ‘look and feel’ as ‘program behaviour’. Once they had done this, it was but a small step to conclude that program behaviour is an idea and no more, and hence is not copyright. I am not convinced altogether that we should protect user interfaces.[26] However, I suggest that if the CLRC had decided that the ‘look and feel’ was an expression of ideas of the function of conveying information to and from the user, then its conclusion might have been different. Of course, this is like saying that if the judge had seen the case from the other side then the outcome would have been totally different. However, my argument is that the CLRC’s conclusion was almost immediately concluded once it decided that user interfaces were merely ‘program behaviour’. And where did it come up with such an expression? It adopted the expression from Randy Davis’ paper, which the CLRC has in its hot little hands by virtue of the fact that one of its members attended a WIPO conference where Professor Davis spoke.[27] Randy Davis has been very influential in computer copyright of late. His report virtually decided the Computer Associates case where he was the expert, and I would argue that his paper based on that report has decided the outcome of the CLRC’s inquiry into protection of user interfaces.
The second point I would like to make focuses on the economic considerations which the CLRC used to deny copyright protection on public policy grounds. The Committee argued that:
‘...[T]he need for standardisation and for efficient user interfaces to be used and developed outweighs the need to grant authors copyright in the “look and feel” of their programs’ behaviour.’
This stance is predicated on the age-old balancing act in copyright: how do we foster innovation which is in society’s interest, without granting monopolies which are against society’s interest? Many would argue that we already do this by asserting that only expression may be copyright, a point in relation to user interfaces I have already mentioned.
Alternatively, we might argue that an economic analysis such as the CLRC’s is the way to balance this concern. Now I am not an economist[28] but one point strikes me. The CLRC’s argument that we need standardisation in user interfaces relies upon an economic concept called ‘network externalities’. The principle underlying network externalities is that at a certain point a manufacturer’s control of a market is so great that there is a public benefit if we allow everyone to use the network which the manufacturer has established. A particularly striking example of this line of argument was developed by an American judge in an early computer copyright case.[29] He thought that certain features of computers were like the ‘H-pattern’ gearshift in a car. Once the H-pattern gearshift is commonplace then we should allow all car manufacturers to use it, since it would avoid retraining drivers every time one went from a Ford car to a Nissan car to a General Motors car.
The CLRC’s standardisation argument is based on this principle. Now, most economists would say that we only need to worry about network externalities when the network becomes sufficiently large that a public benefit can be extracted by allowing everyone to use the network. This seems to me to be unfair. The economists want to take away the benefit that copyright gives only if the copyright work is extremely successful. It is only if the user interface is by far the best on the market and has huge public acceptance that we remove copyright protection. My economic argument in response is that a manufacturer will soon realise that there is nothing to be gained from creating a wonderful interface, because then the protection of copyright will quickly be removed on the grounds of network externalities. So the manufacturer creates a good (but not the best) interface in order to gain some copyright protection. This is a misallocation of resources and is hence contrary to the same economic arguments raised for network externalities in the first place.
However, the CLRC does not even begin to move along this path. It does not seek to perform any economic analysis, and says baldly that ‘Thou shalt have no copyright in user interfaces because of standardisation concerns.’ This seems to me to be inadequate. If the CLRC is to call upon the gods of economics to justify its public policy stance then it must be prepared to explain why standardisation is such an issue here. The CLRC Draft Report denies all protection for user interfaces irrespective of the degree of success in the market; yet it does not seem to recognise that network externalities arise only if the product is successful.
I turn now from non-literal copyright to the question of reverse engineering. I have in some ways introduced this question when examining the question of copyright in program structure, but now I look at reverse engineering of any aspect of computer software and do not limit my discussion to structural matters.
The CLRC suggests a number of purposes for which reverse engineering may be undertaken. These include for the purposes of producing interoperable products and for correcting bugs in software. Other purposes, such as porting, were correctly identified as involving acts by competitors to undermine the original developer’s position. The CLRC recommended that reverse engineering for these purposes not be allowed.[30]
The great benefit of this division is that focussing on the purpose of the reverse engineering is in keeping with international thinking, and clearly contradicts the disastrous outcome of the Autodesk cases.[31] Focussing on the purpose also has the benefit that it lends some flexibility to questions on reverse engineering as technology changes, though it is not clear whether later technological advances may yet cause difficulties.[32]
My one huge disappointment with the reverse engineering discussion of the CLRC is that not one mention is made of the effect of the Circuit Layouts Act 1989 (Cth).[33] The Circuit Layouts Act provides for reverse engineering in very different circumstances to that which the CLRC discusses. Section 23 of the Act provides:
‘The EL rights in an eligible layout are not infringed:
(a) by making a copy or copies of the layout for the purpose of evaluating or analysing the layout;
(b) by making an original circuit layout based on an evaluation or analysis carried out with the use of a copy or copies referred to in paragraph (a);
(c) by making an integrated circuit in accordance with an original circuit layout referred to in paragraph (b); or
(d) by copying or commercially exploiting in Australia an original circuit layout referred to in paragraph (b).’
This section focuses on whether there has been any ‘evaluation or analysis’ performed in order to produce a copy of the chip or layout. This is very different from the tests proposed by the CLRC which ask whether the purpose of the reverse engineering is, for example, to create an interoperable system.
Now, this difference would have no consequences were it not for the fact that any computer program can be stored on any of the following: silicon chip or floppy disk or hard disk or CD-ROM or DAT or whatever. The manufacturers of software do not determine how to market their programs based upon an analysis of which legal regime is better for them—they market it in the form which is most convenient and which caters to their market. It is not beyond the realm of possibility that different provisions, one from the CLRC in relation to copyright and one from the Circuit Layouts Act, could apply to exactly the same computer software.[34]
The most obvious example of this is the proliferation of computer software games which are marketed on chips, encased in a plastic cartridge and used in games consoles for Sega, Nintendo, Neo-Geo or whatever. Though I do not have the figures I would be prepared to wager that on numbers of units sold, this form of software distribution exceeds distribution on floppy disks. If we adopt the CLRC’s report, then reverse engineering of these games will be governed by the Circuit Layouts Act and can only be performed for the purposes of ‘evaluation or analysis’. Antithetically, floppy disk games for the Macintosh, IBM-PC, Amiga, etc, can be reverse engineered for a range of purposes.
So why did the CLRC not look at this question? I thought at first that it was because it did not fall within the limited terms of reference provided to the Committee. Unfortunately, the CLRC cannot hide behind this defence because it did discuss the overlap between the Copyright Act and the Circuit Layouts Act when examining the parallel importation provisions.[35] It seems to me that their failure to examine the question of reverse engineering in light of the Circuit Layouts Act was a fundamental oversight and one which must be remedied.
While we are looking at this question of overlap, and in particular the question of parallel importation, I would like to make one final criticism. For a long time now people have commented that the provisions of section 24 of the Circuit Layouts Act allow for parallel importation of copyright material.[36] Section 24 specifically allows parallel importation, notwithstanding the fact that the chip contains copyright material. A number of parties made submissions in relation to this point. Unsurprisingly, one of those was the party most affected by the decision in Avel v Wells,[37] that is Avel Pty Ltd. The CLRC describes Avel’s submission in the following terms:
‘[Avel] submitted that simply because the author of a computer program chose to store the program in an EPROM, he or she should not lose copyright protection. Avel also noted that if the same program were stored on a floppy disc, it would not attract the operation of s.24(2) and, accordingly, the copyright owner would still be able to exercise his or her rights to control the importation of the program under the Copyright Act. In other words the effect of s.24(2) is that it discriminates against programs embodied in integrated circuits.’[38]
This appears to this commentator as a remarkable clear, accurate and astute interpretation of the effect of section 24 on software marketed on silicon chips. The Committee however rejected this analysis. Its conclusion was as follows,
‘In summary, the Committee concludes that the policy behind the drafting of s.24(2) can be stated as follows. Circuit layouts and integrated circuits are non-copyright utilitarian articles...The Committee is not persuaded that the apparent policy behind s.24(2) should be altered.’[39]
Now, I am not here as an apologist for those who suggest that we need parallel importation provisions. However, I do suggest that the comments made by the CLRC are technologically naive and even disingenuous. Let me give you an example which is happening right now and which does not focus upon computer games cartridges which some might say are special cases.
In the side of many portable computers nowadays there is dinky little hole. Into that hole one can plug a hardware card, called a PCMCIA[40] card. PCMCIA cards are fast becoming a standard, particularly in IBM PC type machines. This card, which in essence is just a few chips stuck on a PCB can perform a number of functions. It might be what we think of as simply hardware, a modem, or more RAM, or a hard disk. Alternatively, it is possible to buy an EPROM version of your favourite piece of software, Lotus 1-2-3, Word 5, etc. The benefit of this is that because it is on a chip the program runs blindingly fast, and does not chew up a lot of your hard disk and RAM while running. This is not science fiction, it is available and commonplace today.
This means that according to the current regime, if your version of Lotus 1-2-3 comes on floppy disk then you cannot parallel import it because section 37 and 38 of the Copyright Act will not let you. But if you have your version of Lotus 1-2-3 coded on a PCMCIA card, then parallel importation is allowed under section 24 of the Circuit Layouts Act. The CLRC said that chips were only utilitarian and somehow different from copyright works. My only question to this is ‘Who is responsible for this plainly incorrect comment?’
The example I have just given is drawn from current technology. I want to conclude by looking a little further down the track and give some examples where I think that the implications of this become even more troubling.
First, returning to the PCMCIA example, one might argue against me and say, ‘Well, Lotus will wake up to this problem and only chose to market their programs in floppy disk form.’ Maybe. But the new Apple Newton Personal Digital Assistant (‘PDA’) comes standard with a PCMCIA slot, to provide for add-on hardware or software. The Newton and other PDAs which are being developed are not designed for the types of applications which we run on PCs, so they do not come with a floppy disk drive. I do not know, but I would again bet that Lotus is looking seriously at developing a version of Lotus 1-2-3 on a Newton PCMCIA card, which those busy folks who have a Newton can use to input their data while away from their desks. And all manufacturers of software for PDAs will look at providing their software in similar format, since they cannot market it on a floppy disk. If you want to see how this works, but on a lower scale, look at the Sharp Wizard and its clones. You slot in a card and away you go with a new application. Now, the Newton looks like being a runaway success[41] and I can see a very large market for this type of distribution of software. And I can also see these software designers being unhappy with the received wisdom as expressed by the CLRC, that somehow the software that they have on chips is just a ‘utilitarian article’.
The second example is somewhat more unusual, though hardly science fiction. One of the problems with portable CD disk players, whether they be standard size CDs or Sony MiniDiscs, is that they are mechanical. They are thus prone to mechanical breakdown and to jolting as you jog along. Chip manufacturers are managing to pack more and more transistors on a chip as each day goes by. I cannot imagine that it will be too far down the track that it will be possible to fit 75 minutes of music onto a chip. Once that happens, Sony will bring out a portable digital music machine (probably called the Sony ChipMan) which relies on solid state reproduction of music from a chip. At the same time, we may see the marketing of books on chip, for reading on your Apple Newton as you ride the tram to work. It will be at this point, that all our tinkering around the edges of section 37 and 38 of the Copyright Act will be exposed as absolutely meaningless. At this point, section 24 of the Circuit Layouts Act will apply to computer software, music, literature, and probably video. Section 37 and 38 will be dead letters. The CLRC’s comment that somehow chips are just ‘utilitarian articles’ may well be the comment that the Committee members eventually regret the most.
Please do not misunderstand me. Much of what the CLRC has said in its Draft Report is extremely timely, well reasoned and practical. The purpose-based approach on the question of reverse engineering stands out as an excellent response to the various conflicting positions put to the Committee.
My concern with the recommendations is not that they go too far, but they do not go far enough, and in very real senses show an unfamiliarity with the technology itself. I confess that many of my criticisms have been suggested by and developed with my undergraduate computer law students, who understand the technology, who love nothing more than to pull apart current computers, and who can spot legal and technical flaws from a million miles. In a sense I am just their spokesperson.
If perhaps the CLRC sat down with some of these students, discussed what the Committee suggests, then perhaps I would not be here today. As I have said, the CLRC report contains oversights if one looks at the current technology. I have suggested other oversights based on a simple reading of technological developments over the next few years. If there are oversights in the report based on today’s and tomorrow’s technology, then how will we be served by this report in ten years time?
[*] BSc LLB(Hons). Lecturer, Law School, University of Melbourne.
[1] Copyright Law Review Committee, Draft Report on Computer Software Protection, June 1993, ISBN 0-642-19361-4 (‘CLRC Draft Report’).
[2] Hunter, D.A.D., ‘Protecting the “Look and Feel” of Computer Software in the United States and Australia’, (1991) 7 Santa Clara Computer and High Technology Law Journal pp95-155; Hunter, D.A.D., ‘“Look and Feel” in America’, Computers & Law, May 1991, pp1-4; Hunter, D.A.D., ‘The “Look and Feel” Spectre’, Computer Commentary, February 1992, pp55-56, reprinted in (1992) 5 Australian Intellectual Property Law Bulletin, March 1992, pp17-18; Hunter, D.A.D., ‘ “Look and Feel” Computer Copyright in the United States and Australia,’ Part 1 (1992) 3 Australian Intellectual Property Journal pp63-93; Part 2, (1992) 3 Australian Intellectual Property Journal pp164-183.
[3] Computer Associates International, Inc. v Altai, Inc., 775 F.Supp.544, 20 USPQ 2d 1641 (1991) aff’d 23U.S.P.Q.2d 1241, 23 IPR 385 (2d Cir 1992).
[4] Davis, R., ‘Intellectual Property and Software: The Assumptions are Broken’, Massachusetts Institute of Technology Artificial Intelligence Laboratory, A.I.Memo No.1328; Davis, R., ‘The Nature of Software and its Consequences for Establishing and Evaluating Similarity’, Software Law Journal, Vol V, 1992, pp299-330.
[5] Davis’ argument is not the first time this argument has been made. See for example Hunter, D.A.D., ‘Protecting the “Look and Feel” of Computer Software in the United States and Australia’, (1991) 7 Santa Clara Computer and High Technology Law Journal at p115. For that matter, my article was not the first time it had been raised either, see for example M. Kramer Mfg Co., Inc. v. Andrews, 783 F.2d 421, 228 U.S.P.Q. 705 (4th Cir. 1986), cert denied, __ U.S. __, 107 S.Ct. 77 (1987); and to a more limited degree Digital Communications Associates, Inc. v. Softklone Distributing Corporation, 2 U.S.P.Q.2d 1385 (N.D. Ga. 1987).
[6] Broderbund Software, Inc. v. Unison World, Inc., 648 F.Supp. 1125 (N.D. Cal. 1986) stands as the best example of this, though one could argue that Digital Communications Associates, Inc. v. Softklone Distributing Corporation, 2 U.S.P.Q.2d 1385 (N.D. Ga. 1987) is nearly as confusing.
[7] For the reasons advanced above, it is troubling to see that two recent cases decided outside of the USA have used ‘look and feel’ as a magic talisman in deciding program structure questions—in the UK, see John Richardson Computers Ltd v Flanders & Anor 19 February 1993 (unreported) and in Canada, Delrina Corporation v Triolet Systems, Inc. & Anor (1993) 47 Canadian Patent Reports (3d) 1.
[8] CLRC Draft Report, p110.
[9] Ibid
[10] Whelan Associates, Inc. v. Jaslow Dental Laboratories, Inc., 609 F.Supp. 1307 (E.D. Pa. 1985), aff'd[1986] USCA3 976; , 797 F.2d 1222 (3d Cir. 1986), cert. denied, 107 S.Ct. 877 (1987)
[11] See Davis, R., op.cit. footnote 4 above.
[12] Id, pp111-112
[13] A feature which re-appears when it discusses ‘look and feel’ at pp112-116, by discussing the Computer Associates case , a program structure case, when examining ‘look and feel’ questions.
[14] Christie, A., ‘Re-writing the Rules on the Form of Protection for Computer Software’, in this journal.
[15] I am indebted to Andrew who pointed out that my argument in some way begs the question; in fact what we should be doing is asking whether these sorts of analogies are appropriate, not whether they are reasonably close to existing copyright analysis for books, films, art works and so on. Although this part of the paper uses these analogies, perhaps it is indeed time to stop using dangerous metaphors and look at programs afresh. It is ironic to find myself making exactly the same mistakes as the CLRC, but I am pleased to note that I am not alone in making these assumptions.
[16] Some might well argue that in fact tables, such as timetables, statistical tables and so on, are closer to software than textbooks. While this may be true, tables cause difficulties of their own, since they are explicitly covered in the definition of ‘literary work’ in section 10 of the Copyright Act. To say that tables are literary works is an act of legislative sleight-of-hand roughly equivalent to saying that computer programs are literary works. I do not wish to cloud already murky waters by using tables as an analogy here. If we must use tables for analogy (and I would support Andrew Christie and say we should not) then let it be an analogy to data, not software.
[17] Meredith Corp. v. Harper & Row Publishers, Inc., 378F.Supp. 686 (S.D. N.Y.), aff'd, 500 F.2d 1221 (2d Cir. 1974), opinion after trial, 413 F.Supp 385 (S.D. N.Y. 1975)
[18] The famed ‘levels of abstractions’ test of Judge Learned Hand from Nichols v Universal Pictures Corp., 45 F.2d 119, 121 (2d Cir.1930). I have argued this point previously in Hunter, D.A.D., ‘ “Look and Feel” Computer Copyright in the United States and Australia,’ Part 1 (1992) 3 Australian Intellectual Property Journal at p76.
[19] Ibid. Indeed the CLRC quoted my comment in relation to this, CLRC Draft Report, p110. Note also the submission made to the CLRC by International Business Machines, Inc., commented upon by the CLRC at p117.
[20] Whelan Associates, Inc. v. Jaslow Dental Laboratories, Inc., 609 F.Supp. 1307 (E.D. Pa. 1985), aff'd[1986] USCA3 976; , 797 F.2d 1222 (3d Cir. 1986), cert. denied, 107 S.Ct. 877 (1987)
[21] Computer Associates International, Inc. v Altai, Inc., 775 F.Supp.544, 20 USPQ 2d 1641 (1991) aff’d 23U.S.P.Q.2d 1241, 23 IPR 385 (2d Cir 1992)
[22] See generally CLRC Draft Report, pp150-180.
[23] Adopting the arguments of Randy Davis—CLRC Draft Report p106. Other examples where the expression ‘look and feel’ is assumed to mean ‘behavioural aspects’ include pp110, 111, p119, amongst others.
[24] CLRC Draft Report, p119
[25] CLRC Draft Report, p120
[26] There is not space here to develop this idea, though I do note in passing that my previous suggestions (made in the articles cited at footnote 2 above) may not be justifiable. On this point I reserve judgment.
[27] CLRC Draft Report, p105-106
[28] But then neither is anyone on the CLRC so I am in good company.
[29] Synercom Technology, Inc. v. University Computer Co, 462 F.Supp. 1003, 199 U.S.P.Q. 537 (N.D. Tex. 1978)
[30] CLRC Draft Report, pp176-179. Other recommendations were based upon considerations not related to commercial rivalry. Thus, reverse engineering of user interfaces was governed by the discussion of the copyright aspects of ‘look and feel’ previously discussed.
[31] Autodesk, Inc. and Anor v Dyason and Ors [No.1] [1992] HCA 2; (1992) 172 CLR 330; 22 IPR 163; 104 ALR 563; Autodesk, Inc. and Anor v Dyason and Ors [No.2] unreported, High Court, F.C.93/003, 3 March 1993
[32] There is an argument that the many distinctions made by the CLRC poses the problem that, as technology advances, a given instance of reverse engineering falls between two or more purposes expressed by the CLRC. This is always a concern with technology and probably cannot be avoided. Alternatively, the reverse engineering incident might potentially be for two separate purposes, one of which is permissible and one of which is not.
[33] Discussion of the overlap between the Circuit Layouts Act and the Copyright Act was made in relation to parallel importation, CLRC Draft Report, pp188-196. I will discuss these recommendations later in this paper.
[34] Of course, manufacturers may choose to market their software on the medium which is most clearly protected or has the strongest protection, but this is a situation to be avoided where possible. It skews the decision away from purely that of an engineering decision to a legal one, producing an inefficient allocation.
[35] CLRC Draft Report, pp188-196
[36] Sub-section 24(2) provides:
‘In spite of section 37 of the Copyright Act 1968 and section 38 of that Act to the extent that section 38 applies to imported articles, where the commercial exploitation of an integrated circuit containing a copy or adaptation of a work (being an integrated circuit made in accordance with an eligible layout) is not, under this section, an infringement of the EL rights in the layout, that commercial exploitation is not an infringement of the copyright in that work unless the making of that copy or adaptation was an infringement of that copyright.’
[37] [1992] FCA 308; (1992) 23 IPR 353
[38] CLRC Draft Report, p192
[39] CLRC Draft Report, p194
[40] PCMCIA stands for Personal Computer Memory Card Industry Association, the organisation which represents the manufacturers of such cards and which lays down some interface standards for this type of hardware.
[41] Or an unmitigated disaster, depending on whose press you read. There is little doubt however that PDAs of some description will become more and more popular.
AustLII:
Copyright Policy
|
Disclaimers
|
Privacy Policy
|
Feedback
URL: http://www.austlii.edu.au/au/journals/JlLawInfoSci/1993/18.html