CASRIP Newsletter - Summer 2007, Volume 14, Issue 3
License or Contract?: GPLv3 and the Persistent Controversy Over GPL Enforceability
By Adam Ake, J.D., LL.M., M.B.A., M.St.[*]
What's so funny about this is GPL is it was supposed to be all about freedom, but there are freedoms that GPLv3 tries to deny users. — Jeff Seul
Open source software (OSS)—constantly increasing in functionality and popularity—presents a serious challenge to the business models of traditional commercial software companies. OSS, as distinguished from public domain software, is distributed with a copyright license that enables others to use its underlying programming in order to modify it freely. There are many, perhaps hundreds, of different versions of “open source” copyright licenses; however, the Free Software Foundation’s General Public License is widely viewed as the most important.
The General Public License (GPL) has taken on significant importance in today’s software market. Since its release in 1991, the GPL version 2 ("GPLv2") has been attached to a substantial majority of all large-scale OSS projects, including—most notably—the Linux kernel. Despite the GPLv2’s popularity, in 2006 the Free Software Foundation (FSF) released a draft of the third version of the GPL (GPLv3) to address issues that which had arisen since GPLv2’s promulgation and which some in the open source community perceived as threatening their movement. After two early drafts circulated for discussion encountered a hostile reception in several important sectors of the open-source community, the FSF distributed a third discussion draft on March 28, 2007. It then released a final version of the GPLv3 at the end of June.
As more and more software—often derivative works of earlier, GPL licensed works—gets distributed under various versions of the GPL, its importance increases, and any changes to the GPL’s terms become particularly important for those companies that have figured out a way to incorporate GPL-licensed software into their business models. Those who aim to profit from GPL’d software have good reason to be wary of the GPL’s authors, the Free Software Foundation, because that group’s stated aims are in significant tension with those who seek to gain a competitive business advantage from OSS.
The goals of the Free Software Foundation are somewhat anarchic, paradoxical and—to many lawyers—a bit unsettling. Put bluntly, the FSF attempts to use copyright law to destroy copyright protections (as well as patent and digital rights management) for software. Intuitively, the use of a law to remove the protections of the same law produces—to use a technical term—an “icky” feeling. The result it seeks to obtain is clearly antithetical to the legislation’s original intent. But is it legitimate?
This paper attempts to address some current legal and strategic issues surrounding the GPL as its drafters attempt to revise the popular license. Part I of this paper gives a brief background on the GPL and the Open-Source movement and the major players involved in current controversies surrounding the document. Part II discusses one important topic that is a carryover issue from earlier versions of the GPL: the issue of copyright license vs. contract, with particular emphasis on available remedies for GPL violations.
A. Open Source Definition and History
In the 1960’s and into the 1970’s the close-knit community of computer programmers at the then-premier computer science institutions in the United States, like Stanford, Carnegie-Mellon, MIT and Berkeley, freely passed their source code among themselves. The prevailing ethos within the community of programmers included an expectation that any improvements made to code would be widely distributed to the entire community.
Developments in the computing world ran counter to this early practice, and some within the community pushed back against the trend towards proprietary software. As computing grew more widespread and software production became more distinct from the purpose-built machines of the earlier generation, companies specializing in software development availed themselves of the protection of copyright and trade secrecy law to protect their efforts in software development. Sensing a threat to the communal ideal that had existed within the early software development community as well as the threat that proprietary, copyrighted software posed to interoperability and the engineers’ vision for the future of computing (which included open standards available to all), a group of software engineers led by Richard Stallman formed the Free Software Foundation in 1985.
1. What is Open Source Software?
Free as in free speech, not free as in free beer – GNU’s Free Software Definition
At its most fundamental level, open source software means that the underlying instructions that software conveys to a computer is available to the user in human readable form, known as source code. Most commercial software is released in the form of object code—meaning in a non human-readable string of ones and zeros that instructs the computer to act. For the user who just wants to run the software, only software distributed in object code form is necessary. Open source software, by way of contrast, is distributed with the source code included, which would allow someone knowledgeable in that programming language to alter the programming instructions and change the software – or, also importantly – to program software that interoperates with the first piece of software. While source code availability may be of little help to most users, it can indirectly help them by keeping costs of software low (since open promulgation of source code diminishes opportunities to extract economic rents by a dominant player who keeps as a proprietary secret information necessary to achieve interoperability) and by fostering the creation of software that works better, since users themselves can fix bugs and redistribute the software after it has been so fixed. While software released as “open source” gives the user access to the software’s source code so the user is free to modify it, it does not indicate that the software is actually provided free of charge – indeed, plenty of “freeware” is distributed in object-code form only and would not be considered open-source. Thus, OSS describes a relatively wide range of software bounded by that purely dedicated to the public domain (i.e., freeware distributed without license in source code form) on one end of the spectrum and on the other end by software where source code is concealed, copyrighted (without availability of license), or patented.
2. How the GPL Fits into OSS
While some OSS borders on public domain, what distinguishes it from pure public domain is that it is distributed subject to a license. One of these licenses, the GPL, is the primary subject of this paper both because it has proven so popular (it covers an estimated 72% of the 143,562 projects under development on the open source hosting site SourceForge and governs three of the most successful open source applications to find their way into data centers: the Linux operating system, the MySQL database, and the Windows-Linux file sharing system known as Samba) and because of its novel “give-back” provision.
To be covered by the GPL, a user who distributes modified GPL-covered code must release the entire work under the GPL, and must include notice of the terms of the license for all subsequent distributors. Under the GPL, the developer distributing the modified code is free to charge any price she wants to transfer the program to the next user, but because the distribution must be made under the GPL, the developer must give that user the right to transfer the program to anyone, at no charge. The freedom for any downstream user to make unlimited distributions makes charging any significant transfer price unsustainable, so once the software has been transferred from the original owner, the market cost will tend toward the cost of distribution: usually approaching zero. Software modification under the GPL can range from minor bug fixes to the reuse of source code in an entirely different project, though just how much GPL’d code must be incorporated into a new work for it to be fairly said to be “derivative” has not been conclusively established, and would likely have to be determined on a case by case basis. Additionally, the GPL attempts to encompass more than what the Copyright Act would recognize as “derivative” and, to the extent that a “work based on GPL code” exceeds “derivative work,” that term may be enforceable only under contract law, if at all.
3. Competing Licenses
There are several other OSS licenses besides the GPL, including a few that have proven successful in supporting business models for commercial software entities which choose to distribute their software under them or to use such software to develop their own. The GPL could, at best, be considered a “business-unwieldy” license since it essentially mandates a software business model (if any) where all profits from the resulting software are generated by income from support services provided ancillary to the software’s distribution. Alternatively, licenses like the Berkeley Software Distribution (BSD) license allow businesses to build on OSS to create proprietary software, and merely exist to clarify an open license for use along with a disclaimer of upstream liability for the provided code. The most recent Macintosh operating system, OS X, is an example of successful creation of proprietary software based, at least in part, on BSD-licensed code. Between these two licenses exists a variety of alternatives and variations: For example, the license that covers the Apache Web server, from the Apache Software Foundation, doesn't include the "give-back" provision of the GPL; the same is true of the Eclipse Foundation's license, which covers projects adding to the Eclipse development environment; and Mozilla has a license which allows proprietary code to be combined with the open source. But tension exists between the GPL and these other, more business-friendly licenses.
Open source purists, such as those in the Free Software Foundation, believe the BSD license, along with similar licenses that are non-“infectious” (meaning they do not control everything they touch), are detrimental to the open source community because they do not require downstream users of BSD-licensed software to openly release their modifications back to the community. Additionally, conflict exists when software developers in the open source community derive their new projects from source code distributed under different licenses. While theoretically developers may choose the license that best satisfies their proprietary and/or open source goals by selecting the appropriate license for their business model, in practice the GPL and other restrictive licenses can “infect” software coming into a project under other licenses, therefore, any software derived in part from code under different licensing terms will default to the most restrictive license terms under which any upstream code was provided. In reaction, some software developers choose to release their programming under both the GPL and another (or more) licenses that are mutually incompatible.
B. Current Players and Recent Clashes
There is little doubt that some commercial software makers increasingly view GPL as a threat, though taking such a position overtly is perceived as something of a poor public relations move. What follows is a brief introduction to the players in the GPL debate and recent litigation arising over GPL software.
1. Free Software Foundation & Richard Stallman
To call Stallman an interesting character is like describing Dennis Rodman as an interesting basketball player. — Charles Babcock
The FSF … regards proprietary software as immoral, patents as the work of the devil, digital rights management as an unacceptable infringement on freedom, and markets for intellectual creations as undesirable or irrelevant. — James DeLong
To the Biblically-inclined, Richard Stallman, the Free Software Foundation’s founder and the GPL’s primary author, evokes John the Baptist in more ways than one. Like the New Testament figure, Stallman has the look of a wild man with his trademark disheveled dress, long brown hair, and scraggily beard; additionally, his mission in life is to spread his vision of the world to come. Stallman wrote the first version of the GPL in 1989, and it was then, as now, as much a political manifesto as it was a copyright license, laced as it was with anti-capitalist and anti-authoritarian jabs against commercial software practices in nearly every section. His views that “software-wants-to-be-free” and his radical “copyleft” approach to twist copyright laws were embodied in the GPL and have guided the development of the Open Source movement. Though the movement has experienced a schism between those who believe there is nothing inherently wrong with proprietary software (such as those who license their work under the BSD license), Stallman continues to be the leader of a major portion of the community who believe fervently in free software. A more specific term for these anti-proprietary open source believers is the Free & Open Source Software (FOSS) community.
The largest opponent of open source software (at least in the eyes of those in the open source movement), Microsoft, did not initially recognize OSS as a threat to its business model. However, certainly by 1998, Microsoft began to recognize that OSS presented a legitimate threat to important parts of its businesses. In that year, several Microsoft-internal marketing documents (now known in the Open-Source community as the “Halloween documents”) identified open source software as a major threat to Microsoft market dominance and suggested ways to interrupt its progress. The memos indicated that "commercial quality can be achieved or exceeded by [open source software]" and admitted that the Linux operating system was a "long-term credible" threat to Windows. Ever cautious about appearing in public to be abusing its dominant market position, Microsoft has battled the tide of open source software with subtlety and encouraged attacks by others. The most notorious “other” that has taken on the FOSS community is the SCO Group.
3. The SCO Group
If it weren’t for the litigation the Santa Cruz Operation, Inc. (SCO), had initiated against commercial OSS distributors, it is almost certain that very few people would have heard of the SCO Group. Yet, SCO is on the front lines of the litigation battlefield trying to contain the spread of FOSS distributed through commercial vendors. SCO claims to hold the copyrights to extensive portions of the UNIX code that it purchased from Novell in 1995 and which it claims have been knowingly incorporated into the GNU/Linux operating system.
SCO has filed suits alleging not just copyright violations, but also has made broader attacks on the validity of the GPL. In March 2003, SCO filed suit against Linux distributor IBM, alleging that IBM had incorporated SCO-owned UNIX code into its distribution of Linux and asked for billions of dollars in damages. SCO has subsequently sued AutoZone, DaimlerChrysler, RedHat and Novell, and has sent letters to other companies running Linux systems asking them to stop using the operating system. SCO has also attacked the GPL itself and claimed, among other things, that it is unconstitutional under the Intellectual Property Clause in Art. I and violates federal antitrust laws.
SCO has resisted producing the specific lines of code it claims to have been infringed. Because of this reluctance, many in the FOSS community and the computing press are skeptical over SCO’s motives and have labeled the entire effort as one meant to create fear, uncertainty and doubt (FUD) among Linux users. Several leaders of the open source movement have challenged SCO CEO Darl McBride in a series of open letters to produce the offending source code, but SCO has resisted, citing trade secrecy reasons, though it asserts that it has provided the allegedly infringing code to those willing to sign a non-disclosure agreement. SCO seemingly seeks to capitalize on the FUD it is creating among the Linux-using community by marketing an end-user license—with an annual fee—that will immunize the user (based on numbers of CPUs or servers running Linux) from suits by SCO for copyright infringement. Adding to this impression that SCO is merely up to no good and doing the dirty work of the proprietary big boys are indications—long suspected in the FOSS community—that Microsoft is indirectly bankrolling the continued litigation brought by the SCO Group against IBM and other Linux distributors by funding SCO’s venture capitalist backers.
SCO has not fared well in court to date. Several of its cases have been stayed pending the Novell litigation, which could wind up with SCO not owning the rights it has been asserting all along, and its suit against DaimlerChrysler has been dismissed. Furthermore, the claims SCO had been making over the illegality of the GPL itself have been litigated by another, rather unlikely figure.
4. The Wallace Litigation
Indeed, in 2006, a 61-year old Indiana retiree and minor software developer named Daniel Wallace took on the role of “canary in the coal mine” for SCO and other anti-FOSS groups by making a (pro se) legal stab at the GPL on Sherman Act anti-competitive grounds. Whether he received any financial support for his Don Quixote-like assault on the FOSS movement from other software makers is unclear; however, he advanced many of the same theories articulated by the SCO Group.
In one of his pro se lawsuits filed in the federal district court of Indiana, Wallace made the claim that IBM, Red Hat and Novell had violated antitrust laws by collaborating to market and distribute open-source software for free. Echoing an argument made by SCO that the GPL is anti-competitive, Wallace argued that "[i]f these companies combine all of their resources to target certain markets [with a free product], it removes any entrepreneur from competing in that market," Wallace says. "I view it as a conspiracy." In his second suit, Wallace sued the Free Software Foundation for their "’predatory price fixing agreement [with the parties named in his first suit] . . . to pool and cross license . . . intellectual property with others’ known as the GNU General Public License ("GPL").”
Wallace’s legal foray was firmly repulsed by the Seventh Circuit. Judge Easterbrook, writing for the unanimous panel, upheld the GPL in the face of these anticompetitive attacks:
Although the antitrust laws forbid conspiracies "in restraint of trade," 15 U.S.C. § 1, § 26, the GPL does not restrain trade. It is a cooperative agreement that facilitates production of new derivative works, and agreements that yield new products that would not arise through unilateral action are lawful…. Nor does it help to call the GPL "price fixing"…. Copyright and patent laws give authors a right to charge more, so that they can recover their fixed costs (and thus promote innovation), but they do not require authors to charge more. No more does antitrust law require higher prices.
The only “bone” the opinion threw at those that would attack the GPL and FSF on anti-trust grounds was the possibility that, should Linux (in particular) gain such a commanding market share that it truly was impossible for others operating systems to compete against it, “that evaluation under the Rule of Reason could lead to condemnation” of such a GPL-fostered circumstance on anti-competitive grounds.
5. Caught in the Middle: IBM, RedHat, Novell and Other Commercial Firms
The final players are commercial firms that have made distributions of FOSS part of their business strategy. Collectively, they have been the subject of suits by both Wallace and SCO in their role as deep-pocketed proxies for the open source movement. Whether motivated purely by the opportunity to profit from services ancillary to FOSS or, in greater or lesser part, as a strategic move to counter Microsoft’s growing dominance in the commercial software world, several important firms, including IBM, HP, Sun Microsystems and Novell, have staked much of their prestige—and business strategies—on distributing Linux and providing services surrounding that operating system. So far, the risk these companies have taken in backing Linux has paid off.
The growth of FOSS—and Linux in particular—has led to a significant installation & support industry to provide services for FOSS, giving these companies a serious financial incentive to popularize FOSS adoption. This service sector revenue stream has become integral to the business strategies of numerous big players, especially Red Hat, IBM and Novell. Linux-related service revenues alone are expected to account for a $37 billion market by 2008, with the lion’s share going to these companies.
In the face of pressure from SCO and the resulting fear, uncertainty and doubt (FUD being the preferred acronym for this syndrome among the FOSS community) among potential customers wary of adopting FOSS for enterprise-critical applications in the face of potential liability for patent infringement, Novell, Hewlett-Packard, RedHat, JBoss, and Sun Microsystems were all offering protection or indemnification programs to shield customers from legal threats arising from the use of Linux by the beginning of 2004. With persistent pressure, however, in 2006 Microsoft was able to peel off one significant member of this group: Novell.
The Novell/Microsoft pact rocked the FOSS world. In the November 2006 agreement, the two companies agreed to collaborate on software interoperability issues such as making Novell’s version of Linux, called SuSe, work as a “guest” on Windows-based servers and vice-versa. The far more contentious aspect of the pact, however, was an agreement for Novell and Microsoft to cross-license each other’s patents, and, in exchange for a royalty paid to Microsoft for each distribution of SuSe Linux (or a minimum of $40 million through 2011), for Microsoft to covenant not to sue Novell or its customers for patent infringement. While that latter pact was in the context of a reciprocal agreement not to sue for patent infringement and includes the possibility of licensing revenue flowing from Microsoft to Novell for use of Novell’s patents, and even though Microsoft has stated publicly that its patent strategy is focused on cross-licensing deals rather than on patent infringement litigation, the deal sent shock waves through the open source community. The general feeling was best summed up by Groklaw’s headline on a post the same day: “Novell Sells Out.” With the stage so set as to the conflicts encircling the GPL, the remainder of this paper attempts to elucidate some of the conflicts within the celebrated document and its newest proposed revision.
II. CONTRACT OR COPYRIGHT LICENSE: THE PERSISTENT ISSUE
As it has grown in potential importance concomitant with the widespread adoption of software governed by it, the GPL’s legitimacy as both a copyright license and as contract has been much debated among observers ranging from FOSS-enthusiast bloggers to legal scholars. However, the issue of legitimacy is becoming largely an academic discussion, since companies are treating it as an enforceable legal obligation, and even the recent Microsoft/Novell agreement shows that there is sufficient respect for the GPL that those companies took pains to avoid its prohibitions. And, in the few cases where the GPL has come up in litigation in the United States or abroad, courts have, thus far, found the GPL enforceable. While it is becoming widely accepted that the GPL is both legitimate and enforceable, exactly how it is enforceable is less clear. Though very few argue the GPL is unenforceable as a copyright license, many still take issue with its enforceability under contract law.
There is a strong argument to be made that the GPL is, in many cases, a copyright license supplemented by contract terms. Under the common law of contracts, one can argue that the GPL itself constitutes an offer; any copying, modifying, or distribution of a GPL-covered work by a would-be licensee constitutes implied acceptance of that offer; the licensee's consideration is an implied promise to abide by the GPL's terms; and the licensor's consideration is provision of the software itself. But, in any case, even in those situations where there is no contract (due to formation problems such as lack of notice of terms, etc.), it is fairly clear that the GPL is still effective in controlling downstream behavior through copyright law—at a minimum those behaviors that implicate the exclusive rights of distribution, reproduction and preparation of derivative works. Thus, while the GPL is almost certainly effective in some form, the clarity of its terms remains a problem, however, and the remedies for its breach are still ill-defined.
A major issue for non-FOSS software makers, and an additional threat the GPL poses to them (besides just loss of market share), is that GPL’d code will inadvertently (at least from the perspective of management) make its way into their proprietary software and they will be sued under the GPL. To illustrate the issue, one author postulates the following scenario:
[A] software company finds some source code that is in the public domain. They spend years modifying the code and create a new and improved application. The company then seals up the code and sells it to the public for a substantial profit. Tweak the scenario and the difference is drastic: the software company instead acquires some source code covered by the GPL. They create the same ingenious new application and sell to the public without releasing the source code. The creator of the original code licensed under the GPL sues the company for violating the license agreement, seeks damages, and releases the new and improved source code to the public. The legal ramifications of mistaking open source code for code in the public domain could not be more severe for any software developer.
There is more than one problem with this scenario author’s envisaged outcome. First, the creator of the original GPL’d code could neither unilaterally obtain nor release the offending code—it would have to be based on a court order. And, while this outcome—the court ordering compliance with GPL terms and forcing the offending company to release its source code to the public—is theoretically possible under either copyright or contract law, in practice a court would essentially have to find that a contract existed before it would make such an order.
Of course, copyright infringement carries severe penalties of its own for a proprietary software seller in the scenario above. The remedies available under copyright law include enjoining the software maker from selling the software as-is due to its inclusion of infringing code as well as actual or (substantial) statutory damages, attorney’s fees and costs. Even if the specific performance remedy is unavailable to an upstream copyright holder, there are plenty of remedies available under the Copyright Act by itself that scare proprietary software sellers. However, since specific performance a la the scenario above is the “gold standard” of remedies for the FOSS movement, it is worth investigating the plausibility of that outcome.
A. The Drafters’ Intent
The Free Software Foundation has long presented the GPL as a copyright license, but left its position on its contract aspects ambiguous—probably purposefully. The GPL’s legitimacy as a license is rather clear. Thought it does seem strange to allow copyright law to be used to virtually abrogate the protections of copyright, it is consistent with the meaning of the word “license.” According to Black’s Law Dictionary, a license is:
A permission, usu. revocable, to commit some act that would otherwise be unlawful; esp., an agreement (not amounting to a lease or profit à prendre) that it is lawful for the licensee to enter the licensor’s land to do some act that would otherwise be illegal, such as hunting game.
Viewed in this way, the GPL varies only from the standard definition of a license in that it is irrevocable by the grantor (by its own terms) so long as the terms of the license are followed; though, as noted, revocability is not an absolute requirement for a license. Additionally, the affirmative requirements many of the GPL’s terms place on the licensee (such as providing modified source code) does not make it less enforceable, except to the extent that a licensee is unaware of the terms. Professor Nimmer teaches that a copyright owner may subject a work’s use to such restrictions in the hands of a remote assignee, so long as the assignee had actual or constructive knowledge of such a covenant.
The GPL’s terms principally focus on its role as a copyright license. In the language of the current draft, if you want to copy, modify or distribute GPL-covered software, you can only do so pursuant to the license:
You are not required to accept this License in order to receive or run a copy of the Program….However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.
Yet, even as it emphasizes the copyright license aspect, this section retains some ambiguity by referring to “acceptance”—an unnecessary condition for license enforceability under copyright law since violations of exclusive rights result in infringement even if license terms were never “accepted” by the violating party. However, as will be discussed below, such acceptance is probably necessary for a court to find a violation of other covenants within the GPL.
Perhaps to address much of the academic writing on the topic and to clarify its own position, the FSF weighed in on the issue in the GPLv3’s first discussion draft by explicitly indicating that the GPL was “Not a Contract;” however, it has since moved back towards its earlier, less definite stance on the issue. Successive GPLv3 drafts have withdrawn from that unambiguous statement, apparently reflecting a tactical decision to retain the prior ambiguity and, with it, maintain at least the possibility of contract damages (and remedies) in any future GPL violation cases. GPLv3 § 9, the section previously titled “Not a Contract” in the first discussion draft, has been re-titled “Acceptance Not Required for Having Copies.”
This is probably just good lawyering on the part of the FSF’s legal counsel. While in some cases courts may not find the GPL was a contract, it would seem folly to shoot one’s self in the foot and explicitly disclaim contract remedies should the remaining elements required to find a contract be present in a given case. Furthermore, retaining the ambiguity on the contract issue does not make the copyright license any less effective, so, on balance, leaving open the possibility of contract remedies seems to only make the GPL more effective overall.
So does it even matter if the GPL is just a license, rather than a contract too? Perhaps. One reason is that it is relatively clear that if both copyright infringement and copyright claims are available to a claimant, the aggrieved copyright owner does not have to elect one theory/remedy over the other when bringing suit. The Eighth Circuit’s decision in National Car Rental Systems v. Computer Associates is representative of the majority view that breach of a license agreement containing a promise over and above the exclusive rights the Copyright Act grants a copyright holder is not pure copyright infringement but rather something “extra,” and thus, the (state common-law) contract claim is not preempted by the Copyright Act.
But the mere fact that a breach of GPL terms may well wind up being subject to claims under both the Copyright Act and contract law does not necessarily mean that the worst-case remedies—such as specific performance, windfall statutory damages, or injunction—are a likely result of inadvertent inclusion of GPL’d code in a commercial product. After exploring each of the available remedies created by the Copyright Act or the common law of contracts, one concludes that commercial companies worried about truly “innocent” infringement of GPL terms probably have little reason for concern, but the issue of intent (to include GPL’d code) is likely to be a critical issue—if not the critical issue—in determining the appropriate remedies for a GPL infringement case.
1. A Typical Scenario
Infringing code just doesn’t magically make its way into software, of course, so the “inadvertent” inclusion hypothetical needs to be clarified. Because international copyright protections automatically attach to expressive works without any registration formalities, programmers should assume that any code they happen upon is copyrighted work absent a clear dedication to the public domain. Thus, perhaps a more realistic scenario to consider than the absolutely “accidental” inclusion postulated above is one where a proprietary software firm, at the management or entity level, is unaware that it has included any infringing code in a new software product; however, one of its employees has either intentionally copied GPL’d code (perhaps out of laziness) or negligently assumed the code was in the public domain (or under a more permissive OSS license like the BSD) and failed to discover it was actually GPL’d code.
Under pure contract law, the proprietary firm is likely off the hook due to agency rules. Unless the programmer had agency authority—either implied, actual or ratified—to enter into a contract governed by GPL terms with an upstream programmer, the programmer’s employer will not be bound on the contract. Admittedly, some lower-level employees routinely bind their companies to license agreements, such as technical support personnel that agree to End User License Agreements (EULAs) when they install software on company computers, but those employees have actual or implied authority to enter into such agreements on behalf of their company. In contrast, a programmer in this scenario will not have ex ante authority to enter into GPL agreements on behalf of her company. Thus, absent a showing of agency authority on the part of our wayward programmer, perhaps by demonstrating that the employer discovered her action and ratified it, the company would not be liable under contract theory, and this would knock out the possibility of obtaining contract remedies – though, as we will see, this doesn’t make much difference since copyright law offers virtually identical remedies as those available under contract law.
In terms of enforceability, copyright law is less forgiving than contract—at least on its face. Like tort law, copyright recognizes the doctrine of respondeat superior, which makes an employer liable for the acts of its employee when done within the scope of employment. Because copyright infringement is a strict liability offense and “unintentional infringement” is only a partial defense that goes to the issue of damages, rather than the issue of liability, it is not necessary for a court to impute an employee’s “intentional infringement” to her employer. Since, however, as we will see, the only remedy available in such a suit that will significantly harm a proprietary software firm—injunctive relief—is within courts’ equity powers to determine, it is likely that the behavior of the infringing company at the entity level will be important. If the defendant company is actually an unknowing or inadvertent infringer at the entity/management level, this could prompt a court to find that the equities of the situation do not warrant any form of injunctive relief and find the company liable only for minimal monetary damages. Such a company likely has little to fear from a GPL violation suit.
2. Specific Performance/Mandatory Injunction
While agency principles seemingly knocked out the contract law remedy of specific performance as a potential outcome of a GPL violation suit (since an inadvertently infringing company would likely not be found liable under contract law), copyright law provides a virtually identical remedy in the form of a mandatory (or positive) injunction—at least theoretically. Though infrequently used in a copyright infringement setting when contrasted to its better known sibling, the prohibitory (or negative) injunction (where a court commands a party not to do something it planned to do), a mandatory injunction could be used by a court to command an infringing proprietary software company to release its source code in accordance with the GPL, rather than just enjoin it from further distributing its proprietary software containing infringing code.
This outcome is extremely unlikely in the case of the inadvertently infringing company, however, because a court would essentially have to find that there had been a contract between the parties to support enforcement of such positive terms in the license by way of a mandatory injunction. There is a difference between limiting terms and contractual covenants included in a license, and a court would likely find that the section of the GPL that commands a distributor of GPL-covered work in object code form to make the corresponding source code available is a covenant, rather than a limit on the license, in which case contractual formalities would have to be established (and lack of agency authority would remain a defense) before the term could be enforced. While the FSF labels the duty to release corresponding source code as a license term, terms that do not implicate exclusive rights granted by the Copyright Act, but rather go beyond and require some other conduct by the licensee, are labeled as “covenants” under copyright law. This is not to say that covenants are unenforceable—a copyright owner may, by inclusion of covenants in the license, subject a remote assignee to conditions under which the license may be exercised. However, critically, the assignee is only bound on these covenants if she had actual or constructive knowledge of them. This would imply that a copyright suit based on failure to distribute corresponding source code as the GPL requires would place a burden on the plaintiff to show that the defendant knew or should have known of the requirement. Additionally, all cases Professor Nimmer uses to illustrate the use of mandatory injunctions in copyright infringement suits have included a clear ex ante contractual relationship between the plaintiff and defendant. Taken together, this leads one to the conclusion that a mandatory injunction forcing distribution of source code in a GPL violation suit is only likely when the plaintiff can show that the defendant knowingly violated the terms of the GPL—in which case the plaintiff would also have a potential breach of contract claim as well. Because an enforceable contract is going to be lacking in an inadvertent infringement case, it is probably safe to rule out this form of relief in such circumstances.
3. Statutory Damages
Statutory damages are also unlikely to be significant issue in the GPL context—whether infringement was intentional or innocent. While the Copyright Act provides for significant statutory damages of up to $150,000 for each occurrence of infringement, the very availability of statutory damages is contingent on the copyright owner showing that he had registered the copyrighted work within 3 months after the code was first “published” or, if not, then prior to an infringement of the work. Otherwise, only an award of actual damages and lost profits is available to the copyright owner.
While data is hard to come by, perusal of open source discussion web sites yields virtually no discussion of prophylactic copyright registration among FOSS developers that could qualify them to later assert statutory damages. In a discussion thread of a potential GPL breach by Sony (as part of its 2005 music compact disc digital rights management (DRM) fiasco), one self-identified lawyer/programmer posting to the blog noted that, while any upstream software developer could sue Sony for copyright infringement under the GPL, “[i]n all likelihood, the developers did not obtain copyright registrations for the code prior to the infringement.” Based on the lack of discussion about the topic and the generally lawyer-unfriendly atmosphere present in the FOSS community, it seems a safe assumption that the vast majority of code additions made to GPL works go unregistered with the Copyright Office.
If a GPL-covered addition to an FOSS work were registered, a proprietary software firm that inadvertently wound up with GPL-covered code in its program could face a significant statutory damages judgment—but that is a big “if.” For one, statutory damages are not calculated on the number of redistributions, but on the number of copied discrete works; thus, even if Microsoft distributed Windows Vista to millions of customers with three GPL-covered programs contained among the thousands of programs that make up the Vista operating system, it would be liable only for three discrete violations, and statutory damages would be calculated thereon, rather than on the millions of infringing distributions. Secondly, where the infringing party sustains the burden of proving—and the court so finds—that the infringer was not aware of and had no reason to believe that its acts constituted a copyright infringement, a court has discretion to reduce the award of statutory damages to a mere $200 per offending work. Thus, this is another instance where the behavior (or subjective intent) of the infringing software company at the management/entity will matter in determining the remedies available to a plaintiff.
4. Actual Damages, Profits & Negative Injunction
FOSS’ non-remunerative nature makes it extremely unlikely that a court could find substantial actual damages for a GPL plaintiff; it also makes it unlikely that a court would award an injunction against any but the most egregious/intentional GPL code infringer. Actual damages are, almost by definition, going to be minimal under the GPL. While the GPL theoretically allows a distributor to charge for copies, after having distributed the first copy of the code under the GPL, the distributor has given all others irrevocable permission to make an infinite number of further copies. Because a distributor in such a situation has no justifiable expectation of obtaining revenue from copies after the first distribution, actual damages from downstream infringing conduct could be only de minimis, at best.
And, while a negative injunction was seen as almost a default remedy for IP infringement until the very recent past, the Supreme Court’s decision in EBay v. MercExchange —that cases of patent infringement are not automatically “special” cases for injunctive relief, and that this remedy must still be justified under the traditional four-part test—is making the assumption that such relief will be readily available look far less certain. While EBay’s precise holding is limited to the Patent Act, Justice Thomas, writing for the unanimous court, indicated that the holding almost certainly applies with equal force in the copyright arena:
Like the Patent Act, the Copyright Act provides that courts “may” grant injunctive relief “on such terms as it may deem reasonable to prevent or restrain infringement of a copyright.” 17 U. S. C. §502(a). And as in our decision today, this Court has consistently rejected invitations to replace traditional equitable considerations with a rule that an injunction automatically follows a determination that a copyright has been infringed.
Thus, it seems a good bet at this point that a court will apply the same four-part test described in EBay to any future copyright infringement case seeking permanent injunctive relief. Under the four part test:
A plaintiff must demonstrate: (1) that it has suffered an irreparable injury; (2) that remedies available at law, such as monetary damages, are inadequate to compensate for that injury; (3) that, considering the balance of hardships between the plaintiff and defendant, a remedy in equity is warranted; and (4) that the public interest would not be disserved by a permanent injunction.
Under this standard, a GPL-violation plaintiff will likely have a difficult time meeting the burden to secure a permanent injunction. While factor two would seem to cut for a GPL plaintiff, considering the lack of actual damages that are likely, courts will almost certainly find that factor one cuts decisively against GPL plaintiffs’ cases. This is all the more so since U.S. copyright law is so economically focused and accords such little weight to an author’s moral rights. Since the GPL licensor clearly was not motivated by direct economic gain since he gave his copies away freely from the beginning, any arguments that the infringing party has harmed the software developer by “locking up” his code and violating its “freedoms” will likely fall on deaf ears.
Weighing of the last two factors—and ultimately the key to resolving the question—depends heavily on the infringer’s behavior. If the infringing company is the victim of a careless or dishonest employee and was otherwise neither negligent nor culpable in causing the infringing code to find its way into the company’s proprietary program, it is very likely that a court will decline to enjoin further sale of the work—particularly if the infringing code constitutes a very small portion of the delivered program.
Instead, a court will likely find that an award a share of the profits from the software to the offended party is the most equitable remedy. By any measure, this should not be a disastrous outcome for a proprietary firm, and could be relatively small. Revisiting the Vista example used before, if infringing programs constituted 0.5% of the programs included in the operating system, a court would likely force Microsoft to pay that amount of its profit to the upstream GPL software developers. Those GPL programmers may strongly prefer injunctive relief in order to force Microsoft to withdraw its product from the market. However, assuming Microsoft—at the management & entity level—had no idea of the infringement before shipment of the ultimate product, a court would likely find injunctive relief both wasteful and not in the public interest and decide that forcing Microsoft to “disgorge” 0.5% of its profits to the copyright holders would more than adequately redress the harms involved.
While this article has mostly addressed the problem of “inadvertent” inclusion of GPL-covered code in proprietary software, it should be clear that a company that intentionally/knowingly includes GPL-covered code in its proprietary software risks the entire range of remedies available under both contract and copyright law. Even if the inclusion is initially made by an employee (i.e., programmer) with no inherent agency authority, a company that ratifies such an employee’s behavior by distributing GPL-covered code in a proprietary product may be found to have ratified the employee’s behavior and, with it, the contract defined by GPL terms. In such a case, specific performance/mandatory injunctive enforcement of the GPL’s source code distribution term would be available to a court as an equitable remedy and, again, due to the lack of other effective remedies under copyright law (again, assuming statutory damages are unavailable due to non-registration), a court may find itself faced with essentially only three realistic available remedies: 1) Specific Performance/Mandatory Injunction to Release Corresponding Source Code, 2) Negative Injunction Enjoining Further Sale (pending removal of offending code), and/or 3) Awarding a Share of Profits. Of these, the first would be the most likely to punish the bad actor and deter such conduct in the future, so it is very likely that an intentionally infringing company could face this remedy, even if it only found out about and ratified its employee’s conduct at a late stage.
Top of Page