13 Chap. L. Rev. 137

Chapman Law Review

Fall 2009



Joseph A. Chern 

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.

I. Background

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.” 

Software copyrightability allowed programmers to become the beneficiaries of exclusive rights including the right to prepare derivative works.  The Copyright Act defines a derivative work as:

[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.

Although the preceding thought experiments also result in potential problems for the FSF, it is worth considering which scenario will yield greater benefits for the public. 


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.

J.D. Candidate 2010, Chapman University School of Law; B.S. Computer Engineering, University of California, San Diego. I would like to thank Ryan Roemer for all of his constructive guidance and insight; Pamela Frohreich for her comments and encouragement; Kyhm Penfil for her edits and suggestions; and the Senior Articles Editors of the Chapman Law Review for all of their hard work. I also would like to thank my family for their love and support which made this possible.
Software developer of GNU operating system and founder of Free Software Foundation. See Richard Stallman, Richard Stallman’s Personal Home Page, http://www.stallman.org/#serious (last visited Oct. 7, 2009).
Brian W. Carver, Share and Share Alike: Understanding and Enforcing Open Source and Free Software Licenses, 20 Berkeley Tech. L.J. 443, 445 (2005) (describing Richard Stallman’s belief that proprietary software was incompatible with “the golden rule”).
Free Software Foundation, About Free Software and the GNU Operating System, http://www.fsf.org/about/ (last visited Oct. 7, 2009).
Free Software Foundation, What is free software and why is it so important for society?, http://www.fsf.org/about/what-is-free-software (last visited Oct. 7, 2009).
Free Software Foundation, Licenses, http://www.gnu.org/licenses/licenses.html#GPL (last visited Oct. 7, 2009) (reporting that the “GNU General Public License…is used by most GNU programs, and by more than half of all free software packages.”).
This article does not address all the legal issues with the GPL, but focuses on the issue of program linking. See infra Part IV.A; see also John Tsai, For Better or Worse: Introducing the GNU General Public License Version 3, 23 Berkeley Tech. L.J. 547, 548 (2008) (analyzing other issues with GPLv3 including software patents and digital rights management).
David Turner, LGPL and Java, (2004), http://www.fsf.org/licensing/licenses/lgpljava.html.
Abraham Silberschatz et al., Operating System Concepts (8th ed. 2009).
Sam Williams, Free as in Freedom: Richard Stallman’s Crusade For Free Software 1-12 (2002), available at http://www.oreilly.com/openbook/freedom.
Id. at 3.
In computer programming, source code (also known as source or code singularly) is a collection of human readable statements and declarations that allow programmers to communicate with computers. Eventually, source code is compiled to object code, which makes up programs such as Microsoft Word, an Internet Browser, or a game. For more information on source code and an example of the first source code written in the C programming language, see Brian W. Kernighan & Dennis M. Ritchie, The C Programming Language 1-7 (2nd ed. 1988).
Williams, supra note 9, at 3-5.
Id. at 4-6.
Hardware, as distinguished from software, is the general term to describe the physical components of technology such as the components that make up a personal computer, including a printer. Software is the general term to describe the collection or programs, which function to tell hardware how to act. See Walter Savitch, Java: An Introduction to Computer Science & Programming 4-5 (3d ed. 2004).
Williams, supra note 9, at 6.
An operating system is the software component of a computer system, which acts as a “manager” of the resources in the computer to coordinate between the hardware and software applications. See Savitch, supra note 14, at 8. Common operating systems are Windows for PC’s and Tiger for Apple computers.
Free Software Foundation, Overview of the GNU Operating System, http://www.gnu.org/gnu/gnu-history.html (last visited Oct. 7, 2009) (“The GNU operating system is a complete free software system, upward-compatible with Unix. GNU stands for ‘GNU’s Not Unix’.”).
What is free software and why is it so important for society?, supra note 4 (“in 1985, Stallman started the Free Software Foundation, a nonprofit with the mission of advocating and educating on behalf of computer users around the world.”).
Free Software Foundation, Philosophy of the GNU Project, http://www.gnu.org/philosophy/philosophy.html (last visited Oct. 7, 2009) (describing the “philosophy of the free software movement, which is the motivation for our development of the free software operating system GNU”); see also Eben Moglen & Richard Stallman, GPL Version 3: Background to Adoption, http://www.fsf.org/licensing/essays/gpl3-background.html (last visited Oct. 7, 2009).
The Free Software Foundation defines the four essential freedoms:
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).
Moglen & Stallman, supra note 19.
GNU General Public License, version 2, http://www.gnu.org/licenses/oldlicenses/gpl-2.0.html (last visited Oct. 7, 2009) [hereinafter General Public License v2.0]; see also Carver, supra note 2, at 450-53 (using the term “open source” for software that refers to an open development process).
Free Software, Free Society: Selected Essays of Richard M. Stallman 41 (Joshua Gay ed., 2002).
Act to Amend the Patent and Trademark Laws, Pub. L. No. 96-517, 94 Stat. 3015, 3028 (1980) (codified as amended at 17 U.S.C. §117 (2006)); see also discussion infra Part III.B.
Williams, supra note 9, at 123.
Savitch, supra note 14, at 12.
Williams, supra note 9, at 123-26.
Open source programmers are generally defined as computer software programmers who use and make software readily available to the public domain. Open source software is to be distinguished from proprietary software. See Open Source Initiative, The Open Source Definition, http://opensource.org/docs/osd (last visited Oct. 7, 2009) (describing ten criteria for open source software).
Williams, supra note 9, at 124.
Robert W. Gomulkiewicz, General Public License 3.0: Hacking the Free Software Movement’s Constitution, 42 Hous. L. Rev. 1015, 1024 (2005).
The full text General Public License, version 1 is available at http://www.gnu.org/licenses/old-licenses/gpl-1.0.html (last visited Oct. 7, 2009) [hereinafter General Public License v1.0].
Free Software, Free Society, supra note 23, at 4, 170-71.
General Public License v1.0, supra note 33.
Gomulkiewicz, supra note 32, at 1025-26 (reporting that Stallman created the second version to clarify misunderstandings and worries).
See Free Software Foundation, What is Copyleft?, http://www.gnu.org/copyleft/copyleft.html (last visited Oct. 14, 2009).
General Public License v2.0, supra note 22, at §7.
Id. at §§2-3.
See discussion infra Part IV.A.
Moglen & Stallman, supra note 19.
Not all of the legal issues are addressed here since the list could go on, but rather the most significant issues to this article will be discussed.
Compare Free Software Foundation, GNU Project: GNU General Public License Version3,http://www.gnu.org/licenses/gpl-3.0.html (last visited Oct. 14, 2009) [hereinafter General Public License v3.0], with General Public License v2.0, supra note 22.
See General Public License v2.0, supra note 22, at §§0, 2(c); 17 U.S.C. §101 (2006).
Carver, supra note 2, at 458-60.
Moglen & Stallman, supra note 19; compare GPLv3, supra note 47, at § 0, with GPLv2, supra note 22, at §0.
General Public License v3.0, supra note 47, at §0.
Tsai, supra note 6, at 566.
“Modified versions,” as used here, is similar to the “derivative work” concept that was replaced from GPLv2. The term here assumes the work falls within the GPL definition of modified work.
See Free Software Foundation, supra note 40.
Among frequently asked questions, the Free Software Foundation provides:
[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].
Ron Phillips, Deadly Combinations: A Framework for Analyzing the GPL’s Viral Effect, 25 J. Marshall J. Computer & Info. L. 487 (2008).
General Public License v3.0, supra note 47, at §§0, 10 (describing the viral effect by automating licensing to any downstream recipients for works that are covered, which means any unmodified programs or worked based on the program).
Phillips, supra note 56, at 492.
Id. at 492-93; General Public License v3.0, supra note 47, at §§0, 10 (describing the viral effect by automating licensing to any downstream recipients for works that are covered, which means any unmodified programs or worked based on the program).
Free Software Foundation, How to use GNU licenses for your own software, http://www.gnu.org/licenses/gpl-howto.html (last visited Oct. 24, 2009).
FSF Frequently Asked Questions, supra note 55.
See supra Part II.A.
See supra Part I.B; compare General Public License v3.0, supra note 47, at §0 (“The resulting work is called a ‘modified version’ of the earlier work or a work ‘based on’ the earlier work”) with General Public License v2.0, supra note 22, at §0 (“The ‘Program,’ below, refers to any such program or work, and a ‘work based on the Program’ means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications…”).
The Free Software Foundation defines modify as:
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.
Tsai, supra note 6, at 548, 566-68 (arguing that new language creates new ambiguities and the open source community is still split over several key issues as to what is covered under GPL licenses).
17 U.S.C. §101 (2006) (“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.”’); see also copyright discussion infra Part III.B.1.
University of Washington School of Law, Derivative Works, http://www.law.washington.edu/lct/swp/Law/derivative.html (last visited Dec. 28, 2009) (arguing GPL drafters urge a broader definition of derivative works than US Copyright law); see also infra Part III.C; see also Tsai, supra note 6, at 555-56 (outlining a broader interpretation of the GPLv2 to include both collective works and compilations).
FSF Frequently Asked Questions, supra note 55 (asserting adding modules to GPL programs are also covered, output from GPL covered programs can be covered by GPL, linking to libraries is also covered); see also infra Part III.C.
See discussion infra Part III.A.
FSF, Frequently Asked Questions, supra note 55.
See Savitch, supra note 14, at 12, 18 (stating programs are not typically written as one piece of code and may consist of several different parts, written by different people, combining other components that already exist).
Alexandra J. Horne, Shared Rights to Source Code: The Copyright Dilemma, 32 Santa Clara L. Rev. 497, 532 (1992) (“Furthermore, because of the complexity of the development process, the software developer can argue that the library routines must be afforded copyright protection because of the economic hardship the developer will face due to the prohibitive expense required to ‘reinvent the wheel’ for each new development project.”).
Tsai, supra note 6, at 557.
Savitch, supra note 14, at 12 (describing the process of connecting several different pieces of code together as linking).
Silberschatz, supra note 8, at 321.
Id. at 318.
Savitch, supra note 14, at 9 (describing a compiler to translate the high-level language that humans can understand [source code] into low-level languages [machine code] that the computer can understand).
See Silberschatz, supra note 8, at 320.
See Tsai, supra note 6, at 557; Silberschatz, supra note 8, at 321.
See Silberschatz, supra note 8, at 828.
Id . at 321.
Id .
See id .
See id .
See, e.g., Burrow-Giles Lithographic Co. v. Sarony, 111 U.S. 53, 58 (1883) (holding that there is “no doubt that the Constitution is broad enough to cover an act authorizing copyright of photographs, so far as they are representatives of original intellectual conceptions of the author”).
17 U.S.C. §102(a)(5) (2006).
National Commission on New Technological Uses of Copyrighted Works, Final Report (1978).
See, e.g., Apple Computer, Inc. v. Franklin Computer Corp., 714 F.2d 1240, 1247 (3d Cir. 1983); see also Lotus Dev. Corp. v. Borland Int’l, Inc., 516 U.S. 233 (1996); Ticketmaster Corp. v. Tickets.com, Inc., No. CV 99-7654 HLH (BQRX), 2000 WL 525390, (C.D. Cal. Mar. 27, 2000).
Robert A. Gorman & Jane C. Ginsburg, Copyright Cases and Materials 12 (7th ed. 2006).
17 U.S.C. §102 (2006).
§102(a); see also Feist Publ’n, Inc. v. Rural Tel. Serv. Co., Inc., 499 U.S. 340, 346 (1991) (providing “original works” has not meant novel or unique, but rather independent creations with a minimal modicum of creativity).
§102(b) (“In no case does copyright protection…extend to any idea, procedure, process, system, method of operation…”); compare 35 U.S.C. §101 (2006) (discussing patentable inventions).
Act to Amend the Patent and Trademark Laws, Pub. L. No. 96-517, 94 Stat. 3015, 3028 (1980) (codified as amended at 17 U.S.C. §117 (2006)); see also Apple Computer, Inc. v. Franklin Computer Corp., 714 F.2d 1240, 1247 (describing that although computer programs are not expressly listed as a work of authorship, legislative history suggests that programs were considered copyrightable as literary works and software was not per se uncopyrightable purely based on functionality).
Apple Computer, 714 F.2d at 1254.
17 U.S.C. §106 (2006) (enumerating the exclusive rights that the owner of a valid copyright has and can authorize, including reproduction, preparation of derivative works, distribution, and public performance of their copyrighted work).
17 U.S.C. §101 (2006).
See, e.g., Horgan v. MacMillan, Inc., 789 F.2d 157, 162 (2d Cir. 1986).
See, e.g., Lee v. A.R.T. Co., 125 F.3d 580, 581 (7th Cir. 1995).
Suntrust Bank v. Houghton Mifflin Co., 268 F.3d 1257, 1259 (11th Cir. 2001).
Carver, supra note 2, at 458 (noting the lack of case law and statutes to clarify derivative works for software).
Emanuela Arezzo, Struggling Around the “Natural” Divide: The Protection of Tangible and Intangible Indigenous Property, 25 Cardozo Arts & Ent. L.J. 367, 411 (2007).
Mark A. Lemley, Convergence in the Law of Software Copyright?, 10 High Tech. L.J. 1, 26 (1995).
Raymond T. Nimmer, Legal Issues in Open Source and Free Software Distribution, 885 PLI/P at 33, 91 (2006).
17 U.S.C. §107 (2006).
Id.; see also Campbell v. Acuff-Rose Music, Inc., 510 U.S. 569, 578 (1994) (“All [factors] are to be explored, and the results weighed together, in light of the purposes of copyright.”).
§107(1); see also Sega Enters. Ltd. v. Accolade, Inc., 977 F.2d 1510, 1514 (9th Cir. 1992) (holding intermediate software copying is allowed if it is the only means to get to the uncopyrighted functional material).
§107(2); see also Harper & Row Publishers, Inc. v. Nation Enters., 471 U.S. 539, 561 (1985) (weighing sub-factors such as whether the copyrighted work has been published already since right to first publication is important under copyright).
§107(3); see also Harper & Row, 471 U.S. at 601 (Brennan, J., dissenting) (weighing quality of portion used versus quantity).
See Sega, 977 F.2d at 1523 (considering the public benefit that copying software for the functional requirements would increase creative expressions based on the unprotected ideas); see also Sony Computer Entm’t, Inc. v. Connectix Corp., 203 F.3d 596, 607 (9th Cir. 2000) (stating copyright law does not create monopolies over certain markets and legitimate software competitors may be welcomed so long as it does not merely supplant the original).
This is not an exhaustive list of all computer or software related cases, but rather a select few that reflect common principles within the scope of this article.
See also Andre R. Jaglom, Internet Distribution, E-Commerce and Other Computer Related Issues: Current Developments in Liability On-Line, Business Methods Patents and Software Distribution, Licensing and Copyright Protection Questions, SN019 A.L.I.-A.B.A. 535, 606 (stating that “[t]he difficulty is in establishing the scope of copyright protection, since unlike the traditional kinds of works protected by copyright, software has a significant functional component”).
Reverse engineering is essentially looking at a final product or output and working backwards to uncover the underlying elements that make the product or output work. See Sega, 977 F.2d at 1514.
Micro Star v. FormGen Inc., 154 F.3d 1107, 1111-12 (9th Cir. 1998); Worlds of Wonder, Inc. v. Veritel Learning Sys., Inc., 658 F. Supp. 351, 355 (N.D. Tex. 1986); Midway Mfg. Co. v. Arctic Int’l., Inc., 704 F.2d 1009, 1013 (7th Cir. 1983).
See Sega, 977 F.2d at 1514; Sony, 203 F.3d. at 600 (dismissing copying because it was only intermediate).
Micro Star, 154 F.3d at 1109.
Id. at 1114.
Id. at 1112.
Worlds of Wonder, Inc. v. Veritel Learning Sys., Inc., 658 F. Supp. 351, 352 (N.D. Tex. 1986).
Id. at 355.
Id. at 356.
Sega Enters. Ltd. v. Accolade, Inc., 977 F.2d 1510, 1514 (9th Cir. 1992).
Id. at 1515.
Id. at 1516. Initialization code in the context of computer programming is code that gives variables a value prior to executing the code. For more discussion on initialization code, see Kernighan & Ritchie, supra note 11, at 40.
Sega, 977 F.2d at 1516. In computer programming, particularly in the C and C++ programming language, header files are separate files from the source code, which typically contain declarations for variables, classes, subroutines, and other identifiers. For more discussion on header files, see Kernighan & Ritchie, supra note 11, at 33.
Sega, 977 F.2d at 1514.
Id. at 1518.
Id. at 1523; see also Sony Computer Entm’t, Inc. v. Connectix Corp., 203 F.3d 596, 602 (9th Cir. 2000) (applying the analysis in Sega to determine that defendant’s copying of plaintiff’s code from a video game console was fair use because it was for purposes of a new video game, different in character, and that defendant was a legitimate competitor in the market for plaintiff’s games).
Sega, 977 F.2d at 1531.
See id. at 1516.
Lewis Galoob Toys, Inc. v. Nintendo of Am., Inc., 964 F.2d 965, 967 (9th Cir. 1992).
Id. at 968; see also Micro Star v. FormGen Inc., 154 F.3d 1107, 1111 (9th Cir. 1998) (distinguishing the case based on the software existing in some permanent or concrete form).
Id. (characterizing the Nintendo case saying once the game was over, the audiovisual displays generated were gone and as a result, were not permanent).
Lewis Galoob Toys, 964 F.2d at 969; see also 17 U.S.C. §117 (2006) (codifying the exception that it will not be infringement for the owner of a computer program to make a copy or adaptation provided the new copy or adaptation is created as an essential step in the utilization of the computer program).
See Micro Star, 154 F.3d at 1110-11.
Id. at 1110.
Lewis Galoob Toys, 964 F.2d at 967.
Micro Star, 154 F.3d at 1111 (characterizing the Nintendo case saying once the game was over, the audiovisual displays generated were gone and as a result, were not permanent).
Sega Enters. Ltd. v. Accolade, Inc., 977 F.2d 1510, 1524 (9th Cir. 1992); see also 17U.S.C. §117 (2006) (codifying the exception that it will not be infringement for the owner of a computer program to make a copy or adaptation provided the new copy or adaptation is created as an essential step in the utilization of the computer program).
Sega, 977 F.2d at 1523 (noting the court is “free to consider the public benefit resulting from a particular use notwithstanding the fact that the alleged infringer may gain commercially” and growth of creative expression can serve a public interest); see also Lewis Galoob Toys, 964 F.2d at 969 (recognizing that “technology often advances by improvement rather than replacement” as a reason to exclude works such as spell-checking or the Game Genie from infringement), and U.S. Const. art. I, §8 (granting Congress power to enact Copyright laws “to promote the progress of science and useful arts”).
See supra Part II.B; see also infra Part III.C.
See Derivative Works, supra note 68 (arguing GPL drafters urge a broader definition of derivative works than US Copyright law).
See supra Part II.B.
See supra Part II.A.
See infra Part IV.A.
See supra Part III.A.
General Public License v2.0, supra note 22, at §0.
Id. at §§1-3.
Lothar Determann, Dangerous Liasons – Software Combinations as Derivative Works? Distribution, Installation, and Execution of Linked Programs Under Copyright Law, Commercial Licenses, and the GPL, 21 Berkeley Tech. L.J. 1421, 1458-62, 1488 n.255 (2006) (stating that dynamic linking typically does not create a derivative work).
See infra Part IV.A.
See supra Part III.A.
See Phillips, supra note 56, at 500-02.
Free Software Foundation, supra note 71 (“If the modules are included in the same executable file [static linking], they are definitely combined in one program. If modules are designed to run linked together in a shared address space [dynamic linking], that almost surely means combining them into one program.”).
Richard Stallman, Transcript of Richard Stallman in Torino, (March 18, 2006), http://www.fsfeurope.org/projects/gplv3/torino-rms-transcript.en.html#q2-linking (last visited Nov. 11, 2009).
General Public License v3.0, supra note 47, at §5.
Id. at §6 (requiring one to supply corresponding source); Id. at §1 (defining corresponding source to include “interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work”).
Id. at §1; see also Tsai, supra note 6, at 566 (arguing that the FSF takes a “tenuous position, stating first that dynamically linked programs are within the scope of the [license], then pulling back with a cryptic condition”); Free Software Foundation, supra note 71 (stating that one relevant condition should be what kind of information is exchanged).
In a close case, MySQL AB v. Progress NuSphere, Plaintiff sued Defendant for copyright infringement by linking code, but the case settled. See Press Release, MySQL, FAQ on MySQL vs. NuSphere Dispute (Jul. 13, 2001) available at http://www.mysql.com/news-and-events/generate-article.php?id=75.
See infra Part IV.C.
See supra Part III.B.
See General Public License v3.0, supra note 47.
See supra Part III.B.2.
Micro Star v. FormGen Inc., 154 F.3d 1107, 1110 (9th Cir. 1998).
Silberschatz, supra note 8, at 268-71.
See Free Software Foundation FAQs, supra note 55.
See General Public License v3.0, supra note 47; Viral Code and Vaccination, supra note 58.
See Lewis Galoob Toys, Inc. v. Nintendo of Am., Inc., 964 F.2d 965, 968 (9th Cir. 1992).
See also Micro Star v. FormGen Inc., 154 F.3d 1107, 1111 (9th Cir. 1998) (stating that concrete and permanent forms can exist on CD-ROMs, which are a type of computer memory).
See Lewis Galoob Toys, 964 F.2d at 967 (stating the effects of the toy were temporary).
See Savitch, supra note 14, at 5 (stating computer memory is used for computer’s “intermediate calculations”).
See Sega Enters. Ltd. v. Accolade, Inc., 977 F.2d 1510, 1514 (9th Cir. 1992); Sony Computer Entm’t, Inc. v. Connectix Corp., 203 F.3d. 596, 600 (9th Cir. 2000) (dismissing copying because it was only intermediate).
Sega, 977 F.2d at 1526.
See supra Part III.B.1.
Tsai, supra note 6, at 557; Savitch, supra note 14, at 12.
Sega, 977 F.2d at 1514, 1524.
See General Public License v3.0, supra note 47.
Free Software Foundation, Copyleft and the GNU GPL, http://www.gnu.org/gnu/thegnuproject.html (last visited Jan. 11, 2010) (admitting that “to permit such combinations would open a hole big enough to sink a ship”).
General Public License v1.0, supra note 33 (stating that GPLv1 does not allow for combining code with conflicting licenses and thus would result in less possible code combinations in the world).
See supra Part III.B.2.