Encouraging closed source modules part 3: elimating the "API update tax"

Unstable driver APIs, thought to be one of Linux's strengths, impose costs on both proprietary and GPL developers.

Richard Stallman, the Free Software Foundation, and other GPL supporters have a logical and reasonable attraction to copyright law. Copyright is simple: even a moment of poetic inspiration jotted down on the back of cocktail napkin automatically gains copyright protection. Developers do not have to file paperwork or go through an expensive, time-consuming process to protect their work. The innovative, if legally questionable, construct of the GPL enables the Linux community to return, at least partially, to the collaborative environment Richard Stallman enjoyed in his early MIT days.

Richard Stallman, the Free Software Foundation, and other GPL supporters have a logical and reasonable attraction to copyright law. Copyright is simple: even a moment of poetic inspiration jotted down on the back of a cocktail napkin automatically gains copyright protection. Developers do not have to file paperwork or go through an expensive, time-consuming process to protect their work. The innovative, if legally questionable, construct of the GPL enables the Linux community to return, at least partially, to the collaborative environment Stallman enjoyed in his early MIT days.

At the same time, though, copyright offers the weakest of protections: it covers only narrowly defined expressions. Both independent authorship (the “clean room”) and compatibility provide future developers with defenses to infringement of the original work. Unless a copyright holder can prove plagiarism of copyrightable elements of source code, the Copyright Act will offer only narrow protection. In practice, the plagiarism protections in copyright law have their own special problems when applied to software, too. While there is no chance that an author would accidentally create a near-verbatim version of this story, the structure of programming languages dictates a different result in the software realm. A group of 10 developers working independently to create a Linux kernel module that prints the text message “Hello, world” when loaded would undoubtedly create 10 nearly identical modules.

In the proprietary software world, copyright strikes a perfect balance between protection and innovation. Under Altai and the cases that followed, copyright holders get protection from those who effortlessly plagiarize their code. At the same time, developers retain a strong incentive to author new works and compete, because the cases provide broad protection for both independent invention and compatibility.

The GPL strikes that same perfect balance. The Debian project’s use of “free” (fully GPL-licensed) and “contrib” and “non-free” (non-GPL licensed) archives provides an excellent example of the ability of closed and GPL code to coexist to the benefit of Linux users and developers worldwide.

The current exception for kernel modules is legally dangerous, though, too. Linux and the GPL face the same problem today that Stallman faced in the late 1970s, though with far more players — individual developer and commercial — than before. Just as before, a single developer could easily upset the delicate balance between the GPL’s ideals on one hand and legal realities on the other. The Emacs balancing act unraveled over this same debate.

In an interview with Linux Weekly News, Professor Eben Moglen illustrated the problem clearly: “If the kernel is pure GPL, then I think we would all agree that non-GPL, non-free loadable kernel modules represent GPL violations. Nonetheless, we all know that there are a large number of such modules and their existence is tolerated or even to some degree encouraged by the kernel maintainers, and I take that to mean that as an indication that there is some exception for those modules.”

Moglen continued: “The kernel also maintains a technical mechanism, namely the GPL-only symbols and tainting structure, which seems to suggest an API for the connection of non-GPL'd code to the kernel, which also seems to me a strong indication of the presence of an exception. The difficulty as a lawyer, even a lawyer that is reasonably knowledgeable about these matters, is that I don’t understand what the terms of that exception are.”

Here, Moglen hints at the legal reasoning described in more detail in part two of this series. Closed-source modules that do not copy code beyond necessary compatibility elements do not violate copyright law under current court interpretations. At best, proving infringement would require a lengthy, detailed expert analysis of source code. Courts would prove extremely reticent to overturn 15 years of progress on software copyrights, and two major Supreme Court decisions, just to fit the ideological goals of the GPL’s drafters.

The nebulous “exception” for closed source code encourages participation from a broader base of developers and companies. Its existence does not represent a fundamental problem; its uncertain nature does. The FSF and the Linux community should embrace closed source code, instead of ignoring or sidestepping the problem as Stallman did when the Emacs project ran into similar problems with its ill-defined license. Rather than continuing an API that is “not a stable API” (in Linus Torvalds’ words), Linux should steady its core structure in order to better control all module code. The lack of such a structure for networking and video drivers, for example, has only contributed to the creation of myriad, nonstandard drivers and hindered Linux’s growth in some market segments.

Open source code can contain (and constrain) closed source code inside the strict parameters of a stable, documented, well-defined API. Regardless of the underlying licensing structure, modules written for compliance must interact with the API’s structure in a predictable, predefined manner. The GPL serves a useful purpose in guiding the direction of Linux development. If Linux developers and GPL purists generally find closed source code odious, then devising open source APIs and architectures to control closed source code’s interaction with the Linux kernel accomplishes as much of the GPL’s stated goals as legally possible.

Torvalds himself hinted at the efficacy of this approach when suggesting “historically . . . you could load a module using nothing but [] standard interfaces” and that this approach created an “implied barrier” between modules and the kernel. While a functionality-crippling barrier is unnecessary, a stricter focus on standardized interfaces and architectures would balance the community’s concerns about closed source code with the realities of copyright law. By recognizing the limitations of the Copyright Act and embracing the practice of positive symbiotic commercial/open source Linux software development, this approach would preserve the long-term success of Linux.

Some in the open source community, though, have suggested that providing binary modules is a “nightmare” and strongly insinuate that closed source developers cannot manage to update or recompile drivers as quickly as open source developers. Some writers have gone even further. On the LKML in late 2005, Arjan van de Ven warned of a “doomsday scenario” if the community formalized the gentleman’s agreement on closed source modules. He warned that the community would splinter, open source modules would disappear as the balance shifted toward closed source development, and Linux would suddenly become wildly unstable. Others point to driver instabilities in Windows as evidence that Linux would suffer a similar fate at the hands of sloppy or incompetent closed source programmers. The successes and failures of both open and closed source modules have belied those arguments, revealing them as ideological and not factual.

Unlike the days when software was a vehicle to sell hardware, and despite utopian ideals of an open source software world entirely free of patents and copyrights, today’s open source community must coexist with the closed source developers. The balance between closed source and open source in Linux has always tilted toward closed source for legal and practical reasons. Not only does the law protect developers that adapt their works for Linux, but, practically, the availability of an open source kernel helps further facilitate closed source development. Despite doomsday predictions, this balance has yet to result in any of the catastrophes van de Ven predicted.

Closed source kernel modules that incorporate GPL code from the Linux kernel for compatibility do nothing to prevent others from obtaining the original, unmodified Linux kernel code from its original authors or maintainers. All Linux code — open and closed source alike — can contain feature, security and stability problems. For example, many open and closed source Ethernet card drivers for years failed to properly support virtual LAN-tagged or bridged frames without source code modification. The “eepro” driver for Intel EtherExpress Pro cards still exhibits serious stability problems under load. Nearly every LAN and WAN chipset has its own unique structures, memory handling, buffering and functions. The haphazard development brought on both by a lack of structure and the purposeful erection of the unstable API barrier means that many drivers outside the kernel tree have fallen into disrepair, and those in the tree offer unpredictable performance and stability. The community has shunned the use of architectures available under open source licenses from commercial Linux vendors to its own detriment. The problems are not limited to network and video drivers, either. The 2.6.19-rc5 release notes extended more than 4,000 lines, and fixed bugs over a year old.

Of course, closed source drivers do not avoid the pitfalls of a rapidly advancing and improving Linux operating system. In October, Rapid7 released a security advisory and working root exploit for NVIDIA’s binary graphics drivers, apparently against a longstanding vulnerability left unpatched by NVIDIA developers. Further standardization, such as adopting a unified network driver architecture, will not make bugs disappear in open or closed source code. However, API standardization can help address van de Ven’s “doomsday” worries by containing closed source code’s interaction with the kernel, and provide developers with the kind of stability they have come to expect from the kernel-to-user space interface and other standardized architectures within the Linux environment.

Greg Kroah-Hartman and others suggest that the adoption of an API would mean requiring Linux to maintain legacy support for older APIs. The two issues are wholly separate. As many developers have noted, Linux development proceeds rapidly and continuously, and can obsolete open and closed source code without discrimination. The Linux community can adopt APIs that are both defined and dynamic. In the networking realm, Linux companies such as ImageStream, Sangoma, and Vyatta, and projects like BSD’s netgraph have proven the viability and efficacy of this approach over many years and kernel revisions. The lack of APIs, along with the lack of documentation and stability in current APIs, deters both closed and open source development equally by creating an unnecessary “API update tax.”

In a practical sense, developers that choose closed source code, who decide to maintain drivers outside of the kernel tree, or who lock users into a particular hardware platform will have to balance the benefits of that choice with its drawbacks. By actively encouraging unstable APIs or forgoing them entirely, the open source community eliminates most or all of its collaborative advantage, making closed source developers more — not less — competitive. Artificial barriers harm all Linux code, by compromising performance and stability, and unnecessarily increasing development time.

“Linux Armageddon” fears and scare tactics aside, users will always choose between using proprietary source code, using open source code (forgoing proprietary extensions, as with non-accelerated NVIDIA drivers), and developing open source versions of the proprietary code. Open source versions of closed source code fall under the same shelter from infringing expressions that closed source developers use. Stallman chose this last option when faced with proprietary code from Symbolics in 1982 and 1983.

The GPL acts as the most important beacon for Linux and the rest of the open source world. Its most significant contribution may differ greatly from the one envisioned by its creators: collaborative, decentralized development rather than free software. Contrary to some analysis with IANAL disclaimers, the “gentlemen’s agreement” model employed by Linux is a common sense adaptation of the GPL. This arrangement successfully accommodates both closed source and open source software. The gentlemen’s agreement is also consistent with the U.S. Copyright Act and its surrounding case law. Rather than push to change this functional approach, the community should work to embrace and solidify it. Courts and market inertia will force both the open source and closed source models to coexist. Neither purely open source nor purely closed source models for Linux will succeed without the other.

Discuss this article on the LinuxWorld.com community site

Learn more about this topic

Encouraging closed source modules part 1: copyright and software12/06/06Encouraging closed source modules part 2: law and the module interface12/08/06

This story, "Encouraging closed source modules part 3: elimating the "API update tax"" was originally published by LinuxWorld-(US) .

Editors' Picks
Join the discussion
Be the first to comment on this article. Our Commenting Policies