Encouraging closed source modules part 2: law and the module interface

Where do you draw the line between what's part of a GPL-covered work and what isn't? Does NVIDIA need to tap-dance around the GPL to get a proprieary module into the kernel, or is there an easier approach?

Current Job Listings

This is part two in a three-part series of articles debunking some common myths about the GPL’s reach and highlighting the sensible solution that the Linux community has constructed despite these myths. This part applies the body of court cases to the GPL, outlining the framework of the “gentleman’s agreement” struck by commercial and non-commercial Linux developers.

Obviously, the highest levels of abstraction in the court’s current test provide very little copyright protection for Linux kernel modules. Linux creator Linus Torvalds suggested “when you have the GPL, and you have documented for years and years that [the kernel module interface] is not a stable API, and that it is not a boundary for the license and that you do not get an automatic waiver when you compile against this boundary, then things are different [than with a stable API].” At the same time, Torvalds focused on how today’s kernel modules are “used for pretty much everything, including stuff that is very much ‘internal kernel’ stuff,” destroying “the kind of historic ‘implied barrier’” between the GPL-licensed kernel and supporting modules. Torvalds argues “there are cases where something would be so obviously Linux-specific that it simply wouldn't make sense without the Linux kernel. In those cases it would also obviously be a derived work, and as such . . . it falls under the GPL license.” The level of integration required, in essence, could render a kernel module’s source code useless for other software platforms.

In Sega Enterprises, Ltd. v. Accolade, Inc., the court denied copyright protection for “functional requirements for compatibility with the Genesis console . . . .” Under this approach, the right of the kernel module author to create a compatible module overrides any nominal copyright infringement created when that author creates static or dynamic links to kernel code. Sega’s Genesis console had no public API whatsoever, stable or otherwise, yet the court still denied protection to these functional elements. Regardless of the status of the API or system interface required for compatibility, any parts of a program that a developer must copy — such as kernel headers, definition files, variables, or mandatory Linux kernel function calls — in order to create a Linux-compatible kernel module would not receive copyright protection.

Any Linux copyright holder would have a far weaker argument for protection given the public availability of code under the GPL (unlike the closed source Sega Genesis code). No court from Midway to Sega has ever discussed stability, relative usefulness, platform specificity, or advancements in functionality as acceptable standards. However functionally extensive or poorly documented the API may be, the source code provides the uncopyrightable tools necessary for developers to write Linux-compatible modules.

In its preamble, the GPL also essentially argues that its license does not erect any artificial hurdles. The GPL carries no fees and expressly makes source code freely available for the public. At first glance, this free and open source software approach would support what the Sega court termed “growth in creative expression, based on the dissemination of other creative works and the unprotected ideas contained in those works, that the Copyright Act was intended to promote.” However, the Sega court rejected this “favorable license” argument. The court extended the right of developers to create compatible modules free from the control of the original copyright holder — even if the original copyright holder was willing to license that right under other terms. Sega had offered Accolade a license agreement that would have allowed Accolade to create Sega-compatible games with the condition that Sega manufacture those games. Despite this license offer, the court declined to find copyright infringement in Accolade’s creation of Sega-compatible games without a license. The court used the opportunity to destroy the artificial barrier between personal or non-commercial use and commercial use. The Sega court held that the commercial nature of Accolade’s use of Sega’s unpublished API did “not alter [their] judgment in this regard.” The court found that Accolade’s creation of Sega-compatible games had led to “an increase in the number of independently designed video game programs offered for use with the Genesis console,” precisely what the Act “was intended to promote.” Like Sega’s license, the GPL would impermissibly apply the act’s principle of growth to only some works (those carrying its license).

The Ninth Circuit refined the Sega analysis further in Sony Computer Entertainment v. Connectix Corp. to address this type of barrier to the creation of works. The Ninth Circuit carefully rejected Torvalds’ postulation that the intimately connected, but undocumented and unstable, kernel module API granted Linux copyright holders the sole right to authorize the creation of compatible modules.

The court rejected Sony’s argument that the type or amount of intermediate copying necessary affected the infringement analysis. Applying the Connectix analysis to Linux, the GPL’s proscription on use of GPL-licensed code presents developers with a dilemma similar to the one the court found in Connectix: develop in a vacuum or risk an infringement action. In this, the court saw “two engineering solutions that each require intermediate copying of protected and unprotected material, [but that require the developer to] often follow the least efficient solution.” The Ninth Circuit rejected this approach to infringement analysis as “erect[ing] an artificial hurdle” and creating “precisely the kind of wasted effort that the proscription against the copyright of ideas and facts . . . [is] designed to prevent.’” The Ninth Circuit in Sega and Connectix explicitly eliminated the need, for example, to follow the NVIDIA approach of using wrappers to “separate” closed source code from the Linux kernel, or to use clean room development procedures to insulate developers from the “taint” of the GPL-licensed kernel code and allow them to redevelop necessary code from scratch. All of these approaches erect artificial hurdles rejected by the Supreme Court generally for all copyright actions and in Sega and Connectix for software.

However, the courts’ interpretation of the Copyright Act is compatible in many ways with the spirit of the GPL as well. The Sega court notes it was precisely “growth in creative expression, based on the dissemination of other creative works and the unprotected ideas contained in those works, that the Copyright Act was intended to promote.” Developers write software by building on processes and procedures in the work of others. As in the expanded market for Sega Genesis-compatible games in Sega, the expanded availability of software and supported hardware for Linux creates a public benefit and a further incentive to create Linux-compatible works.

Open source proponents obviously support this proposition as well. Richard Stallman and other open source proponents based the open source movement on this same communal theory.

Not surprisingly then, the Ninth Circuit in Sega and Connectix found that module writers not only could link to existing programs for compatibility and interoperability, but also could profit from selling those modules. The Connectix court explicitly rejected Sony’s argument that commercial use raised a “presumption of unfairness” that defeated any assertions of fair use or non-infringement. The earlier Sega decision rejected Sega’s argument that Accolade could not claim fair use or non-infringement if it competed in Sega’s market. While unlike Sega and Connectix, authors of GPL programs do not stand to profit directly from the sale of the software or development licenses, the Sega court found no distinction between commercial use and non-commercial use.

Similar to the generic abstraction standard applied by the circuit courts under Altai and later cases, the courts have used flexible standards to draw lines between permissible use for interoperability and impermissible infringement. Neither Congress nor the courts chose to draw these lines along the boundaries of intimate linking or stable APIs, but the boundaries of market competition. While closed source kernel modules could compete with GPL code in the Linux kernel or in other open source modules, the Supreme Court requires that courts consider if “[the challenged use] should become widespread, [and whether] it would adversely affect the potential market for the copyrighted work.”

These tests leave courts with wide discretion to determine when a competing software product “usurps” the original product. If anything, in the open source software market, open source products tend to usurp closed source ones, and not the reverse. Stallman’s creation of Emacs and the GNU operating system projects are perfect examples. Similarly, the act and the test outlined in Sega, do not clearly define when information from an original program used to create a compatible one rises to the level of misappropriation. In situations where the act does not offer guidance, the courts invoke misappropriation to remedy allegations of plagiarism or other dirty tricks, in light of the competitive market for that software.

By allowing developers to copy code for compatibility or interoperability purposes, courts separate the value of creating new works from the value inherent in existing ones. Courts in other countries have recognized this type of adaptive work for many years. As discussed earlier, markets place a value on software based in part on its compatibility and interoperability and its adoption by previous consumers, and not just the aesthetic beauty of its source code expression or the relative effort of its developers. Sega, Connectix, and other cases uphold the idea that the commercial value of compatible software belongs to the subsequent developer and the community of software users and not the original copyright holder.

Part three will focus on how the Linux community has quietly created a solution that functions within both the GPL and the black letter of the U.S. case law. Review part one

Learn more about this topic

Encouraging closed source modules part 1: copyright and software12/06/06IBM faces fewer claims in SCO lawsuit07/03/06Open-source licensing: GPL is a better model07/04/05

This story, "Encouraging closed source modules part 2: law and the module interface" was originally published by LinuxWorld-(US).

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Now read: Getting grounded in IoT