You see it sprinkled liberally in mailing list and forum discussions: IANAL. “I am not a lawyer.” Of course, legal analysis often follows—sometimes well informed, but often wildly incorrect or outdated. Debates about GPL enforceability are no different. Copyright law, though, has evolved to shrink the gray areas significantly.
You see it sprinkled liberally in mailing lists and forum discussions: IANAL. “I am not a lawyer.” Of course, legal analysis often follows — sometimes well informed, but often wildly incorrect or outdated. Debates about GPL enforceability are no different. Copyright law, though, has evolved to shrink the gray areas significantly.
The open source community’s commercial and non-commercial members have debated the intellectual property issues surrounding the GPL and Linux for years, and even more now as the release of GPLv3 approaches. This process has led the Linux community to evolve its open source development model sensibly to accommodate realities of copyright law and the need to secure both significant commercial participation and widespread industry adoption. Erroneous ruminations about the legal effect of the GPL threaten to undermine this consensus. The GPL has its flaws and legal shortcomings, but the community has adopted a practical — if undervalued and oft-ignored — “gentleman’s agreement” that enables commercial participation in open source projects. This three-part series discusses the application of the Copyright Act to Linux, and kernel modules specifically.
How the Copyright Act handles software
For purposes of examining the GPL and Copyright Act, Linux has three different types of software: standalone applications running in kernel space or user space, the Linux kernel itself, and kernel modules that interconnect with the kernel through a system call interface. Each type of program presents a potentially different treatment under the GPL and Copyright Act. Of the three, the GPL and Copyright Act speak in black-and-white terms about the first two.
Standalone applications do not fall under the GPL or the Act’s definition of a “derivative work,” regardless of whether the applications run in user or kernel space. Provided the developer did not use GPL-licensed code to create it, no application merely running on an operating system can constitute a derivative work of that operating system.
The Linux kernel developers have licensed the Linux kernel code under the GPL. Developers that directly modify this source code fall on the opposite end of the spectrum from developers of standalone applications. Anyone that acquires the Linux kernel source code and directly modifies it to form a new kernel has created a derivative work of Linux. The GPL requires that such modifications also use the GPL, and the act would tend to support this requirement.
The third category creates significant debate. With the ambiguous definitions in the GPL, and rather paltry protections provided to software under the Copyright Act, kernel module code likely falls outside of the definition of “derivative works.” The GPLv2 defines a “work based on the Program” as “either the Program or any derivative work under copyright law: that is to say, a work containing the Program or another portion of it . . . ." Section 0 elaborates on its definition of a “work based on the Program” by including verbatim copies, modified versions, or translated versions of the Program. In both cases, the GPL fails to make the distinction between a work containing the Program and a work based on the Program, or collective and derivative works as Congress defined them under the act. Combining these terms into a single all-encompassing definition is illogical, especially given the GPL’s reference in the same sentence to copyright law and the importance of those legal terms of art under the act.
Section 101 of the act, without specifically mentioning software, defines a derivative work as “a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted.” The GPL purports to restrict non-GPL software from linking with GPL-licensed programs by asserting the copyright holder's exclusive right to prepare derivative works granted by the Act. However, courts have increasingly sought to narrow the definition of derivative works, especially for code written to be compatible with underlying original works. This trend toward stricter tests for derivative works contradicts the GPL’s broad assertions of protection for works based on GPL code.
Like the GPL, earlier cases interpreted Section 101 of the act broadly, granting significant protection to derivative works. An early pair of cases illustrating what the Ninth Circuit subsequently called a “hopelessly overbroad” definition of derivative works will be familiar to most readers who grew up during the 1980s. Worlds of Wonder, Inc. v. Veritel Learning Systems, Inc. and Worlds of Wonder v. Vector Intercontinental, Inc. did not involve software, but closely mirrored the debate about software linked to GPL code. Worlds of Wonder created the animated teddy bear Teddy Ruxpin. The defendants in each case created their own tapes for use with Teddy Ruxpin. These tapes emitted the same voice and signal and “interoperated” with Worlds of Wonder’s product. In essence, the defendants had written “software” (or what today would be software, rather than a cassette tape) that “ran” on Teddy Ruxpin. Even though the new tapes contained no Worlds of Wonder content, the courts found them to constitute infringing derivative works.
The definitive 1980s-era broad construction case is the Third Circuit’s Whelan Associates, Inc. v. Jaslow Dental Lab., Inc. To avoid an interpretation that would allow nearly verbatim copying, yet still offer a simple rule to apply, the Whelan court took earlier cases to their extreme in applying the act to software.
In Whelan, the plaintiff alleged infringement of its copyright in a custom program for dental laboratory record keeping. Whelan developed the custom program based on specifications devised by its customer, Jaslow. Jaslow later developed and started marketing its own competing version of the Whelan program, and Whelan sued. While Jaslow had not copied Whelan's source code directly, the structure, sequence and organization (SSO) of the two programs were extremely similar.
The broad interpretation in Whelan and earlier cases may have worked well for video games or cassette tapes, but not for software. Whelan’s primary weakness was its definition of “idea.” The definition was at once both too broad and too narrow. In an overall sense, Section 102(b) of the Act excludes facts, processes, procedures, ideas that have “merged” with expressions, and other considerations from copyright protection. The Whelan court’s exclusion of only the idea of the program and other elements necessary to that idea was too narrow. At the same time, defining the “idea” as managing a dental lab was too broad. A court’s choice of level of abstraction singularly affects the analysis of any possible derivative work infringement. In Whelan, the court’s definition of the idea as “efficiently managing a dental laboratory” could easily have fallen under a broader expression umbrella. A computer program, while undoubtedly helpful, is merely one possible “expression” of an “idea” of efficient management of a dental laboratory. By choosing a low level of abstraction, the Whelan court extended broad protection to the plaintiff’s program.
Some of the confusion about the GPL’s reach undoubtedly comes from these early cases, especially Whelan. In 2003, Linus Torvalds repeated the broad Whelan argument on the LKML in supporting his conclusion that Linux kernel modules would constitute a derivative work, even though the code incorporated no protected expression. Torvalds argued, “You just can't make a binary module for Linux, and claim that that module isn't derived from the kernel . . . [E]ven if you made your own prototypes and tried hard to avoid kernel headers, it would still be connected and dependent on the kernel.” Since the Second Circuit’s 1992 decision in Computer Associates v. Altai, no court has adopted Whelan’s broad protection, opting instead for a narrower approach.
The Altai decision was the first to narrow Whelan. Instead of Whelan’s simple idea/expression test, the Altai court adopted a three-stage “abstraction, filtration, comparison” test. Every U.S. appeals court that has reviewed this test has adopted it, or an even stricter version. The test’s first step, abstraction, involves dividing the program into its component parts. For example, the high-level function of Linux as an operating system breaks down into several kernel subsystems. Within each subsystem, different routines implement features (concurrency, multitasking, connectivity) or support hardware (network drivers, video drivers). Some subsystems break down further, such as in the network subsystem or architectures to support a particular range of network interfaces. Each subsystem breaks into component routines, functions, subroutines, and ultimately mathematical instructions.
Unlike Whelan, courts today do not choose any one level of abstraction as the “best” level. Instead, the Altai test proceeds to examine each level of abstraction to determine what, if any, protected expression exists at that level. Once a court abstracts each level, the court will filter the unprotectable elements out of the program. While courts still agree with Whelan that the act does not protect an underlying idea or any elements necessary to implement that idea, the filtration stage includes several additional considerations supplied by the court in Altai.
First, courts exclude any code structure dictated by efficiency, since “efficiency concerns . . . so narrow the practical range of choice as to make only one or two forms of expression workable options.” Second, and more importantly for analysis of the GPL, courts identify any standard practices and techniques common to programming applicable in a specific industry (Linux kernel modules, for example) or programming in general. The third stage analyzes the remaining portions of the original work and allegedly infringing work. This step compares only the “core of protectable expression.” Courts then apply a more standard infringement test to determine if the works are substantially similar, and, if so, whether any copying was substantial enough to constitute infringement.
At each level of abstraction, a plaintiff must prove both substantial similarity to and substantial copying of a protectable expression. Courts have rejected the argument that this detailed test would strip the software industry of incentives to write software. The Supreme Court rejected the idea that the labor and investment alone required to write software (the “sweat of the brow” defense) creates protectable copyright material.
On a side note, the frequent debate over static and dynamic linking may make for interesting mailing list fodder. Courts in the past 20 years have prevented software makers from using copyright law to control linked software, though, without drawing a distinction for when linking happens. A pair of video game cases from the Ninth Circuit illustrates the shift. For example, in Sega Enterprises, Ltd. v. Accolade, Inc., the Ninth Circuit held that Accolade could “reverse engineer” Sega’s video game system to create games that ran on the system, even though it involved copying Sega’s code. Similarly, in Sony Computer Entertainment, Inc. v. Connectix Corp., the court permitted the defendant to reverse engineer Sony’s game console in order to write an emulator that allowed users to play Sony’s games on a PC.
Part two of this series applies Altai and later cases to the GPL. Part three focuses on how the Linux community has quietly solved the problem, and how to solidify this consensus approach. Look for these subsequent parts later in the week.
This story, "Encouraging closed source modules part 1: copyright and software" was originally published by LinuxWorld-(US).