licenses are valid and enforceable as licenses under copyright law, however, then there would appear to be little justification for declining to apply the provision of the Copyright Act governing termination of such licenses.
Termination of an open-content license would have effects on the underlying project that, while difficult to predict, are unlikely to be salutary. Consider an example from the FOSS world: software development has been recognized as an irreducibly complex process insofar as the production of software works exceeding a certain (and comparatively rudimentary) level of complexity is a challenge beyond any individual developer.[1] To make all but the simplest programs, therefore, multiple programmers must collaborate. When they do so within the hierarchical structure of a single firm, no copyright issues arise from one programmer’s reuse of another’s work because the employer holds the copyright to each employee’s contributions under the work made for hire rule.[2] In contrast, contributors to FOSS projects must coordinate their activities outside any single hierarchical structure.[3] Open-content licenses make such coordination lawful; they substitute for the hierarchical structure of a firm by allowing each contributor to the project to adapt and reuse code contributed by earlier contributors. Each FOSS work, in other words, is protected by not one copyright, but many: each contributor’s contributions are individually protected from the moment of fixation, but then licensed for free reuse by members of the public.[4] If any of those underlying licenses is terminated, however, then the project may be effectively stymied, for the creation of further derivative works based upon the terminating author’s contribution would be prohibited.[5]
Although the FOSS community has never experienced an instance of license termination, one recent case did raise the possibility that code contributed to a FOSS project long ago was not validly licensed. The essence of the complaint in SCO v. IBM was that IBM had contributed code to the Linux kernel that was actually copyrighted by plaintiff SCO.[6] SCO’s case foundered when a district court found that it did not actually own the code in which it claimed copyright.[7] While the case was pending, however, it appeared
that Linux software developers would have to review an indetermi-
- ↑ See Weber, supra note 9, at 59 (“there are inherent limits to software that can be built by one or two people”).
- ↑ 17 U.S.C. § 201(b) (2006).
- ↑ See Weber, supra note 9, at 62–65.
- ↑ See Vetter, supra note 68, at 81 (describing the “web of license interdependency” among contributors to a FOSS project).
- ↑ See § 203(b)(1).
- ↑ See Kerry D. Goettsch, Recent Development, SCO Group v. IBM: The Future of Open-Source Software, 2003 U. Ill. J.L. Tech. & Pol’y 581, 583–84 (2003); Zittrain, supra note 9, at 266–67.
- ↑ See SCO Group v. Novell, Inc., No. 2:04CV139DAK, 2007 WL 2327587, at *35 (D. Utah Aug. 10, 2007). On March 30, 2010, following a trial, a jury found that the terms of the parties’ asset purchase agreement did not result in a transfer of copyright in the underlying code to SCO. SCO Group, Inc. v. Novell, Inc., No. 2:04-CV-139 TS, Special Verdict Form Mar. 30, 2010 (copy on file with the Harvard Journal on Legislation).
