Chapter 5: Copyright Protection of Software:
Noncode and Nonliteral Aspects of Computer
Programs—When Does One Computer Program
Infringe the Copyright in Another Even Though
the Codes Are Different?

Preliminary Comment on “SSO”

The preceding chapter considered functional and other constraints on computer programs that required them to have certain features. The chapter addressed whether copyright protection extends to such features, making other programmers not free to use the features without permission from the copyright owner (for example, by license). The chapter concluded with an exposition of the Abstraction – Filtration – Comparison test. This is the currently prevailing legal test for determining whether one computer program is infringingly similar (“substantially similar”) to another, taking duly into account the foregoing functional and other constraints on computer programs.

This chapter considers a related question: what aspects or features of computer programs are protected by copyright, even though the accused infringer, who has taken the feature without permission, did not copy the “literal” instructions or code of the computer program in taking the feature. Such copying is sometimes termed “nonliteral copying,” although that term has some seeming lack of clarity. (Does it involve exact or “literal” copying of a nonliteral feature of the copyrighted work? Or does it involve just an inexact, approximate copying of the literal aspects of the work?)

Perhaps the same ambiguity is created with the doctrine of equivalents in patent law, which is invoked in contrast with literal infringement of the claims of a patent. The latter term means that every element or limitation in the claim in suit has an identical counterpart in the accused device or method, rather than just an equivalent counterpart, as in what might be (but usually is not) termed nonliteral patent infringement under the doctrine of equivalents. Then, to make matters even more confusing (in patent law), a patent claim having as an element a means for performing a given function covers any device using the particular structure (means) for performing the function that the patent specification has described or the structural equivalent of that means. But in the latter case, the use of such an equivalent structure is deemed a literal infringement. (One has to live with these things. At least it helps to raise entry barriers against cut–throat competitive inroads from negligence litigators.)

In one sense, the cases in this chapter and the preceding chapter are alike in that in both sets of cases the copyrighted work and the accused work typically share something that is not at the expression polar extreme of the idea/expression continuum. In chapter 4, however, the main issue was usually whether a functional constraint could be satisfied only by repeating in the second work the identical expedient used in the earlier work. If two plays end with the death of Julius Caesar, both must have him utter Et tu, Brute? before falling to the floor of the Senate. Or if the scene is the South Bronx, vermin and derelict cars will likely adorn the setting. That is part of the scènes à faire for that subject matter. In other cases, the merger doctrine may address the issue and excuse a taking because no or few other ways exist to express the idea.

That is not so for the cases in this chapter. The issue in these cases is not whether merger or scènes à faire applies and thus excuses the use of the same literal element that the earlier computer program used. Here, the question is whether the feature of the earlier work that was taken in the accused work is just an unprotected (or unprotectable) idea or other thing outside copyright protection. Or, to look at the other side of the coin, is what is found to be common to both works protected from appropriation even though it is non-identically contained in the second work? (It is far short of a Xerox copy, as in the manner of 35 U.S.C. § 102 or even the doctrine of equivalents.)

There is some overlap, and cases in chapter 4 have already introduced you to the concept of taking something more abstract than the very words (or lines of code) of a copyrighted work. It is appropriate, therefore, to review the opinions in Borland and Gates, for example, to look for protection of, or refusal to protect, relatively less concrete aspects of the copyrighted work.

This preliminary comment now summarizes some old case law, rather than reproducing the opinions, in order to introduce you further to the notion of copying nonliteral aspects of computer programs.

The Whelan case

You have already been introduced to Whelan Associates, Inc. v. Jaslow Dental Laboratory, Inc., 797 F.2d 1222 (3d Cir. 1986), cert. denied, 479 U.S. 1031 (1987), in earlier cases. Although Whelan’s analysis is now considered “somewhat outdated,” see Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693, 706 (2d Cir. 1992), for a time courts adopted its reasoning. See id. (collecting cases showing that by then Whelan had “received a mixed reception”).

Whelan pioneered the acceptance of the notion that the “structure, sequence, and organization (SSO)” of a computer program is expression that the copyright in a computer program protects. In that case, the defendant had “migrated” a computer program written in one computer language (EDL for IBM Series 1 machines) to a computer program written in a second language (BASIC for IBM–compatible PCs). As a result, the two programs’ respective lines of code did not resemble one another, at least not superficially. Nevertheless, the district court and Third Circuit held that the evidence of structural similarities between the two programs established substantial similarity and thus copyright infringement.

The following excerpt from the Third Circuit's opinion (its verbatim quotation of expert witness testimony from the trial transcript, which the court said was sufficient to establish substantial similarity) exemplifies why the court held the program structures of certain subroutines in the parties' computer programs to be substantially similar:

A. In the Dentalab system, the same kind of thing again, same information is up there, description, unit price, extension, items and [the] program reads all those things in from the number of files actually, and displays them and then gives the operator a number of options to change the order as it appears on the screen to skip this one, to cancel it, or to accept it. The same choices are given in Dentalab systems, change, skip, cancel.

Assuming that the order is accepted, both systems then calculate the money, calculate the amount of money that will be billed, and at this point they use the price code to find which of the four prices are to be charged for this particular customer. Both systems do that. They pick that one of the four prices and calculate the total amount, right then the record of this invoice that has been formed to show the invoice's file, sets the flag in the order's file to show that this order has now been invoiced so that it doesn't get reinvoiced.

Q. What is a flag?

A. Well, a flag would be, in this case, a certain location is marked I for invoices, just an indicator that invoicing has been done on this record.

Q. Both used it?

A. Both used a flag. I don't remember whether Dentcom uses a letter I or some other symbol, but there is a flag there that it's a field number 12, in which it's indicated that this file has been invoiced or this order has been invoiced.

Q. Do you have any comment about the invoicing?

A. Well, I think it should be clear, it was clear to me from going through these programs that there is a very marked similarity between the two, that they, item by item, are doing pretty much the same thing with the same fields in the same files, and accomplishing roughly the same results. So there was quite a match, line by line, between these two, flow in these two.

Q. What do you conclude from that?

A. Well, back together with the file's structure, sort of set up with the — how the programs have to proceed. I would think that the person who designed or constructed the DentaLab system must have been thoroughly familiar with the Dentcom system. The person who constructed the Dentcom system must have been familiar with the series one system, because the same file structure and same program steps are followed, same overall flow takes place in both systems.

It is left as an exercise for the reader to determine whether this testimony does, as the Third Circuit asserted, demonstrate the marked similarity of expression between the two computer programs.

Literal copying and speed–up kits

The following excerpt from Midway Mfg. Co. v. Strohon, 564 F. Supp. 741 (N.D. Ill. 1983), is included to illustrate a clear case of literal copying of code, which is what this chapter is not about:

This inquiry is unusual here because of the technical nature of the works involved. Nonetheless, the record before us overwhelmingly supports the conclusion that the CUTE-SEE ROMs are substantially similar to the PAC-MAN ROMs.

The four ROMs alleged to have been copied contain all of the “instructions” used to direct the sequence of the play as well as some “data” or information that is transmitted for display on the screen. It is apparently possible, using a so-called Microcomputer Development Lab, to print out the information stored on the ROMs. And in evidence before us are printed out listings of over 16,000 units or “bytes” of information contained on the four PAC-MAN ROMs and of a like number of bytes on the CUTESEE ROMs. Each of the over 16,000 bytes in the exhibits consists of a numerical value expressed in base 16 — a 16-digit counting system. In each set of four ROMs there is a total of over 128,000 units of binary information, or object code. It appears that the full 16,000 locations are not necessary to program the PAC-MAN game. Thus, at the end of two of the PAC-MAN ROMs there is a substantial series of uncoded locations in each of which the “00” value appears on the printout. By contrast, the corresponding locations on the CUTE-SEE ROMs all contain encoded information.

Midway established at the hearing that 89% of the 16,000 bytes in the PAC-MAN ROMs is identically reproduced in the corresponding CUTE–SEE ROMs. Moreover, Midway showed that of the more than 16,000 bytes, 13,382 contain actual sequencing instructions, as distinct from data that appears directly on the screen. The ratio of identity between PAC-MAN and CUTE-SEE is significantly higher when the 13,382 instruction locations are considered in isolation: over 97% of those locations are identical; only 381 of the 13,382 contain different information in the CUTE-SEE ROMs. Midway's experts identified three long strings of identical locations between the CUTE-SEE and PAC-MAN ROMs. The longest of these, which covered 3984 locations, spanned virtually an entire ROM.

The degree of similarity, while not absolute, is substantial. As we have previously noted, the uncontradicted expert testimony at the hearing was that there is virtually an infinite number of ways to write a set of program instructions that will produce the PAC-MAN game sequencing. It is thus not at all necessary that the assembly code or object code phases of a computer program that would operate a maze chase game track the PAC-MAN program. The fact that the alterations in the PAC–MAN program — which concededly have a substantial effect on the play of the game — occur largely in the blank or uncoded locations at the end of two of the ROMs further supports the inference that the CUTE-SEE program was created by copying the PAC-MAN program and then “patching” additional, new program information into the work. The high degree of identity of the two programs and the virtual impossibility that two programmers working independently would write so nearly identical programs compels the conclusion that the CUTE-SEE ROMs designed for placement at locations 6E, 6F, 6H and 6J on the PAC-MAN circuit board infringe the computer program stored in the corresponding PAC-MAN ROMs.

Slayton argues that we may not limit our analysis to the four so-called instruction ROMs; that the full PAC-MAN program is stored on a total of six ROMs; and that therefore we must be satisfied that there exists a substantial similarity of all five CUTE-SEE ROMs to the six PAC-MAN ROMs before we may find the former infringing. We are not persuaded. Just as it would surely be an infringement to copy one chapter of a novel or one volume of a multi-volume work, so the fact that Slayton did not also copy the data stored on ROMs 5E and 5F does nothing to mitigate the piracy of the portions of the program stored in ROMs 6E, 6F, 6H and 6J.

The defendant, Slayton, was selling a speed-up kit for coin-operated video games. The court explained why defendant was marketing a speed-up kit as follows:

Despite the considerable commercial success that the PAC-MAN game has enjoyed, individual operators, like the defendant Slayton, attempting to recoup their investments in their machines, have apparently suffered from the phenomenon of “pattern play,” the ability of expert videogame players, by means of a practiced or routinized series of “moves,” to score enough points to play for an extended period of time on a single quarter. Alternatively, when some players have so mastered the game that it is no longer challenging, they no longer play.

At some point, when enough players have become sufficiently expert at a game like PAC-MAN to pattern-play the game or to lose interest in it, the individually owned machines cease to be profitable. As a result, there is a demand among operators of video games for “speed-up,” “enhancement,” or “update” kits, the purpose of which is to complicate and speed up the action of the games, in order to make them more challenging for practiced players.

The CUTE-SEE enhancement kit for the PAC-MAN game, which is the subject of this proceeding, is one example of such an effort to improve the revenue from individual machines. The CUTE-SEE kit includes a set of five ROMs with instructions for their installation in the PAC-MAN circuit board. The five CUTE-SEE ROMs are to be substituted in place of the PAC-MAN ROMs in various locations on the printed circuit board.

The kind of speed–up kit that the defendant, Slayton, made essentially replicated the code of several ROM chips of the plaintiff's printed circuit board, to which Slayton added some additional code to make the game operate faster or in a different manner. Slayton committed copyright infringement because he reproduced the plaintiff's code in his substitute ROM chips. Literally, within the meaning of 17 U.S.C. § 106(1), Slayton reproduced in a copy some of the plaintiff's copyrighted computer program.

Suppose that Slayton had refrained from copying the code from the plaintiff's ROMs to his own. Suppose, instead, that he made a piggy-back device that intercepted certain signals passing between the ROMs and microprocessor of the plaintiff's printed circuit board, so that Slayton's device could then patch in a different signal of its own from additional ROMs that Slayton supplied (these ROMs would have no code copied from the plaintiff). Presumably, Slayton would not then be guilty of reproducing Midway's code, in violation of § 106(1).

Would Slayton therefore be off the copyright hook?

One ultra-simple way to do a speed-up on a video game printed circuit board is to locate the clock chip on the board, which has pins for various speeds, e.g., 1 KHz, 2 KHz, 4 KHx, and 8 KHz. If you take a razor blade and cut the trace on the board to the manufacturer's selected clock pin, say 2 KHz, and then solder in a jumper wire to the pin for the next highest speed, say 4 KHz, you double the speed of the video game. Is this hardware change a copyright infringement? Does it make a difference that the change is by a hardware device instead of a software device?

Do you think operators of video game equipment should have a right to adapt or change it to prolong its useful financial life, without encountering copyright problems from the original seller? Buyers of patented machines have such a right. See Wilbur-Ellis Co. v. Kuther, 377 U.S. 422 (1964) (owner of patented sardine canning machine has right to adapt and modify it to pack sardines into different size of can). See also Leyland, supra.

Counsel (one of the casebook editors) for an amicus curiae, SHIELD, argued for this proposition in the Strohon case. SHIELD contended that the Wilbur-Ellis principle should apply to copyright, but the court rejected the argument: “Without support in the legislation that exclusively governs the rights of the parties in this copyright dispute — whatever its merit as an initial proposition — SHIELD's argument cannot prevail.”

The court also rejected an attempt to rely on 17 U.S.C. § 117's adaptation right, because Slayton sold substitute ROM chips (“unauthorized sale of reproductions”) to effect his speed-up modification. That violated § 106(1).

Brown Bag Software v. Symantec Corp.
United States Court of Appeals for the Ninth Circuit
960 F.2d 1465 (9th Cir. 1992)

[Brown Bag sued Symantec for copyright infringement, contending that it had infringed Brown Bag's copyright in the PC–Outline computer program in marketing its outliner program Grandview.

According to the district court opinion, Brown Bag asserted that the following aspects of Grandview's user interface are substantially similar to PC-Outline, and that these similarities allegedly render the “total look and feel of the two programs substantially similar”:

Tang, Circuit Judge

Summary judgment for a defendant accused of copyright infringement is appropriate when the plaintiff fails to show a genuine issue regarding whether the ideas and expressive elements of the works are substantially similar. Frybarger v. International Business Machs. Corp., 812 F.2d 525, 528 (9th Cir. 1987). This is so because the plaintiff bears the burden of proving that the allegedly infringing work is substantially similar to the work protected by plaintiff's copyright. Id. A “genuine issue” exists when the plaintiff provides indicia of “a sufficient disagreement” concerning the substantial similarity of two works “to require submission to a jury."

In response to the summary judgment motion Brown Bag submitted the declarations of its president and its computer expert, Ronald Ogg. The Ogg declaration set forth seventeen specific features in PC-Outline and Grandview alleged to be similar. “[U]sing [Ogg's] list as a tool to organize the features which plaintiff asserts are substantially similar in the two programs,” the district court found that none of the listed features could form the basis for a finding of copyright infringement.

In particular, the district court ruled that one group of features represented a claim of copyright in “concepts ... fundamental to a host of computer programs” such as “the need to access existing files, edit the work, and print the work.” As such, these features were held to be unprotectable under copyright.

A second group of features involved “nine functions listed in the menu bar” and the fact that “virtually all of the functions of the PC-Outline program can be performed by Grandview.” The district court declared that “these functions constitute the idea of the outlining program.” The court also held that “the similarity of using the main editing screen to enter and edit data....is essential to the very idea of a computer outlining program."

The third group of features common to PC–Outline and Grandview concerned “the use of pull-down windows.” Regarding these features, the district court first found that “[p]laintiffs may not claim copyright protection of an...expression that is, if not standard, then commonplace in the computer software industry.” Finally, the court concluded that the pull-down windows of the two programs look different.

Regarding the color schemes of the two programs, the lower court rejected the similar blue backgrounds as a basis for finding infringement.

Finally, regarding the two screens presenting the programs' respective opening menus, the court ruled that “the expression[s] of the two screens are not substantially similar, as a matter of law.” Finding that “[p]laintiff has failed to meet its evidentiary burden on this matter,” the district court granted Symantec's summary judgment motion.

Analytic dissection is relevant not only to the copying element of a copyright infringement claim, but also to the claim's ownership element. One aspect of the ownership element is the copyrightability of the subject matter and, more particularly, the scope of whatever copyright lies therein. To the extent a plaintiff's work is unprotected or unprotectable under copyright, the scope of the copyright must be limited. See, e.g., Data East (holding that, because “the similarities result from unprotectable expression,” “[t]he lower court erred by not limiting the scope of [plaintiff's] copyright protection").

Thus, where two works are found to be similar without regard to the scope of the copyright in the plaintiff's work, Data East teaches that the source of the similarity must be identified and a determination made as to whether this source is covered by plaintiff's copyright. It is this process in which the district court engaged with regard to the five groups of features found to be unprotected or unprotectable by Brown Bag's copyright in PC-Outline. Again, this use of analytic dissection was proper.

Brown Bag further argues that the district court became so engrossed in its analytic dissection that it neglected to evaluate the “overall look and feel” of the two programs for substantial similarity. Stated differently, Brown Bag contends that the district court failed to consider the “intrinsic” component of the Krofft test, which involves a subjective analysis of similarities in expression.

Even assuming this is true, we find no reversible error because the record fails to include any evidence indicating that Brown requested the district court to make this analysis. Although the district court “entertained an in-court demonstration of the two programs and...carefully reviewed submitted copies of relevant outlining programs,” no such evidence was ever included as part of Brown Bag's opposition to Symantec's summary judgment motion. Therefore, there is no reason we should expect the district court to have made the analysis Brown Bag now requests.

Conclusion

The record fails to support Brown Bag's objections to summary judgment on its copyright infringement claim. We therefore affirm that judgment.


Notes

1. Consider the list of items in which Brown Bag asserted copyright protection. Do you think that it was sensible for Brown Bag to claim that copying "OPENING MENU" as a caption for the opening menu was an act of copyright infringement? What about the blue background? What about the other items?

Is there a lesson in this? Consider this controversy in light of the discussion, earlier in this course, of constraints and human factors analysis.

2. Look and feel may have used up its 15 minutes of fame and glamour. It has not been heard from recently. Indeed, although Lotus could have made a look and feel argument in the Borland case, it avoided doing so. Lotus seemed, rather, to prefer arguing that it created a compilation of commands and a hierarchal order for invoking them, protectable as a literary work or as an aspect of a literary work.

3. Is a blue background field, widely used in user interfaces, functional? See Stern, Legal Protection of Screen Displays and Other User Interfaces for Computers, 14 Colum.-VLA J. Law & the Arts 283, 319 n.89 (1990). Consider alternatives, such as:


Is a blue background field, widely used in user interfaces, functional? See Stern, Legal Protection of Screen Displays and Other User Interfaces for Computers, 14 Colum.-VLA J. Law & the Arts 283, 319 n.89 (1990). Consider alternatives.



Is a blue background field, widely used in user interfaces, functional? See Stern, Legal Protection of Screen Displays and Other User Interfaces for Computers, 14 Colum.-VLA J. Law & the Arts 283, 319 n.89 (1990). Consider alternatives.



Is a blue background field, widely used in user interfaces, functional? See Stern, Legal Protection of Screen Displays and Other User Interfaces for Computers, 14 Colum.-VLA J. Law & the Arts 283, 319 n.89 (1990). Consider alternatives.



Is a blue background field, widely used in user interfaces, functional? See Stern, Legal Protection of Screen Displays and Other User Interfaces for Computers, 14 Colum.-VLA J. Law & the Arts 283, 319 n.89 (1990). Consider alternatives.



Is a blue background field, widely used in user interfaces, functional? See Stern, Legal Protection of Screen Displays and Other User Interfaces for Computers, 14 Colum.-VLA J. Law & the Arts 283, 319 n.89 (1990). Consider alternatives.


Are any of these less satisfactory?



Pearl Systems, Inc. v. Competition Electronics, Inc.
United States District Court
8 U.S.P.Q.2d 1520 (S.D. Fla. 1988)

Marcus, U.S.D.J.

This action was brought by Pearl Systems, Incorporated, seeking a declaratory judgment that it had not infringed a computer program copyright held by Competition Electronics, Incorporated. Competition Electronics' counterclaim for copyright infringement was tried before the Court without a jury.

Findings of Fact

1. Pearl Systems Incorporated manufactures and distributes the “PST-10 Shot Timer,” a shot timer device used for competitive pistol shooting.

2. Competition Electronics Incorporated manufactures and distributes the “Pro Timer III,” another shot timer device used for competitive pistol shooting. Competition Electronics is in the business of manufacturing shot timer devices for competitive pistol shooting. These devices measure “par-time” shots. The par-time function is used to measure the number of shots fired in a pre-set time period.

In 1983, Competition Electronics developed the “Pro Timer II,” a new generation shot timer device which incorporated a microprocessor. The CMOS microprocessor allowed the device to be much smaller and to perform more functions. One critical new function in the Pro Timer II was the “shot-review” function. The shot-review function permits the user to determine the total number of shots fired and the time between consecutive shots during a given round. Additionally, the shot-review function displays the shot number of the shot which is being reviewed.

Because the Pro Timer II used a CMOS microprocessor, software had to be developed for the unit to perform its functions. In 1986, Competition Electronics introduced into the market the Pro Timer III, which is similar to the Pro Timer II.

3. Competition Electronics registered the software for its Pro Timer III and for the Pro Timer II.

4. James Guido and Amir Majidimehr are the two shareholders of Pearl Systems. Mr. Guido approached Mr. Majidimehr in the fall of 1986 with the idea of making and selling a shot timer device. Majidimehr, who had no prior knowledge of competitive pistol shooting or the devices used to time shots, had a background in electronics engineering and had taken a number of courses in both hardware and software design at Florida Atlantic University.

Mr. Guido, who had subscribed to American Handgunner and Front Sight, showed Majidimehr an advertisement of the Pro Timer II so that he would understand its features. Majidimehr was the primary designer of the PST-10 and testified that he knew how the Pro Timer II operated based upon Mr. Guido's description thereof. According to Mr. Guido, he discussed with Majidimehr various ways of making the software do what they wanted it to do, including which buttons would activate which subroutines.

5. Competition Electronics claimed that two essential aspects of its software were copied: the shot-review subroutine and the par-time entry subroutine.

Both the shot-review function and use of par–time are critical features of a shot timer device and play an important role in the marketplace in marketing the devices because competitive pistol shooters use these functions frequently.

Both the Pearl Systems and Competition Electronics shot timers have buttons for the user to press and a display screen to convey information to the user. The internal operations of each shot timer are controlled by a microprocessor, which is programmed to perform certain functions. The program processes information it receives when buttons are depressed and displays the information on the display screen. The shot-review subroutines in both Competition Electronics' Pro Timer III and Pearl System's PST–10 use information from a single button to provide data sequentially on a single display. When the shot-review button is depressed, the current shot number is displayed. When the same button is released, the time from the beginning of the operation to the current shot is displayed. To display the time difference between shots in both units, a different button must be used to transmit information to the software.

To enter the desired par-time in both the Pro Timer III and the PST-10, a separate button must be pushed. The software then uses data received from three separate buttons—the ten digit, the one digit, and the one-tenth digit—to select and store the data for each digit. The difference in setting par-time that Pearl Systems relied upon—the user of the PST-10 must hit the button to increment the numbers, while the user of the Pro-Timer III may simply hold the button down—is a matter of the button type selected (hardware), not a reflection of a different software subroutine.

6. Competition Electronics' first expert witness, Dr. John C. Comfort, Professor of Computer Science at Florida International University in Miami, Florida, was requested by Competition Electronics to design software for a shot–timer device. Without being told how or shown any shot-timer device, Dr. Comfort was informed that the design had to meet certain specifications: it had to be able to record shots; it had to have shotreview capabilities; it had to have par-time capabilities; and it had to be able to be worn on a belt. Spending approximately twenty hours, and acknowledging that he would need another ten or twenty hours to perfect it, Dr. Comfort developed a software design with shot–review and par-time entry subroutines that varied from both the Pro Timer III and the PST-10.

Under Dr. Comfort's design, the user has two options to review the shots: use the review-time mode or the differential-review mode. In the review-time mode, the absolute time from the first shot to the final shot is displayed when the mode button is flipped up. When the mode button is flipped down, the unit will display the time between shots. Likewise, to set the par-time, the user presses a lever-type button down to reduce the displayed numeral, and up to increase it. According to Dr. Comfort, his design, which uses different software subroutines for the shot-review function and the par-time entry, would cost between $40 and $50 to produce.

7. Competition Electronics' second expert, Dr. Scott Woodard, owner and Director of Research and Development for Zylab Corporation, a firm that develops computer software, was requested by Competition Electronics to determine the extent of similarities and dissimilarities of the subroutines for the shot-review function and the par-time entry of the Shot Timer III and the PST-10, as well as those of the device designed by Dr. Comfort and the PACT unit. For his analysis, Dr. Woodard examined the source codes for the Competition Electronics product and the Pearl Systems product. He also developed flowcharts based upon the way the products operated and validated the flowcharts by examining the source codes. We believe these flowcharts are generally accurate depictions of the par-time entry and shot-review subroutines. Dr. Woodard concluded, supported by his flowcharts, that the systems-level design of the two relevant subroutines in the Pro Timer III and the PST–10 were virtually identical. Notably, what Dr. Woodard labelled as subroutine B (par-time set) and subroutine D (shot-review) are substantially the same in both devices. According to Dr. Woodard, the flowcharts would have been different between the products if the system-level design, the level of computer software design that requires the highest level of creativity, had been different in the products.

Dr. Woodard also compared the PACT flowchart and a flowchart of Dr. Comfort's design. Dr. Woodard stated that in part because the PACT unit uses a keyboard function instead of buttons to enter data, the shot-review and par-time entry subroutines of the PACT machine are quite different from those of the Pro Timer III and the PST-10. Furthermore, the process by which the PACT machine interprets data it receives from the keyboard was “substantially different.” With respect to Dr. Comfort's design, Dr. Woodard noted that while there were some similarities in the two subroutines, there were also substantial differences. For example, the buttons to enter the par-time are not dedicated, but the same button is used to enter the ten, the one, and the one-tenth digit. Moreover, the Comfort design uses a separate mode button to select the function the user wishes to employ, and in both the par-time mode and shot-review mode the same lever-type switch is used to increment the numbers up or down. The different systems level design of the Comfort system makes the function of the button dependent upon the mode; while in both the Pro Timer III and the PST-10, two separate buttons perform these functions. These differences resulted in substantially different subroutines, as reflected in the flowcharts.

We credit the conclusion of Dr. Woodard that the shot-review and the par-time set subroutines in the Competition Electronics product and the Pearl Systems product are substantially the same. These similarities were not constrained by product function. To make the comparisons, Dr. Woodard relied upon the source codes for the units as well as the external operations of the products, and analyzed how the system-level software would have to function.

Dr. Woodard also noted that while there was some variance between the Pro Timer III and PST-10 in external switches used and in the coding process and coding philosophy, these differences were not relevant to the similarities in the two subroutines. Thus, even though the languages in which the directions were written (source code) may have differed, they carried the same message.

8. Ronald Bailey testified that subsequent to commencing this action, in March and April 1988, he spent approximately twenty hours making software changes in a Pro Timer III unit. He was able to change the subroutines so that a different sequence of buttons would be used to enter the par-time and to engage the shot-review function. This resulted from a change in the systems level design of the software.

9. Pearl Systems' expert witness, Dr. Frederick G. Harold testified that the Pearl Systems subroutines and the Competition Electronics subroutines were different at the source-code level because of the difference in hardware and different programmers. However, he also noted that despite these differences it was still possible for the software to have been copied at a different level. Pearl Systems' other expert, Dr. Riva P. Bickel, acknowledged that while she had found differences in the subroutines at the code level and module level, there was no real difference in the shot-review mode at the system level design.

. . . 11. Based upon the testimony of Dr. Comfort, Dr. Woodard, and Mr. Bailey, an examination of the flowcharts of the two subroutines, and our own review of the operation of both shot–timer devices, we conclude that the par-set subroutine and the shot-review subroutine of the Pearl Systems product are substantially similar to those of the Pro Timer III. We are not convinced that the subroutines in the Pearl Systems device that are substantially similar to the subroutines in the Competition Electronics' device were the result of Pearl Systems’ independent creative effort.

Conclusions of Law

We have concluded supra that Pearl Systems had access to both the Pro Timer III and the Pro Timer II, which incorporated the same software as the Pro Timer III. We also have concluded that the Pearl Systems and Competition Electronics subroutines for entering par-time and performing the shot-review function are substantially similar. Any differences in the subroutines in the Pro Timer III and the PST-10 are inconsequential, as the Pearl Systems device captures the “total concept and feel” of the Competition Electronics subroutines. See Roth Greeting Cards v. United Card Co., 429 F.2d 1106, 1110 (9th Cir. 1970). Copyright protection of computer software is not limited to the text of the source code or the object code. Rather, the separate subroutines in a computer program are protected by the copyright laws. Whelan.

An additional constraint is put on a copyright action by the idea/expression dichotomy. It is axiomatic that a copyright does not protect ideas, only expressions of those ideas. Baker v. Selden. The real test, then, is to determine whether the defendant has copied the expression of the idea, rather than just the idea itself.

At issue here are the two subroutines. The par-time entry subroutine was designed to provide a method for the user to set a par-time. That is the idea. The shot-review subroutine was designed to allow the user to review the shots he or she has fired and to learn of the time that elapsed between each shot. That is also an idea. The subroutines themselves are expressions of those ideas. Moreover, the subroutines in both the Competition Electronics device and the Pearl Systems device were nearly identical, and this was reflected by the fact that the subroutines were triggered by the same sequence of buttons. As there was ample testimony that alternative system level designs could have been used to avoid this similarity, we conclude that the idea did not have only one necessary form of expression, but many. The nearly identical structures of the subroutines used by both Competition Electronics and Pearl Systems were not necessary to the tasks. Consequently, the idea and its expression did not “merge."

In other words, the purpose or function of a utilitarian work would be the work's idea, and everything that is not necessary to that purpose of function would be part of the expression of the idea.

We are unconvinced by Pearl Systems' argument that our holding today would discourage innovation. The principle that a programmer who develops a subroutine is entitled to copyright protection does not permit him or her to monopolize the idea underlying the program subroutine. In fact, by protecting the rights of programmers to their developments, programmers will be encouraged to develop new modes of “computer thinking,” knowing that their work product is safe from the vagaries of program copiers. While this will not afford a programmer protection of his or her idea, it will protect the expression of that idea.

We find that Competition Electronics had a valid copyright protecting the software of the Pro Timer III, that Pearl Systems copied that software, and therefore Pearl Systems infringed Competition Electronics' copyright in the Pro Timer III software.

Notes

1. The court made this statement in finding 4: “Mr. Guido, who had subscribed to American Handgunner and Front Sight, showed Majidimehr an advertisement of the Pro Timer II so that he would understand its features.” The court made this statement in its conclusions: “We have concluded supra that Pearl Systems had access to both the Pro Timer III and the Pro Timer II, which incorporated the same software as the Pro Timer III.”

Is the first statement the basis for the second? What kind of access would that be?

2. Based on the testimony of Dr. Woodard, the court appears to have found: that Dr. Woodward's flowcharts accurately described the par-time entry and shot-review subroutines; that “the systems-level design of the two relevant subroutines...were virtually identical"; and that “the flowcharts would have been different between the products if the system level design, the level of computer software design that requires the highest level of creativity, had been different in the products.” The court concluded:

[T]he subroutines in both the Competition Electronics device and the Pearl Systems device were nearly identical, and this was reflected by the fact that the subroutines were triggered by the same sequence of buttons. As there was ample testimony that alternative system level designs could have been used to avoid this similarity, we conclude that the idea did not have only one necessary form of expression, but many.

These statements suggest that the way that the defendant set up the buttons (switches) on the panel of the machine led to a particular structure in the software subroutines, a structure substantially similar to that of the plaintiff's software. Yet, the defendant could have set up its switch arrangement differently, and that would have led to a different structure in the software. Therefore, the defendant infringed the copyright in the computer program.

Whether it was the switch setup or the system–level design (or maybe those two amount to the same thing, here), the defendants could have avoided infringing similarity with the plaintiff's equipment if they had had the common decency to have arranged their switches differently. Is there any possible reason why they did not deserve to have the copyright infringement book thrown at them?

3. To what extent is the systems-level design of a machine such as the shot-timer device protected by copyright law? Its switch setup on the front panel?

4. Why shouldn't a competitor select a different systems-level design and/or switch arrangement to avoid being constrained to use particular code, when the code is copyrighted? If it fails or refuses to do so, is there any possible reason not to hold it a copyright infringer?

5. To further particularize the last question, assume that a particular hardware design is in the public domain. That is, there is no patent on the hardware and presumably no copyright. However, that hardware constrains the software used with the hardware. The hardware constrains the software to require particular lines of code to be used (or a particular structure of code). Unless the designer uses such software, she must use different hardware. Should not the designer avoid that hardware if she wishes to avoid incurring the guilt of software piracy? Does it matter whether many or few more or less satisfactory hardware alternatives exist?

6. Let me tell you about one of my many inventions — this one is called the electronic typewriter; it will be obvious to you what task it does. I have invented a computerized device with some 101 buttons on its front panel. Many of them simply correspond to the letters of the alphabet. Some of the buttons, however, have more interesting functions. They invoke subroutines — little programs within the larger program that my device executes.

One button I call the “enter” or < ↵ > button. When you press it, it calls up a subroutine that moves the cursor down one row and then it moves the cursor all the way over to the leftmost column.

Another button I call the “up arrow” or < ↑ > button. When you press it, it calls up a subroutine that ascertains the present x and y coordinates of the cursor — x,y; then calculates a new pair of coordinates, x and y-1 (in BASIC, the subroutine or procedure is x = x; y = y-1); and then it moves the cursor to the screen location whose coordinates have been so calculated.

I wonder whether you will be able to guess what subroutines are called up by three other buttons on my front panel — “down arrow” or < ↓ >, “left arrow” or < ← >, and “right arrow” or < → >.

My rival, Professor Nefarious, has copied my machine. That remorseless villain has no respect whatever for intellectual property rights. He copied the layout of my front panel exactly, QWERTY keyboard, enter button, up arrow button, and so on. Not content with that, he wrote subroutines for his program that followed my structure, sequence, and organization of subroutines, copied the look and feel of my machine, its plot, its style — you name it.

Thus, when you press the up arrow button on his front panel, it invokes a subroutine that does some screen–coordinate calculating and moves the cursor one row (space) up. Needless to say, the story is the same for the other buttons such as enter, right arrow, and so on. For every one of my buttons, he has an equivalent subroutine in his program.

I checked the code in his subroutines. I wrote in C++ and he, an inveterate show-off, wrote his in APL. Even though the language and code in which his subroutines may differ from mine, I can assure you that they carry the same message. For example, whether you press the right arrow button on his machine or on mine, the same thing happens. A subroutine is invoked which does some calculations and the cursor is moved on the screen so that its y coordinate remains the same but its x coordinate is incremented by one.

I plan to sue the wretched plagiarist for copyright infringement in the Southern District of Florida. How do you think I will make out?






Link to next section of this chapter

Return to Table of Contents