US case law provides several insights, which are coherent with the specification/implementation dichotomy that I proposed as a general category to systematize the various positions concerning the protectability of software interfaces.
In the following subsections, I will describe in some detail a few of the technologically simpler cases, because these applications will make clear that transposing the dichotomy in actual decisions is possible and coherent with the present findings of the courts.
3.2.1. E.F. Johnson Co. v. Uniden Corp.
The case E.F. Johnson Co. v. Uniden Corp.122 concerned an innovative mobile radio communication
system (“logic trunked radio” or LTR system). The defendant entered into the market for compatible radios and repeaters, realizing a software which had to be compatible with the one managing plaintiff ’s devices. Analysing the radios of the defendant,123 the plaintiff ’s engineers found (as the court confirmed) several
suspect analogies (including likely copied portions of code).124 One could be tempted to list this case among
the ones “indicating that copyright protection for APIs is warranted”. However – keeping in mind the previously discussed dichotomy – it will be easy to understand that it is actually a case which is perfectly coherent with the protection of API implementations against literal copying, while allowing almost complete freedom to reproduce elements dictated by API specifications.
As an example of a typical (even thought quite minimal) interoperability requirement, I quote a part of the court’s findings:
“Due to the fact that Uniden designed its radio to be compatible with EFJ’s LTR system, both parties acknowledge that some similarities in software design were inevitable. The Court finds that in order to make its radios compatible with LTR repeaters Uniden was required to copy the ‘Barker code’ found in the copyrighted EFJ program. A ‘Barker code’ is a pattern of ones and zeroes alternated in a prepatterned sequence. Both the sending and receiving units must identify the Barker code in order for communication to be established. The EFJ Barker code is numerically depicted as 1011000. In order to make its radios compatible, Uniden was required to and did copy this aspect of the EFJ program.”
Therefore, as it frequently happens, an interoperability specification dictated the reproduction of some apparently arbitrary expressions (the “Barker code”) in any compliant implementation. To deal with this problem, the Court summarized, in this way, the test created by the Third and Ninth Circuits125 to analyze
copyright infringement in the field of software:
120 This is coherent with the Commission’s attitude in Magill and IMS-Health cases, where the Commission was plainly sceptical
about the opportunity of granting Intellectual property rights in the fields at hand, but it refrained from discussing this matter (outside of its jurisdiction).
121 There is a significant difference between intellectual property rights (properly said) and trade secrets: despite the fact that
both legal institutions may be used to protect intangible assets, intellectual property rights may be used erga omnes and their subject matters are explicitly defined by the law, while trade secret may protect any kind of information and ideas, but essentially only against various forms of unfair appropriation.
122 623 F. Supp. 1485 (D. Minn. 1985). Being on of the first cases dealing with interoperability issues, the Court decision is
accompanied by a whole range of definitions and technical details (including a glossary and several detailed explanations and examples).
123 Incidentally, the simple act of analysing this product (through decompilation) would probably be formally prohibited by the
narrow interoperability-specific exception of Art. 6 of the European Software Directive.
124 Software code was embodied in physical devices, but this is not relevant (as the parts conceded and the Court correctly
recognized).
“whether other programs can be written which perform the same function as the copyrighted program. If other programs can be written or created which perform the same function as the copyrighted program, then that program is an expression of the idea and hence copyrightable. If a specific program, even if previously copyrighted, is the only and essential means of accomplishing a given task, their later use by another does not amount to infringement.”126
To the same effect, the Court also quoted the CONTU127 final report:
“In the computer context [...] when specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to an infringement.”128
That having said, however, the Court specified also that some specific parts of the expression, like the already mentioned “Barker word”, were “of necessity identical in both codes” (in order to achieve interoperability), but other parts of the software needed not to be identical (and hence could not be legitimately reproduced). In particular, the Court found some identical mistakes in the two software and this was considered a very reliable proof of literal copying, which was surely technically unnecessary (and actually technically detrimental).129 The courts clearly summarized its conclusion saying that
“the mere fact that defendant set out with the objective of creating an LTR-compatible radio does not, without more, excuse its copying of plaintiff’s code. The Court finds that copying plaintiff’s code was not the only and essential means of creating an LTR-compatible software program. Defendant was required to copy plaintiff’s Barker word, as discussed above. Virtually all other aspects of defendant’s program could have been independently created, however, without violence to defendant’s compatibility objective. Defendant has reproduced the expression, not merely the idea of plaintiff’s copyrighted program.”
A contrario, reproducing ideas, and not expression, would be legitimate and also reproducing expression would be allowed, in cases in which this is “the only and essential means” of creating a compatible product.
3.2.2. CMAX/Cleveland v. UCR
Another example may come from CMAX/Cleveland v. UCR.130 This case is explicitely listed by Parasidis
as among the “Cases Indicating Copyright Protection for APIs is Warranted”.131 However, I argue that this is
just a case where the defendant had literally copied the expression of the plaintiff ’s interface implementation. UCR operated in the rent-to-own business: it rented various consumer audio/visual and other products to final customers. Computermax (CMAX) was a computer software company, producing the RMAX System, designed to enables rent-to-own companies to input, store, process and retrieve information related to their business (inventory, rental agreement, accounting information and so on): the RMAX System was comprised of two related software packages, the RMAX Remote Store System (client part) and the RMAX Host System (server part). The Plaintiff, CMAX, provided its important customer UCR with the source code of its copyrighted programs, in order to improve the cooperation and communication regarding problems and request improvements. Admittedly using the work of programmers of limited experience, and continuously referring to the actual implementation of the RMAX client to solve programming problems, UCR developed its own version of the RMAX system (UCR developers admittedly copied the entire design of the software, including screen display, reports, menus, file format and so on).
In this case, it is evident that the interoperability implementation had actually been copied, along with several other elements of the RMAX client. As the Court found:
126 It should be said that the Johnson v. Uniden court seems to interpret the “only and essential means” requirement in the
sense of saying that a given mean is the only and essential one not in absolute terms, but at a given level of efficiency.
127 The National Commission on New Technological Uses of Copyrighted Works (CONTU) had been established by the US
Congress to survey issues concerning the application of copyright to new technologies.
128 623 F. Supp. 1485 at 1502, quoting National Commission on New Technological Uses of Copyrighted Works, Final Report
20 (1979) (CONTU Report).
129 623 F. Supp. 1485 at 1496: “The Uniden select call prohibit feature incorporates the same error found in version 3.0 of the
EFJ software. For this comity of errors the Court can conceive of only two plausible explanations: one, that EFJ and Uniden engineers independently committed the same inadvertences; or two, that Uniden engineers unknowingly wrote the error into their code when copying the EFJ code. The Court finds the latter explanation to be the likelier one.”
130 CMAX/Cleveland v. UCR, 804 F.Supp. 337. 131 PARASIDIS, Copyright Protection for APIs, p. 74—76.
“The data elements appear in the respective files of both systems in identical order, and in most instances, are the same length. The ordering method utilized in the RMAX Remote Store System, however, is not alphabetical or otherwise systematic, nor is it functionally significant in any respect. Thus, there is no reason why the UCR System should have the same data elements in the same order that the RMAX System does, absent copying.”132
In fact, these similarities were not dictated by any interoperability requirement, since “some file layouts in the UCR System have a number of fields that do not appear in RMAX Remote Store System files”,133 so that
it was clear (to the Court) that interoperability between the client and server systems did not require a strictly given number of, or a structure for these fields. In fact, the Court may even have been wrong – technically speaking – in concluding that some specific instances of copyright were not needed to achieve interoperability. The point is that evidence of parasitic copying was so clear and abundant that some legitimate copying could not have excused them. Overall, the Court did not give any sign of evaluating that copyright prevented the defendant from creating a piece of software interoperable with that of the plaintiff, it just and simply verified that, in this specific case, the interoperable product had been realized by unskilled programmers, using the source code of the original piece of software as a continuous reference, hence creating a clearly derivative work. Banalizing, the defendant’s developers did not analyze the plaintiff ’s software in order to reconstruct a specification document to be used as a technical constraint in developing their own piece of software. Instead, they just tried to realize a piece of software which was as similar as possible to the one they had access to, just rephrasing (or even copying) the solutions adopted by the plaintiff when they were not sure about something.
3.2.3. How to distinguish between copying ideas and expressions?
The aforementioned cases also offer some hints about practical rules used to distinguish between the copying of ideas and Expression. In order to do that, let me borrow something from the literature on the idea/expression dichotomy.134 From that literature, it is evident that the majority of cases decided on the basis
of the dichotomy “really do[es] not hinge ultimately upon a characterization of a work in isolation, but instead involve a close comparison of a copyrighted work with an allegedly infringing work”.135 In fact, it is
well known that there is no preliminary test of “copyrightability” of intellectual creations, so that the possibility of using copyright to protect a given work is always evaluated ex post by the legal system. And that typically happens in the context of a litigation, where what is being decided is ultimately the scope of the excluding power granted by intellectual property. That implies that it is not necessary to apply the idea/expression dichotomy as an abstract test (to determine if something could be protected or not); to the contrary, it is sufficient to apply the dichotomy just to determine if something that has been copied was a freely appropriable idea or protected expression. Hence, “whenever possible, [the dichotomy] should be applied at the infringement stage, in order to allow the comparison of the copyrighted work with an allegedly infringing work, rather than applied at the threshold stage to a copyrighted work in isolation”.136 In fact,
applying the dichotomy as an abstract test, we risk facing prohibitively difficult issues and we could be tempted to say that interface specifications are not protectable at all, while interface implementations are always protected. That is not the case and thinking in these terms is misleading. Hence, violation will depend upon the typical test of substantial similarity, but here the idea/expression dichotomy will come into play, preventing similarities dictated by technical principles, ideas and methods from leading to a finding of substantial similarity.137 In other words, the advantage of applying the dichotomy at a later stage, in the
132 804 F.Supp. 337, recital 83. The Court is actually reporting a specific example of this evidence of copying, that I want to
repeat here in order to give an intuition of the kind of evidence used to back the accusation of copyright violation (recital 82): “The
RMAX Remote Store System’s Rental Agreements file contains five ‘late payment’ fields in consecutive order. In the RMAX file, ‘LATE.1’, ‘LATE.2’ and ‘LATE.3’ appear as the eighteenth, nineteenth and twentieth fields, respectively, while the ‘LATE.4’ and ‘LATE.5’ fields appear in the forty-third and forty-fourth positions. Obviously, the two latter fields were added some time after the first three ‘LATE’ fields. The UCR System’s Rental Agreement file utilizes the exact same ordering method. […] The Court agrees with [the Plaintiff ’s expert testimony’s] conclusion that a programmer creating a new file from scratch logically would have placed these five data files together, rather than placing three together, inserting twenty- three unrelated fields, and then adding another two. The only reasonable explanation for this similarity is that the UCR System’s programmers copied the RMAX Rental Agreements file.”
133 804 F.Supp. 337, recital 83.
134 In particular, from SAMUELS, The Idea-Expression Dichotomy, . 135 Id., p. 419.
136 Id., p. 462.
context of a substantial similarity test, is that we do not need to decide in abstract if any given word is part of an unprotected idea or of the protected expression. Instead, we are allowed to focus on the existing similarities and we may just evaluate if they are dictated by the underlying ideas or not.
For instance, EFJ v. Uniden makes evident that a typical way of detecting the copying of the expression is simply to find similar bugs in two pieces of software.138 Obviously technically superfluous instructions,
declarations of variables and the like may give similar hints139 (in some cases, some odd programming choices
may even have been expressively introduced in the code in order to provide a proof of copying, without any other meaningful use).140 In general, finding statistically unlikely similarities, in cases in which the same
technical problem had several different solutions (without one being more efficient or appropriate than the others)141, provides a relevant evidence of copying of protected expression. An especially telling example may
be taken, again, from EFJ v. Uniden. In that case, “miscellaneous evidence of copying abound[ed]”, but one instance is especially interesting. Several (counterintuitive) programming choices of the plaintiff had been taken for efficiency reasons related to the specific characteristic of the Intel microprocessor installed in its radios; without any apparent reasons, the defendant (using a Hitachi microprocessor, with different technical characteristics) took exactly the same choices (which were suboptimal on its own, different microprocessor).
This kind of evidence, where similarities in the expression are not only unnecessary, but even counterproductive for the late comer, are far more common than one may expect in cases where original expression is copied. In fact, the main point of copying someone else expression is precisely to save on development costs; hence copiers will typically be quite sloppy in their copying activity. In principle, it would surely be possible to fully understand someone else code and reproduce its structure – maybe in such a way that could violate the original copyright – without leaving much evidence of the copying. However, the cost of this kind of copying – unless it is done by illegally appropriating secret information and/or stealing workers142 – is likely to be so high that it does not pose any major competitive threat to the first comer. To be
sure, some kind of detection errors are unavoidable. However, the risk of “false negatives” in case of very “high quality” copying (i.e. copying that is possibly reproducing some protectable expression, but that is performed very near to the idea/expression “border”) is a risk that entails much less costs than the opposite “false positive” case. In that case, the legal system would risk granting patent-like protection through a tool, copyright, that does not incorporate the appropriate pro-competitive corrective elements.143 In fact, as I will
try to clarify (in § 8 and in the second paper) the economic meaning of forbidding the copying of expression is to make sure that late comers did sustain development costs, which are similar to the ones borne by early comers. What we want to avoid are cost savings based on copying. If there is evidence that some copying has been performed to save on costs (or, equally, just because of laziness), then we do not want to allow this copying. However, if – in the context of an independently written software – some apparent “copying” is likely to have been dictated by technical reasons, in order to achieve compatibility, then there is no reason (as I will try to demonstrate in § 8) not to allow it. Actually, I will try to demonstrate that forbidding similarities in expression dictated by technical reasons would very likely reduce social welfare.
In fact, the favour that the so-called “clean room” process of software reverse engineering finds in front of US courts confirms that American judges share the previous reasoning. In the clean room process, two
138 Errors are relatively frequent in software code (because several of them do not impede or hinder the correct working of the
program, if not in very specific situations), so that case law is rich of examples of copying activities detected (also) using copied mistakes.
139 Again in EFJ v. Uniden, the Court found that “[p]recisely the same three superfluous instructions are found in the Uniden
[defendant] program, in precisely the same location [with respect to what happened in the plaintiff ’s software]”.
140 Notice that, in principle, some of these arbitrarily introduced pieces of code could have been inserted as a kind of “time
bomb” against unofficial compatible products: in other words, they may become necessary for future interoperability (see JOHNSON-LAIRD, Software Reverse Engineering, ; RICHARD H.STERN, Reverse Engineering for Future Compatibility, 1 European Intellectual Property Review, 175--180 (1994)). Hence, it is actually possible to imagine cases in which some bugs are knowingly copied and introduced in a new program for compatibility reasons. However, such a decision could be testified – for instance – by specific notes in the source code of the allegedly copied reimplementation: hopefully, no programmer would willingly copy a bug without adding a comment explaining that the following lines are not completely correct and why they are not.
141 For instance, in EFJ v. Uniden, a matrix that could be structured in 32 different ways had been structured exactly in the same
way in two types of software (this fact was not considered in itself, but in the context of several other suspect similarities).
142 All cases in which there are legal tool to remedy to possible market failures which are more appropriate than copyright and
that entail less risks of market distortive effects.
143 These elements include the preliminary scrutiny of novelty and existence of an “inventive step”, disclosure obligations and
so on. See, in particular, GUSTAVO GHIDINI, Profili evolutivi del diritto industriale. Proprietà intellettuale e concorrenza (Giuffrè, Milano. 2001) or GUSTAVO GHIDINI, Intellectual Property and Competition Law. The Innovation Nexus (Edward Elgar. 2006).
separate teams of engineers perform the reverse engineering work frequently needed to access interoperability information and the reimplementation work needed to create a new specification-compliant