English (United Kingdom)

https://curated-unify.zendy.io/wp-json/zendy-region/v1/featured_content/oa?rat=en

https://curated-unify.zendy.io/wp-json/zendy-region/v1/highlighted_journal/

Zendy Plus

Presents the access of premium content as premium feature

Premium Content

Presents the keyphrase highlighting as premium feature

Keyphrase Highlighting

Presents the summarisation as premium feature

Summarisation

Insights

Presents the pdf analysis as premium feature

PDF Analysis

Presents the zaia usage as premium feature

ZAIA

Zendy Tools

Zendy Open

ion that is more general still. ' Two commentators have suggested an example of the application of levels of abstraction analysis to the structure of computer programs rather than the programs themselves: [A]n "abstraction" analysis might define structure at one level of abstraction by a detailed flowchart that reflects the operation of each subroutine of the program as well as the rela· tionships among subroutines. At a somewhat higher level of abstraction, structure might be depicted by a flowchart of the logical links among subroutines. At an even higher level, still possibly considered to depict structure, the program could be described by a simple list of the subroutines in the order they appear (e.g., "billing routine followed by accounts payable routine"). Ladd & Joseph, supra note 70, at 10. The example begins much as the approach suggested in the text by identifying the implementation of the program at its lowest level as the lowest level of abstraction. The authors next move to a representation of the whole structure of the programion. The authors next move to a representation of the whole structure of the program and finally to organization wholly independent of structure or function. These levels correspond roughly to what this Note has called sequence, structure, and organization, respectively. See supra note 27 and accompanying text. This approach is easy to apply and a step in the right direction, but it treats the structure of the program as something independent of the program and builds its abstractions upon the structure of the program rather than the program itself. This considers insufficiently the possibility that lower levels of structure might contain more protected expression than higher levels. It is unclear what questions one must ask to determine where in Ladd and Joseph's hierarchy of levels the division between idea and expression falls. It is also unclear what it means to say, for example, that structure is protected as such but organization is not and whether that could possibly be a correct result. 153. See supra notes 19-25 and accompanying text. Several commentators have briefly de· scribed a similar approach with greater emphasis upon the relationship between the levels of abstraction and the programmer's approach to writing the program. Reback & Siegel, Toward a Comprehensive Test/or Software Copyright Infringement, COMPUTER LAW., Dec. 1984, at 1, 4· 10; see also Reback & Hayes, The Plains Truth: Program Structure, Input Formats and Other Factual Works, CoMPUTER LAW., Mar. 1987, at 1, 4-7. One difference between the approach described by these commentators and that described here is that they seemingly equate levels of abstraction with levels of a program's structure. See Reback & Hayes, supra, at 6; Reback & Siegel, supra, at 4. This Note would instead view a program from a very large number of levelsion with levels of a program's structure. See Reback & Hayes, supra, at 6; Reback & Siegel, supra, at 4. This Note would instead view a program from a very large number of levels of abstraction. At each level, the program has a structure. This Note forms these abstractions by conceptually substituting the functions of modules for their implementations at different levels of a program's structure and in different parts of a program. While Reback, Hayes, and Siegel would identify a single level of a program's structure as a "level of abstraction,'' this Note suggests that one abstract view of a program might consist of a particular level of that program's structure, the literal instructions and the functions of all of the modules at that level of the program's structure, and all of the higher levels of the program's structure. February 1990] Note Copyright Protection 899 is simply copying parts of the Jower levels, and if the copying is extensive, all leve1s of a program's structure. · · Developing a set of abstract views of a program is relatively easy; the task of determinillg th,e point in this set of abstractions at which the additional detail in the next-lowest. level constitutes expression rather tha11 idea is much more difficult. Professor Chaffee's pattern test154 is an attempt at a general solution to this problem in the context of novels and plays. By its own terms, it is not well suited to computer programs. Whether there is any expression in the structure of a program viewed at a particular level of abstraction can only be. apswered after a more fundamental inquiry into the details of the program. Beginning with the highest level of abstraction, the function of a program is in every case an idea.155 At any lower level of ~bstraction, one ·must consider the details present in ihe structure of the program at that level of abstraction but missing from the structure· of the program at the next highest level of abstraction to deterniine whether they too are idea. These details consist of a set of module functions and client relationships. 156 At each level, these details should· be considered part of the idea of the program if they are not sufficiently original to be protected or the use of these structural details is necessary157 efficiently to implement the program as it exists at the higher le:vel of abstraction.158 Eventually, one will reach the level of individual instructions. Even sequences of literal instructions cannot constitute protected expression when they are not original or they are necessary to the efficient implementation of the program's function. 159 154. See supra text accommpanying note 50. 155. See supra note 126. 156. See supra note 27 and accompanying text. 157. Although a program could always theoretically be implemented with a trivial structure, this could prove quite difficult and would be contrary to general programming practices. See supra note 21 and accompanying text. No aspect of any program's structure should be found protected on the grounds that the underlying function could conceivably be implemented in a way contrary to generally accepted programming practices. 158. See 3M. NIMMER, supra note 40, § 13.03(A][l]; Reback & Siegel, supra note 153, at 45. This inquiry is in some sense the same inquiry made in Whelan Assocs. v. Jaslow Dental Laboratory, Inc., 797 F.2d 1222, 1238 (3d Cir. 1986) ("[T]he structure of the program was not essential to that task .•. . "),cert denied, 479 U.S. 1031 (1987), and Apple Computer, Inc. v. Franklin Computer Corp., 714 F.2d 1240, 1253 (3d Cir. 1983), cert dismissed, 464 U.S. 1033 (1984), except here it is conducted level by level and incorporates an efficiency qualification. The approach to distinguishing idea from expression suggested here differs from the Whelan rule in its definition of function. See supra notes 20, 73, and accompanying text. Moreover, the Whelan rule lacks an explicit means of distinguishing process from expression such as that proposed in section IIl.B. This Note's approach is also in some respects similar to that described in Davidson, supra note 38, at 1082-85. Davidson does not explicitly build levels of abstraction but rather conceives of a program as a collection of nested "black boxes," which correspond to modules, and then determines a level of protection for each black box. 159. CONTU REPORT, supra note 11, at 20. No single instruction can ever be very original; neither can any individual word of a novel or play. The question is whether there is sufficient originality in some meaningful sequence of instructions. See Declaration of Melville B. Nimmer, supra note 114, UU 14-15. For example, a well-known and often used sequence of instructions for 900 Michigan Law Review [Vol. 88:866 Although this inquiry is by design essentially the same as that applicable to any literary work, it is necessary to make one concession to the utilitarian nature of computer programs. Computational efficiency, which might be defined differently depending upon one's objectives, plays a role in this inquiry because the use of some structures over others may be indicated by concern for the efficient use of computer or human resources. 160 If ideas and, in particular, functions are not to be protected by copyright, surely it is no response to a claim that the use of a particular set of modules is necessary to implement a function to argue that the accused program might have been written in a way that requires larger amounts of memory space or processor or programmer time, or makes the program more difficult to learn or use. While it is absolutely essential that necessary or conventional implementations of a function not be protected, there will probably be relatively few cases where a particular implementation of a function is necessary. With the possible broad exception of operating system programs, where the design of the computer may actually dictate some significant aspects of the implementation of the program,161 there are usually many ways to implement any function. 162 For example, even if all teleprompter programs would have the same four modules at the highest level, 163 the likelihood that any of these modules could be implemented efficiently with only one structure is probably very small. Claims of necessity should thus be viewed with some skepticism. This method of distinguishing idea from expression in the context of computer program structure, regrettably, may not be very easy to apply. Distinguishing idea from expression is never easy, and the computer program context makes this inquiry especially difficult for sorting the items in a list is no more deserving of copyright protection than a dozen lines of Hamlet contained in an otherwise original play. 160. One commentator recently suggested that copyright should not protect aspects of a structure motivated by such functional concerns as efficiency of execution. Menell, supra note 18, at 1085. This concern for not protecting aspects of structures resulting from design decisions made in the interest of computational efficiency stands behin

Idea, Process, or Protected Expression?: Determining the Scope of Copyright Protection of the Structure of Computer Programs