Chapman Law Review
TESTING OPEN SOURCE WATERS: DERIVATIVE WORKS UNDER GPLV3
Copyright (c) 2009 Chapman Law Review; Joseph A. Chern
Richard Stallman has always believed that sharing software is a moral obligation. As such, in 1985, Stallman pioneered a movement towards free software and created the non-profit Free Software Foundation (“FSF”), a tax-exempt charity for free software development. The FSF, in turn, created the GNU General Public License (“GPL”) as an instrument to enforce free software principles. Although this license has become one of the most popular licenses in the world, legal uncertainties continue to plague its enforceability.
Among the debated issues of the license, the FSF maintains that dynamically linking to a GPL-ed library creates a derivative work under copyright principles subject to the original license. There is, however, difficulty with this position because dynamic linking technically does not create a “copy” of any GPL-ed software. This article analyzes perceived arguments both for and against the FSF position. The legal validity of these arguments will be evaluated in relation to the current approach courts have taken with software copyright. This article argues that the FSF most likely does not have legal support for its position that dynamic linking to a GPL-ed library creates any GPL obligation. The implications of this holding are also examined and alternative consequences are considered.
Part I of this article discusses the development of the FSF and explores the history of the GPL. Part II briefly describes the application of the GPL and introduces the FSF’s interpretation of the extent of that application. Part III explains the technical complexity of computers, describes how copyright law has attempted to address the complex nature of software, and revisits the FSF’s interpretations in depth. Finally, Part IV analyzes perceived legal issues with the FSF position regarding current copyright law and examines alternative outcomes.
Before examining the legal issues with dynamic linking, it is helpful to understand the rationale behind the GPL and the free software movement.
A. Beginning of Free Software
The motivation for the free software movement began in 1970 when Stallman worked as a programmer for the Massachusetts Institute of Technology’s (MIT) Artificial Intelligence Lab. Frustrated with a paper jam in one of the lab printers, he decided to take action. Using the source code freely provided with the centralized network printer, he modified the source code so that other users waiting would be alerted when the printer was jammed. Eventually, the lab received a new Xerox printer, and Stallman tried to make the same improvements; however, Xerox did not provide the printer’s source code. Xerox supplied the hardware, but denied the release of their source code under contractual obligations.
Consequently, Stallman set out to challenge the direction of software culture. In 1984, Stallman left MIT and wrote a complete operating system compatible with UNIX, the standard operating system at the time, and eventually called it “GNU.” In 1985, Stallman founded the FSF to promote the project’s concept of software freedom. The original focus of Stallman and the FSF was to bring a wholly free operating system into existence to give users an opportunity to inspect, share, and modify the source code of the software they used. According to the FSF, open source software hinges on the four software freedoms: (1) to run a program for any use; (2) to study the code and modify it for individual needs; (3) to redistribute; and (4) to improve a program for society. It is important to note that the movement’s goals are “primarily social and political, not technical or economic.” The term “free” did not mean monetarily free, but rather “free” to study and modify. FSF’s often-quoted catchphrase is “‘free’ as in ‘free speech,’ not as in ‘free beer.”’
B. General Public License, Versions 1-3
When Congress modified the Copyright Act to explicitly protect software programs, the FSF became concerned about its efforts to promote shared source code since battling a copyright holder required great time and resources. As a result, “companies, not hackers, held the automatic advantage[,]” and provider corporations effectively could hold a monopoly on their software. Software typically builds upon the source code from previous programs; therefore, tipping the scales in favor of large corporations places an arduous burden on the FSF’s goals. Eventually, the FSF recognized it could actually use copyright licensing to its advantage. A programmer could use a copyright license to bind others, who modify or distribute the programmer’s source code, to the license’s terms. Specifically, open source programmers, such as Stallman, could license their code with specific conditions, such as to allow others to copy it so long as they also publish any modified versions in return. This prompted the FSF to create a universal license making it possible for many projects to share the same code and keep programs free. Thus, the first version of the GNU General Public License (“GPLv1”) was born.
GPLv1 attempted to solve two major problems that restricted the freedoms of “free software.” First, many software companies released only binary versions–executable, but not modifiable or understandable by humans–of their source code. GPLv1 solved this problem by requiring the release of human readable source code under a GPLv1 agreement. Second, like the FSF, programmers could also benefit from copyright protection when they modified source code and redistributed it with additional restrictions to the existing license. GPLv1 did not allow for combinations with software that might impose additional restrictions, because this would create a conflict.
Two years later, the FSF published the second version of the license called GNU GPL version 2 (“GPLv2”). The underlying idea behind the second version was what the FSF calls “copyleft.” A play on the phrase copyright, “copyleft” promoted rather than restricted the use of copyrighted materials. This change was best embodied in Section 7 of the GPLv2, which states that if a user has restrictions–such as court orders, agreements, or otherwise–placed on GPL-covered software that may hinder the rights of others, the user cannot distribute that code at all. Most importantly, “copyleft” principles subjected the author of a GPLv2 piece of software to two requirements: (1) to license the original and modified versions of the software under the same license; and (2) to provide the source code to any user of the license. These provisions will be essential to the derivative work issue discussed below.
After fourteen years, GPLv2 began to show its age in the form of many legal problems. As a result, the final version of GPLv3, released on June 29, 2007, attempted to address some of the legal issues from the previous version while maintaining the core “copyleft” obligations. Among the significant issues, GPLv3 tried to clarify the scope of the license by introducing newly defined terms and consolidated requirements. GPLv2 borrowed many terms from U.S. copyright law, such as “derivative works” and “collective works”, but this only led to ambiguities about how far the license should reach. Furthermore, because the GPL is meant to be a global license that can apply in any country regardless of that country’s copyright laws, the GPLv3 abandoned the term “derivative work” and redefined the license to meet global standards. The new license also includes “propagate” and “convey” to define what constitutes distribution and tries to clarify whether dynamic linking falls within the scope of the “copyleft” license.
II. Software and GPL
The resolution of the legal issues with GPL greatly depends on the FSF’s ability to advocate for definitions of legal terms as applied to software. Such definitions have yet to be evaluated by the courts. In addition, the unique nature of how a GPL is triggered can effectively limit its scope. This section first describes that unique nature and then previews the FSF’s legal interpretations. A more in-depth discussion of the FSF’s interpretation is revisited in Section IV.C, following a discussion of current case law.
A. Triggering the GPL: “Distribution” and the “Viral” Effect
Pursuant to one of the “copyleft” provisions, modified versions of GPL-ed software are subject to the same license as the original code if released. Consequently, critics of the license have described it as having a “viral effect.” The effect of the license is metaphorically similar to that of a virus because in order to trigger the effects of the GPL, the only requirement is that any portion of the software be covered by the GPL. If any portion of the software is covered by a GPL license, the remaining portions of the code, even if it was intended to be proprietary, become “infected” with the license.
Distributing any software under the license can cause this viral effect. In order to use the license for a piece of software, the author only has to add two elements to his code: (1) “a copyright notice (such as ‘Copyright 1999 Terry Jones’);” and (2) “a statement of copying permission, saying that the program is distributed under the terms of the GNU General Public License.” When these two elements are present, any distribution of that code will be subject to the same terms of the GNU GPL. For instance, assume software Program A contains the two elements and, as a result, is covered under the GPL. Anyone would be free to use Program A to create Program B. Accordingly, Program B is “infected” by the GPL of Program A and must, at a minimum, have the same terms. In a simple situation, Program B typically contains a verbatim copy of Program A, which makes the license application a legal, rather than a technical, matter. In any case, the “viral effect” helps to achieve the goals of the free software movement by ensuring reciprocation of free software. It is important to note that neither private use nor modifications of a GPL code creates any licensing obligation, but obligations do apply if the code is publicly distributed.
B. FSF’s Interpretations of Derivative Works
The FSF has been less than clear on its definition of what creates a derivative work. However, in order to promote the free software movement and the goals of a GPL, it is important to draw the line between “infected” derivative works and works that are not “infected” that carry no “copyleft” obligations.
One thing is clear: the FSF has abandoned the term “derivative work” and has adopted “modified works” essentially to cover the same principles. Although “modified works” is defined in the latest GPL, the scope of the definition remains ambiguous and is still debated. One possible interpretation of the FSF definition of “modified works” is that the definition mirrors the scope of the U.S. copyright law’s definition of derivative work. However, the drafters of the GPL seemingly urge a broader interpretation. When answering questions about whether programs are covered under the license, the FSF generally leans towards the answer that provides the broadest coverage. Specifically, when dealing with a situation in which two separate programs are combined, each with a different license, the FSF would argue that in most cases the programmer/user would be “combining them into one program” under the GPL. However, the FSF has admitted that “[t]his is a legal question, which ultimately judges will decide.”
III. Program Linking and Copyright
The FSF’s acknowledgment that courts ultimately will decide the scope of GPL licensing suggests the need for an analysis of the current legal interpretations of copyright protection by courts. Section III.A begins with a technical primer on software linking that may affect a court’s treatment of copyright protection for software. Section III.B examines traditional copyright law and basic copyright principles and analyzes courts’ approaches to derivative works. Section III.C revisits the FSF’s interpretation of “modified works” and focuses on the role software linking might play in this analysis.
A. Program Linking (Static and Dynamic): Technical Background
Developers of software often use pre-written code and data when writing their own programs to avoid “reinvent[ing] the wheel.” Software “libraries” are commonly used collections of reusable code and data that provide “common functions, such as printing, reading data from a disk, or opening a file.” A computer will at some point “link” the relevant code from the library with the developer’s own code to create a larger functional program. The timing of this linkage depends on whether the process is accomplished through dynamic or static linking.
In computer science, “human readable source code” typically goes through several steps before it is executed by the compiler. Generally, these steps are divided into three “times”: compile time, load time, and execution time. During compile time, the source code is translated into machine code to create an object module that is read by the computer. What occurs during the load and execution times vary depending on hardware and software limitations.
If an operating system supports only static linking, the libraries that the source code uses are combined with the object module during load time. Effectively, this is akin to replacing footnotes in an essay with a copy of the referenced material. The libraries are treated like another object module that is physically combined together with the new code into which it was integrated. Conversely, if the operating system allows dynamic linking, the linking is “postponed until execution time.” With dynamic linking, a “bookmark” is placed in the source code for each library reference, which indicates how to load the library code when it is actually being used. Under this approach, there is no actual copy of the library code in the source code, but rather an address where the code can be accessed when needed. The library and source code remain separate files on disk.
B. Traditional Copyright Law
As copyright law has developed, it has dynamically embraced new technologies. For example, courts, and eventually Congress, agreed that lithographs and photographs constitute copyrightable subject matter in the early years. More recently, Congress convened the National Commission on New Technological Uses (“CONTU”) to thoroughly explore the scope of copyright protection for software, a concept with which courts continue to struggle. This section will introduce relevant principles of copyright law as applicable to software and briefly examine how the courts currently address the changes.
1. Brief Overview of Copyright and Software: Basic Application
Copyright is the right of an author to control the reproduction of his or her original expression. Whether an author owns a valid copyright depends, inter alia, on whether the subject matter is copyrightable. Copyrightable subject matter includes “original works of authorship fixed in any tangible medium of expression.” Works of authorship can include anything, from literary works such as novels, to musical works such as compositions and lyrics. However, although copyright law protects the expression of ideas, copyrights do not extend to either the functional elements or the ideas underlying those expressions; this is an area typically left to patent law. Because of the functional nature of software, Congress has been reluctant to allow for copyright protection for software. In fact, it was not until 1980 that Congress approved a statutory amendment to define a “computer program” in the Copyright Act. Following the decision in Apple Computer, Inc. v. Franklin Computer Corp., courts have continued to “reflect Congress’ receptivity to new technology and its desire to encourage, through the copyright laws, continued imagination, and creativity in computer programming.”
[A] work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgement, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ‘derivative work.’
Historically, “derivative works” have been simpler to identify in areas such as choreography, visual art, and literary sequels. Defining a derivative work in the software context has not been as obvious and finds little clarity in the statutory definition or case law. The recent trend in courts is that “copyright law today, in practice, affords narrow protection to software.” This may be because “as software patents gain increasingly broad protection, whatever reasons there once were for broad copyright protection of computer programs disappear.” Alternatively, copyright law may find difficulty affording broad protection because of the unique nature of software and the “inherent difficulty of fitting copyright[s] . . . to rapidly changing and variously described software technology approaches.”
The difficulty in providing protection for software is further complicated by the “fair use” exception for copyright protection. Essentially, fair use excuses “reasonable unauthorized appropriations” which is determined by evaluating four factors. The four factors are: (1) the purpose and character of the use; (2) the nature of the copyrighted work; (3) the amount and substantiality of the portion used in relation to the copyrighted work; and (4) the effect of the use upon the potential market. Because copying software is often for the public benefit, to promote the sciences without substantially impairing the value of the copied work, “fair use” has provided a venerable defense against infringement in the software context.
Despite the struggle to find steady copyright ground in the computer context, it may be useful to examine how courts have dealt with the issue thus far.
2. Reverse Engineering and Non-Literal Copying Software Cases
Recent court cases have confirmed that the unique nature of software yields different copyright results with similar fact patterns. Although there is currently scant case law specifically discussing whether dynamic linking of software programs can implicate a derivative work, there is an extensive history of reverse engineering and non-literal copying software cases that are instructive to the ultimate linking question. In a series of reverse engineering cases, courts have held that copyright infringement existed even when there was no literal copying of any software, as long as the visuals created by the software were substantially similar in both idea and expression, and at least an exact description of the visuals existed in concrete form. Some courts also have determined that there was no copyright infringement where the software distributed was not copied, even though there had been intermediate copying to create the distributed work.
For example, in Micro Star v. FormGen, Inc., the defendant owned the copyrights to a popular computer game. The game included an editor, which allowed players to create their own levels for the game. Without literally copying any of defendant’s software, plaintiff packaged user-created levels for sale on a CD. Plaintiff sought a declaratory judgment that there was no copyright infringement, while defendant counterclaimed for a preliminary injunction. In reversing the district court, the Ninth Circuit granted the preliminary injunction and held that the defendant would likely succeed in showing that the audiovisual displays generated when running plaintiff’s distributed levels would infringe on plaintiff’s right to create derivative works.
The Court reasoned that the displays would be similar in both idea and expression. Even though the plaintiff did not literally copy any of the software for the games, the plaintiffs were infringing on the defendant’s right to create sequels by creating new tales told by the plaintiff’s new levels. However, the Court clarified that the work the defendant was infringing upon was the story of the video game characters. It conceded that the software files themselves did not create the derivative works because they did “not, in fact, incorporate any of [plaintiff’s] protected [software].”
Similarly, in Worlds of Wonder, Inc. v. Veritel Learning Systems, Inc., the defendant made cassette tapes compatible for use with a toy bear named Teddy Ruxpin. The toy was animated by placing a cassette into the back of the animal, thus moving the eyes, nose, and mouth in synchronization with the story or song on the tape. Although the defendant did not actually copy any of the plaintiff’s tapes or software, the Northern District of Texas held that the “series of related images” that the tapes created were the copyrighted work in this case. Granting a preliminary injunction, the Court held that the defendant infringed the plaintiff’s right to prepare derivative works because defendant’s tape cassettes created a modified work substantially similar to the plaintiff’s “series of related images.” Again, because the defendant’s tapes did not contain any copyrighted software, the Court emphasized that the defendant was infringing the story of the toy rather than the tapes.
Furthermore, courts have found no copyright infringement where there was literal intermediate copying of plaintiff’s software, done only to access uncopyrighted elements of the code. In Sega Enterprises Ltd. v. Accolade Inc., the defendant copied the plaintiff’s video game code in order to reverse engineer the program to discover the requirements for compatibility with plaintiff’s video game console. The defendant used the information to create its own games to sell in the market. In the software code for these games, the defendant also included plaintiff’s initialization code into a standard header file to allow games to interact with the console code.
The Ninth Circuit ultimately held that the intermediate copying was fair use, and therefore was not infringement, because it was the only means to access the uncopyrightable elements, namely the compatibility procedure. The Court reasoned that the defendant was only trying to “become a legitimate competitor in the field of Genesis-compatible video games” and that consumers would still continue to purchase multiple video games. The Court also found the distribution of the header files was purely functional and held that “[t]he initialization code is a functional feature of a Genesis-compatible game and Accolade may not be barred from using it.” The Court focused on the purely functional aspect of the software copied in determining that the third party could distribute copies of the functional code.
In a similar case, Lewis Galoob Toys, Inc. v. Nintendo of America, Inc., the plaintiff created a device called a Game Genie, which was sold for use with a Nintendo Entertainment Video Game system. The device physically attached to the video games before they were placed into the console, in order to block data bytes sent to the console and replace the bytes with new values. Effectively, this allowed users to modify aspects of the game by entering in “cheat codes.”
The Ninth Circuit held that because the Game Genie acted only as a window into the computer program, it did not create a derivative work and there was no infringement. The Court focused on the fact that Game Genie, as distributed, did not contain any of the Nintendo code in “some concrete or permanent form” and therefore did not meet the statutory definition of a derivative work. It also did not matter that the visual images the code generated could be reconstructed when the game was over by entering the same codes, because the images did not exist permanently at distribution of the Game Genie. Despite copyright law’s lack of protection for functional elements, the Court also mentioned that the “Game Genie is useless by itself, it can only enhance” and “such innovations rarely will constitute infringing derivative works under the Copyright Act.”
Whether or not one agrees with the holdings of these cases, they all provide insight into the various approaches of applying copyright principles to software. Courts first determine whether a work “incorporates” any portion of the copyrighted work. If a work does not incorporate any protected expression, it cannot be a derivative. Even when protected expressions have been incorporated into the new work, they must exist in some “concrete or permanent form” at distribution to be a derivative work. Temporary reproductions following distribution are not enough to be “concrete or permanent.” Furthermore, even where there is intermediate copying, courts have suggested that this is permissible so long as it is used purely to gain access to the unprotected functional elements. Finally, attempts to promote creative expression may also influence how a court ultimately rules, regardless of any adverse market effect. Despite these opinions, the FSF appears to urge a different approach.
C. FSF / GPL Interpretation of Static / Dynamic Linking
The FSF, and the drafters of the GPL in particular, likely would not agree with courts’ treatment of derivative works. Terminology aside, whether or not a work is a “derivative” or “modified” version of a GPL-ed source is critical to the success of the free software movement. Because of the “viral nature” of the GPL, the narrower the scope of coverage under the GPL, the fewer “infections” and the fewer GPL-species works there will be. Accordingly, the FSF has attempted to tackle the problematic issue of what falls under the scope of the license by addressing program linking.
Software that uses static linking to a GPL library warrants minimal discussion that it is a derivative work under any definition. With software utilizing static linking, an actual copy of the GPL code is transcribed verbatim into the larger program. Because the software now contains the GPL code “or a portion of it, either verbatim or with modifications,” the software is now subject to the provisions of the license. Specifically, any future distribution and modification of that software must now include the source code and will be subject to the same license. This much seems clear.
Dynamic linking has generated a different response to the question whether a derivative or modified work is subject to GPL’s “copyleft” provisions. This debate occurs in part because the GPL library is never physically combined with the larger program in which it is referenced. As discussed above, the GPL library and the larger program exist on completely different disks, and the GPL software is never technically “modified.” Consequently, if no derivative work is created when dynamically linking to a GPL library, then there is no obligation to follow the license. Under this analysis, software developers are free to retain proprietary software despite using GPL code.
In spite of this, the FSF maintains that dynamic linking to a GPL library can create a single work that is subject to the GPL terms. When asked about the specific issue of program linking and its relation to GPLv3, Stallman expressly addressed that:
[I]t doesn’t matter which kind of linking is being used. If there are two modules that are designed to be run linked together and it’s clear from the design from one or the other that they are meant to be linked together then we say they are treated as one program and so I hope that will make it a little bit clearer although that’s not really a change, it’s a clarification. That’s what we believe GPL version two means already.
The “clarification” to which Stallman was referring is a new express provision in GPLv3. Under the new license, the “copyleft” obligation now extends specifically to “dynamically linked subprograms” that require an “intimate data communication or control flow between these subprograms.” The FSF appears to take a firm position that dynamic linking undeniably creates a “copyleft” obligation in a single work. However, it weakens its position with the self-imposed condition that the dynamic link must involve an “intimate data communication.” Thus, while the FSF clarifies rather than changes its view that dynamically linked programs always have been within the scope of the GPL, courts must now define terms such as “intimate” to determine the status of dynamically linked programs in addition to depending upon principles of copyright.
IV. Challenges and Issues with GPL and Dynamic Linking
This section analyzes the likelihood of success of the FSF’s argument, perhaps simplified, that dynamic linking creates a derivative work. Infringing upon an exclusive right such as preparing a derivative work would subject one to the restrictions of the corresponding license, namely the GPL in this case. Section IV.A considers the courts’ likely approach to the FSF’s argument based on current legal theories; Section IV.B examines the implications of the courts’ likely trend; and Section IV.C asks whether that approach is the optimal solution.
A. Is There Any “Copying”?
Courts specifically have never addressed the issue of whether non-GPL libraries can dynamically link to GPL libraries with or without the same “viral effect” of the license. The FSF leaves questions unanswered, and courts struggle to set standards for software in general. However, as case law on the issue is presently developing, a court likely would not find that a dynamically linked program falls within the scope of a GPL license.
With dynamic linking, the FSF would support a more technical analysis of the definition of “intimate.” If a linked program, whether dynamic or static, does not share the requisite “intimate data communication,” there is no “copyleft” obligation. However, as seen above, courts would likely focus on the abstract inquiry of whether the challenged software is a derivative work rather than on the underlying technology. In any case, it is unlikely that a court would find an “intimate relationship” if the court did not also find that the linked program was a derivative work. When a work does not incorporate any protected expression, it cannot be a derivative. Dynamic linking never incorporates any protected expression; it only makes references to it. One may argue that the operating system physically incorporates the code somewhere in memory during runtime when needed; however, while having some merit, this argument should fail for two reasons.
First, recall that the GPL applies only if the work is released. If a program can be released or distributed separately from a GPL work, the license obligation does not take effect. For example, assume Program A is meant to be maintained as a proprietary word processing program, while Program B is a GPL-ed printing program. Program A can be distributed for use to word process without any use of printing capabilities of Program B. Program A used alone does not “incorporate” any of Program B’s protected expression. If User X of Program A then wants to have printing functionality, he can independently acquire Program B and use it privately with no obligation. As a result, even if Program A and B are combined in memory when the computer is running both of them, there is no “copyleft” obligation for this private use.
Second, even if combined in memory when the user is running the program, copyright law requires the protected expression or, in the example above, Program B, to exist in some “concrete or permanent form.” Although virtual computer memory may be considered “concrete or permanent,” temporary recreations are not enough to meet this requirement. The combination will exist only while the programs run and, as in the Nintendo case, as soon as the programs end, the combination does as well.
A second argument could be made that even references to GPL-ed code can be considered to “incorporate” the protected expression. This argument should also fail. Courts have suggested that even intermediate copying is permissible in order to take advantage of the unprotected functional elements. References do not even rise to the level of intermediate copying, but are, as the name suggests, merely pointers to a particular function. Similar to copying an entire video game source code to find out compatibility functions, referencing to GPL-ed code is a mechanism to use the unprotected function and would likely not be considered “incorporation” of any protected material.
Finally, fair use factors may weigh in favor of no copyright infringement for dynamic linking. Even if there is copying in computer memory, the four fair use factors would likely not favor the FSF. First, the nature and purpose of using GPL-ed code is typically to promote software efficiency and to create new programs with additional functionality. Second, the nature of the GPL-ed work is that it already has been published because it is freely distributed and encourages its use. Third, the amount copied would be only that which is necessary for the program to function. Finally, courts have established fair use where the effect on the market from the copying is to establish legitimate competition. Software vendors could make these arguments in their favor to establish fair use.
As a result, a court would likely not find that a derivative work is created simply by dynamic linking because the GPL-ed code is neither “incorporated” nor exists in a “concrete or permanent form.” It is hard to imagine that the level of “intimate data communication” is met when one program is not a legal derivative of the other. Additionally, if a court finds “incorporation,” it is likely that the incorporation would be protected by fair use.
B. Implications Assuming No Obligations
Assuming dynamic linking to GPL code does not impose any “copyleft” obligations, proprietary software vendors can plan to selectively incorporate open software without further obligation. However, the free software community would not benefit from misappropriation of their work products. While pure believers in free software principles may continue their efforts in providing an open development model, others who once supported the FSF for its reciprocal guarantee that they would receive the same benefit may reconsider. This could result in a range of outcomes, from a floodgate of legal challenges to a decrease in free software development. The worst-case scenario might be an end of free software.
C. Alternative Outcome and Implications
Although a court most likely would hold that the distribution of software that only dynamically links to a copyrighted work is not itself a derivative work, it is worth exploring legal scenarios in which a court does impose copyright obligations for such a distribution.
One possible scenario could use the same principle for which the FSF is fighting and use it offensively. If dynamic linking creates derivative works because the operating system combines the works into shared memory, could the creator of the operating system equally argue that loading the software into its operating system creates derivative works and thus subjects users to their own license? For instance, could Microsoft, owners of the common operating system Windows, assert that dynamic loading of libraries in Windows creates a Microsoft licensed product? Furthermore, the Microsoft license could impose conflicting restrictions with the FSF such as prohibiting any GPL-ed linking in its entirety.
A second scenario may involve two dynamic libraries that both have the same functionality: lib_GPL, which is GPL-ed, and lib_BSD, which has no license obligations. Consider Program A that is distributed for use with either library, but will not function without one of them. Inevitably, users of Program A will choose to combine either library, but choosing one over the other may have entirely different consequences. Can it be possible that Program A is obligated by the GPL regardless of which library the user chooses? This likely would lead to yet another debate between the FSF, who would answer the question in the affirmative, and proprietary software vendors, who likely would disagree.
Software complexities have challenged the legal system to find workable standards in areas such as copyright law. While this area is still developing, the software industry has attempted to define its own responsibilities. However, these responsibilities may not always find legal support. The FSF, for instance, maintains that dynamic linking, just like static linking, to GPL-ed software can create a derivative work subject to a GPL license. Although dynamic and static linking perform the same functional goals from a programming perspective, their technical differences may produce different legal implications. To date, there is no case law addressing this specific issue; however, some opinions suggest that the FSF has questionable basis to assert that dynamic linking creates a derivative work. Unlike static linking, there is no requisite incorporation of protected material to create a derivative work. Furthermore, other copyright principles such as “fair use” likely weigh against the FSF’s position. With potentially both positive and negative consequences for not only free software but also proprietary software proponents, this unresolved intersection of technology and copyright law will provide a rich and interesting source of future legal developments.
Free software is a matter of the users’ freedom to run, copy, distribute, study, change and improve the software. More precisely, it means that the program’s users have the four essential freedoms: The freedom to run the program, for any purpose (freedom 0). The freedom to study how the program works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this. The freedom to redistribute copies so you can help your neighbor (freedom 2). The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
Free Software Foundation, The Free Software Definition, http://www.gnu.org/philosophy/free-sw.html (last visited Oct. 7, 2009).
[t]he GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them…. But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program’s users, under the GPL. Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you.
Free Software Foundation, Frequently Asked Questions About the GNU Licenses, Does the GPL require that source code of modified versions be posted to the public?, http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLRequireSourcePostedPublic (last visited Oct. 24, 2009) [hereinafter FSF Frequently Asked Questions].
To ‘modify’ a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a ‘modified version’ of the earlier work or a work ‘based on’ the earlier work.
General Public License v3.0, supra note 47, at §0.