- 15 Non-Certified IT Skills Growing in Demand
- How 19 Tech Titans Target Healthcare
- Twitter Suffering From Growing Pains (and Facebook Comparisons)
- Agile Comes to Data Integration
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.
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.