Legal Uncertainty in Free and Open Source Software and the Political Response

From The Politics of Open Source Adoption
Jump to: navigation, search

Jennifer M. Urban



By the mid-1990s, the concept of free and open source software was well established in the information technology industry. The development of Linux and other major projects was well underway, and the legal struggle over ownership of the UNIX code base and its Berkeley derivatives had drawn to a close. Most software licensing lawyers, however, maintained a professional distance from F/OSS licenses and licensing issues. For the average licensing attorney, the concept of generously granting rights, rather than heavily restricting and controlling them, was simply headache-inducing. F/OSS licenses lacked a number of the basic characteristics of proprietary licenses, such as standard legal drafting style and “privity” (a clear relationships between the contracting parties); they existed alongside a perceived lack of control, within F/OSS projects, over the origins of contributions to the code base; they incorporated new ideas like “copyleft,” which placed novel restrictions on subsequent development and commercialization.

Lawyers also had trouble weighing and valuing the role that licenses play within the F/OSS community. F/OSS licenses not only define terms of use, but can structure the projects themselves by defining the roles and responsibilities of the contributors. As a consequence, some in the F/OSS community tend to view these licenses as social compacts in addition to legal documents, directed at project participants as well as commercial adopters or competitors. Some of the important F/OSS licenses—notably the GNU General Public License, which is widely seen to bundle a manifesto with an unorthodox software license—emphasize this constitutional function as much as they define and regulate F/OSS within a complex and litigious software marketplace. Moreover, F/OSS development processes by their very open nature, are seen to incorporate problems that in commercial situations would lead to stricter licensing and contractual definitions. As F/OSS projects began to compete with commercial software, they entered a commercial arena where these legal definitions mattered a great deal.

It is in this context that software attorneys began to be genuinely concerned about the legal issues surrounding F/OSS licenses. At the very least, the informal drafting of the most common licenses made it difficult for lawyers to advise their clients about the legal risks associated with licensing F/OSS. The traditional (and important) lack of warranties and indemnification under F/OSS licenses made it difficult to assess the extent of those risks. Among software attorneys, especially, the perception of higher risk was—and arguably still is—widely shared. Yet the adoption of F/OSS has increased and is accelerating. By January 2004, 14 per cent of U.S. companies had deployed Linux—a 66 per cent increase from 2002 (Schadler, 2004). By 2008, Linux is projected to represent nearly 38 per cent of the market for server sales (MacKinnon, 2004). Apache web servers, licensed under the open source Apache Software License, represented two-thirds of the web server market as of May, 2004 (Miller, 2004). Mozilla’s new open source browser, Firefox, surpassed 16 million downloads within a month and a half of its launch. Google runs on a massive Linux server farm. Licensing lawyers now attend professional education programs to get up to speed on F/OSS advising.

Why this acceptance of risk? While there is clearly professional bias toward traditional licensing arrangements and hypersensitivity toward FUD (fear, uncertainty, and doubt), legal uncertainties about F/OSS are genuine. Recent cases have brought a few important legal issues related to F/OSS before the courts, although very little has been resolved to date. Pushback against F/OSS by proprietary software providers routinely highlights these risks. It is not clear, however, whether recent attempts to slow F/OSS adoption by highlighting legal risks have had any effect, and there is some reason for thinking they have backfired. A number of organizations beyond the F/OSS community, including traditional businesses, governments, and non-profits, have extensive interests in the viability and widespread adoption of F/OSS, and have entered the debate in consequential ways. The F/OSS community itself—comprising commercial and noncommercial developers, hackers, advocates and others—has countered criticism and legal threats with an increasingly well-coordinated information campaign, publishing a stream of commentary, analysis and legal arguments. It has also undertaken collective efforts to identify and replace vulnerable code in major F/OSS releases.

This chapter sketches the major legal uncertainties surrounding F/OSS, some of the efforts to de-legitimize F/OSS or capture its growing value, and finally the nature of the F/OSS community response, which has coalesced into an effective though still-limited political strategy. The primary case study is SCO v. IBM—the high profile infringement case brought against corporate GNU Linux users—and the surrounding public relations campaign aimed at undermining public confidence in the legality of GPL-licensed software.

Sources of Legal Uncertainty for F/OSS Licenses

Legal concerns associated with F/OSS licenses traditionally have fallen into two broad categories:

  • code ownership (or intellectual property) issues; and
  • license enforcement issues (both copyright license and contract).

These concerns tend to affect both licensees and licensors—in large part because, in the F/OSS model, the former often become the latter. The shape of the concerns varies, however, according to those differences in position. I will visit these concerns only briefly here, as they have been discussed in a variety of sources[1]. As with all intellectual property issues in the global marketplace, the issues are made more complex by the international nature of F/OSS projects. Intellectual property and licensing laws vary widely worldwide; of particular note is the variation in patent protection for computer programs—robust in the U.S. but heatedly debated in Europe. For simplicity’s sake, this report mainly concerns itself with United States law, but it is only a piece of the whole.

F/OSS licensing models can seem counterintuitive because they exploit intellectual property laws that were designed to empower IP owners to exclude other people from making copies or derivatives of the software. While proprietary licenses control what the licensee can do with the software (especially the draconian EULAs most consumers encounter when they purchase software), F/OSS licenses use the licensor’s IP rights to allow and encourage copying and modifying by anyone, without licensing fees. This is not to say that F/OSS licenses abandon IP rights—quite the opposite. A license such as the GPL depends upon a very robust interpretation of the scope of copyright. But because business managers and IP lawyers generally think of IP as protecting a ‘profit center’ product and because legal case law, statutes and “standard” drafting practice have developed around protectionist non-F/OSS licenses, uncertainty exists about the scope and enforceability of F/OSS license provisions. Further, because the F/OSS development model is often highly decentralized, there are uncertainties about the ownership of F/OSS code[2].

Code: Ownership and Control

Intellectual property law offers developers a number of ways of establishing exclusive rights or protections for their work. Copyright is a primary mechanism. Writing software code is legally characterized as an “expressive” or “creative” act analogous to other forms of authorship, and thereby benefits from copyright’s restrictions on unauthorized copying and derivative use. Patents offer a parallel structure of protection, applicable not to the code itself, but to the underlying ideas and methods. Software patents, valid for 20 years, are recognized in the U.S. but remain controversial elsewhere (e.g., in Europe where a state-harmonizing software patent directive was narrowly defeated in the E.C. in 2004). Although patents provide stronger levels of protection, with fewer limitations on rights, copyrights last a great deal longer: 95 or 120 years for an institutional copyright holder and life plus 70 years for an individual[3].

Other mechanisms and secondary rights also shape the ownership of software. Trade secret law—a legal structure for protecting and regulating industrial secrets—offers one strategy. Performance and exhibition rights—a subcategory of copyright that governs the right to perform or display works—are another, applicable because of the ways in which computer code mediates users’ experience of a creative work. (Video games are a prominent example.)[4] Trademark is still another, relevant not only to branding exercises, but, in the F/OSS context, to indicate the source of the code and to ensure the main stakeholders of projects retain some control over the use of key identifying terms[5].

F/OSS licenses rely on combinations of these rights and on contract law to ensure that licensees can modify and use the code broadly. Given the complexity of these overlapping mechanisms, it is often difficult to tell which protections are being invoked. The GPL drafters argue, for instance, that the GPL constitutes a “bare license” that does not rely on contract law to enforce its provisions. In practice, the alignment of these rights makes it simpler to assert excludability than to define the legal bases of open access.

In the F/OSS context, concerns about IP ownership arise for two related reasons: (1) the large number of contributors who add to the code base; (2) the perceived lack of any practical means of verifying the sources of their work. In theory, each contributor owns the copyright to her contribution and licenses it (via a F/OSS license) back into the project. This means that for large projects, many different contributors hold copyrights to pieces of the code. For IP lawyers and F/OSS advocates, this creates a basic problem: who enforces these copyrights if they are infringed (for example, if GPL-licensed code is released under a proprietary license)? Open code and the often-limited financial resources of F/OSS projects create an asymmetry in the effective capacity to defend copyrights. Because proprietary code is, by definition, closed to scrutiny, it is difficult for F/OSS projects to prove infringement of their work. Because F/OSS code is, by definition, open, proprietary vendors can search the code for possible infringement. (That same openness, however, also makes it easier for the F/OSS community to police the code base and excise questionable material, at least in theory.) Moreover, U.S. copyright law requires that copyrights be registered before a party can bring an infringement action. In cases where F/OSS projects do not keep meticulous track of the licensed contributions, it may be impossible to identify the copyright holders. Under these circumstances, it would likely be extremely challenging for F/OSS projects to defend their code. The Free Software Foundation approaches this problem by requiring a copyright assignment from anyone who contributes to the code base for its projects. This provides the FSF more leverage in defending its code, and it has exercised this prerogative on several occasions by threatening lawsuits[6].

Complications can arise when developers contribute code for which they hold no rights, as is often the case in work-for-hire situations. Not only does the contributed code constitute possible infringement problems, but code derived from such work may also infringe. Because of this lack of control over the origins of individual contributions, F/OSS licenses do not provide warranties[7] or indemnities to licensees. This structural uncertainty has already been exploited by The SCO Group in its cases against some Linux end-users and in its demands for licenses from 1500 large companies[8].

Ownership concerns are exacerbated in the context of software patents, as controlling contributions to the code base is not necessarily enough to escape liability. Patents provide very strong rights, and protect entire methods of accomplishing a task. Guarding against patent infringement means not only knowing ones own code base, but also knowing if any applicable patents exist. This is not an easy or inexpensive task[9], and the F/OSS community rightly considers patents a substantial risk to F/OSS. Patents are a serious issue for all software projects, including proprietary projects, and the resulting uncertainty taints software generally. However, the same dynamics of openness and limited resources put F/OSS at an even greater structural disadvantage with respect to patents. Potential plaintiffs (whether legitimate or ‘trolls’) can search F/OSS code for infringement. F/OSS projects, on the other hand, have been reluctant to enter the patent game—although some F/OSS advocates have explored defensive uses of patents[10].

License Enforcement and Interpretation Issues

To date, F/OSS licenses have not been widely tested in the courts. The recent Sitecom case, in which a German court upheld the GPL, is the first significant example. Here, the lack of precise legal language in many of the common licenses (for example, the GPL and the BSD variants) and questions regarding enforceability of their provisions, create uncertainty about their enforceability and how they should be interpreted. The lack of clear assent to the license terms by the licensee is one such challenge. The GPL and BSD family of licenses are simply “included” with the software, sometimes in the notes to the code, sometimes separately. The Free Software Foundation, especially, has been creative in its arguments on this point, but it is unclear whether a court would review the GPL under contract law, which has strict requirements of notice and evidence of agreement by both parties[11]. The wording of F/OSS license provisions can also cause confusion; for example F/OSS licenses often grant a right to “modify” the code. Most F/OSS developers and advocates understand this to include the right to create derivative works, but not all modifications rise to the level of a derivative work under copyright law—traditional license provisions track words directly from the IP statutes, avoiding this uncertainty. There is further uncertainty about the overall status of the licenses: are they copyright licenses, patent licenses, or both? As the definitions and commercial functions of F/OSS concerns are explored by courts, these distinctions become increasingly important. A growing number of F/OSS licenses do reflect closer attention to legal conventions. For example, the widely-used Mozilla Public License is very tightly drafted, making challenges to the enforceability of its language and interpretation issues less likely. As such, the MPL has influenced a number of corporate-sponsored F/OSS licenses. The forthcoming GPL 3—a revision of the GPL—is also likely to address some of these issues, especially regarding patents. Finally, the constant proliferation of license types exacerbates these interpretation challenges. Despite F/OSS community efforts to reign in this tendency, the Open Source Initiative (OSI) has approved over 50 licenses as of this writing[12].

Yet plain language is important, particularly for F/OSS licenses which also play the role of social contracts among contributors. Traditionally-drafted licenses, such as Microsoft’s EULAs, are generally daunting for the non-lawyer; this is also true of some professionally-drafted corporate F/OSS licenses. In the bottom-up F/OSS development system, this can create uncertainty for contributors and adopters rather than reduce it, especially when the goal is to expand F/OSS communities. The Creative Commons licenses provide one method of addressing this conundrum by combining professionally drafted licenses with a plain language file that lets non-lawyers know at a glance what the license means[13]. Similarly, the Free Software Foundation’s website provides a great deal of information intended to help GPL users understand what is intended by its terms[14]. In the end, however, enforcing a license might require going to a court, which will make decisions based on standard conventions and previous case law rather than what the license drafter says she intended. In addition, while the FSF is likely to enforce the GPL according to its interpretation, other licensors who have used the GPL might take a different tack. Legal uncertainty, then, remains.

The Effect of Political and Economic Interests in F/OSS

Although courts have yet to weigh in, a number of organizations have extensive interests in the viability and widespread adoption of free and open source software. Among these are large IT businesses that contribute to the code base and use the licenses for their own releases, such as IBM and Sun Microsystems; other large businesses, such as Merrill Lynch, that in-license F/OSS (that is, use F/OSS but do not redistribute it); and a wide variety of states, public agencies, and non-profits[15]. Legal uncertainty is a definite concern for these actors, as the city of Munich demonstrated by (temporarily) halting its city-wide F/OSS migration because of concerns about emerging EU software patent law[16]. Other organizations, most notably Microsoft, have taken active steps to highlight the liability risks of F/OSS. Absent relevant court verdicts, this is mostly a campaign of vague threats, with dubious results[17]. In November, 2004, for example, Microsoft’s CEO stated publicly that organizations using Linux might be at risk of intellectual property suits[18]. Yet in a 2001 internal study, Microsoft found that messaging campaigns against F/OSS that focused on legal issues were not effective tools for slowing Linux adoption[19]. Overall, the progress of F/OSS adoption indicates that legal uncertainty is not outweighing the perceived advantages of price and customizability.

Members of the F/OSS community have obvious (though often individually economically small) stakes in the debate. From Richard Stallman to Eric Raymond to Bruce Perens to the less-well-known hundreds-of-thousands of individual F/OSS enthusiasts, the F/OSS community has effectively leveraged the platform of the Internet to test criticism of F/OSS and to define the debate. While these actors are (for the most part) not lawyers, they have become well-versed in the legal issues, and have exhaustively and eloquently dissected threats to the F/OSS model. While the effects of their work cannot be quantitatively measured, and while their opinions may or may not hold sway with courts, their influence on the perception of legal uncertainty in and around the F/OSS community and on the capacity of diverse F/OSS actors to defend those arguments has been substantial. Certainly, members of the community feel that their efforts have paid off with regard to Microsoft’s anti-F/OSS rhetoric[20].

The F/OSS community provides extensive commentary on each of the issues described above. The Free Software Foundation’s website provides not only detailed information about the intended meaning of the GNU GPL, but also interpretation of the larger political and social dynamics affecting F/OSS adoption, such as the observation that licensees rarely have an incentive to claim to a court that the GPL is unenforceable because it would deprive them of their right to use the software. The FSF also documents different licenses’ compatibility with the GPL. Because both licensees and potential licensors often look to Richard Stallman, Eben Moglen and the FSF to explain the GNU GPL and criticisms of it, this may be a more effective method of reducing uncertainty than it seems at first glance. Licenses, after all, attempt to regulate behavior. If everyone involved follows an interpretation understood by all to be the proper one, courts will enter the picture only rarely.

OSI also provides detailed online information about open source licenses and the risks of open source adoption. More assertively, OSI uses its trademark on the term “open source” to police what can and cannot be called an “open source license.” This control over semantic borders provides considerable leverage in maintaining the coherence and—to some extent—the legal integrity of a wide range of open source projects.

Increasingly, governments (particularly municipal governments and governments of developing countries) have weighed in in favor of F/OSS adoption. Famously, a Peruvian congressman named Edgar Villanueva Nuñez wrote an eloquent letter in favor of a 2002 Peruvian bill to require the state to use F/OSS. Nuñez was responding to a Microsoft executive’s criticisms of the bill, and argued in part that F/OSS was the only way to ensure responsible use of public funds, permanence of public data, citizen access to public data, and security[21]. Since Nuñez’s letter, government adoption has only increased. Brazil’s President Luiz Inacio Lula da Silva has touted F/OSS as a way to train Brazilians to be technically proficient while avoiding “economically unsustainable” Microsoft licensing fees[22]. Numerous developing countries around the world have embraced or are exploring F/OSS to solve language localization problems and to create robust, economically sustainable platforms for their governments and citizens[23]. The wealthy European countries of France and Germany are also attracted to F/OSS, despite the challenges noted above (Hatlestad, 2004). The Los Angeles City Council, as of this writing, is discussing switching government systems to F/OSS to save money for hiring more police officers (Jardin, 2005).

The economic interests in sustaining the F/OSS development and licensing models, then, are substantial. Against this backdrop, a handful of recent legal disputes confront some of the uncertainty surrounding F/OSS licensing.

Current Cases

Several current disputes, most importantly the SCO Group cases, illustrate the dynamic between the legal uncertainties around F/OSS and the larger political struggles over F/OSS adoption.

Sitecom/Netfilter Case

The GPL received a boost in April, 2004 when a German court stopped Sitecom, a Dutch company, from distributing the code for netfilter/iptables, which is licensed under the GPL, without attaching the GPL license text or including the source code (Shankland, 2004). By enforcing the GPL against Sitecom, the German court became the first court to issue a published decision enforcing the GPL.

German courts have no precedential weight in the U.S., and little if any persuasive weight[24]. Moreover, the differences between U.S. common law and German civil law systems suggest caution in generalizing about the logic and impact of the case. Nonetheless, the Sitecom decision is a positive development for at least two reasons beyond its German context:

  • Because F/OSS is a truly international undertaking, the harmonization of legal interpretations of F/OSS is becoming increasingly important. Positive early precedents can have a disproportionate impact on the direction of this harmonization, and European precedents carry considerable weight in other national and international IP law.
  • U.S. courts notwithstanding, support for the GPL and other F/OSS licenses in the international community will help build F/OSS market share worldwide. Because F/OSS is a network good that grows in value with the number of users, U.S. courts may eventually be faced with a social and technological fait accompli, in which undermining F/OSS licenses would have unacceptable costs for the U.S. business community.

Mambo/Furthermore Dispute

Issues of code ownership have been at the center of the Mambo/Furthermore dispute. The president of Furthermore, Brian Connolly, claims that developers he hired to create code for his company illegally released it into the GPL-licensed Mambo code base. Some of this dispute has taken place in public on the respective company and project websites, including Furthermore’s initial cease-and-desist notice to Mambo and Mambo’s reply[25] Negotiations recently broke down, and Connolly has threatened to sue Mambo end-users (McKenzie, 2004). While this dispute may never advance beyond threats, the copyright ownership issues (particularly the work-made-for-hire issues stemming from the independent developers’ release of code into the Mambo code base) exemplify some of the larger F/OSS concerns with unattributable code. Further, the public nature of the dispute raises questions about political limitations of F/OSS preferred model of open discussion and resolution of issues.

The SCO Cases

In March of 2003, The SCO Group of Utah sued IBM for $1 billion (this grew to $5 billion[26] ), claiming that IBM had included SCO’s proprietary code in a Linux distribution[27]. Originally, SCO explicitly noted in its complaint that the suit was not about the relative merits of open source versus proprietary software[28]. In its press strategy, however, SCO clearly exploited uncertainty about the GPL and the Linux code base. By the time it filed its answer to IBM’s counterclaims, SCO was casting the GPL in an extremely dubious light, stating that it “violates the U.S. Constitution”[29](SCO later dropped this claim.) One month later (March, 2004), SCO sued two Linux end-users, AutoZone and DaimlerChrysler, claiming that their distributions of Linux infringed SCO copyrights. Because the GPL provides no warranties or indemnities for intellectual property infringement to licensees, SCO argued that Linux end users were the liable parties. Its press strategy was clearly intended to cast suspicion not only on IBM’s strategy for releasing code into the Linux project, but also to create concerns about liability among all Linux licensees (Shankland, 2003). SCO’s CEO compared the suits to the Recording Industry Association of America’s lawsuits against peer-to-peer users, stating, “It wasn't until the RIAA launched a series of lawsuits against end users that the end users became fully educated”[30] SCO’s Chris Sontag stated that it is “appropriate that we warn commercial companies that there are intellectual property issues with Linux.” (Shankland, May 14, 2004). SCO clearly views the lawsuit as a revenue source; it has sent demand letters to 1500 corporations, and offered licenses to Linux users for $1399 per single-processor server (Becker, Aug. 5 2003).

Competitor Reactions

Because the SCO cases involve the legality of a widely-deployed enterprise system, large companies have a stake in the outcome. IBM has chosen to defend against the multi-billion dollar suit, despite the mounting legal costs of discovery fights and preparation for trial. Explicitly charging that SCO was mounting a campaign of “innuendo and rumor” that threatened “the whole open-source community,” Red Hat (a Linux distributor) sued SCO for unfair competition and for a declaratory judgment that it was not infringing SCO’s copyrights or misappropriating SCO’s trade secrets (Shankland, Aug. 4, 2003). Red Hat has also established a fund, seeded with $1 million, to defend individual developers and non-profits against SCO[31]. Another fund, run by the Open Source Development Labs (a consortium which sponsors two Linux projects), has attracted funding from Intel, IBM, MontaVista Software Inc. and others, and has a goal of $10 million (Weiss, Jan. 12, 2004).

Some companies, including Hewlett-Packard(Fried, Sept. 24, 2004), Novell (Shankland, Jan. 13, 2004), and Red Hat (Shankland, Jan. 19, 2004) have begun offering legal protections to Linux licensees. HP offers a limited indemnity—good only against threats from SCO--to Linux licensees, provide they do not modify the code received from HP. Red Hat offers a warranty stating that it will replace any infringing code. Novell’s indemnity is limited to $1.5 million or 1.25 times the software support price. Although these legal protections are limited, they represent a real decrease in uncertainty for smaller companies that license Linux from these distributors. (IBM has not offered an indemnity, claiming that SCO’s claims are without merit.)(Lyons, Aug. 5, 2003).

Publicity and Response

Competitors of SCO are not the only players to see the benefits of reducing legal uncertainty around Linux. Open Source Risk Management opened its doors in 2003, as the SCO cases dominated discourse about F/OSS. OSRM offers risk assessment to both companies and individual developers (Linux developers can buy a membership for $250 a year), and provides indemnification for copyright risk for Linux users. Some saw OSRM as a political misstep on the part of some in the F/OSS community. Pamela Jones of Groklaw (see below) was originally prominently involved in its inception. While the organization hoped to be seen as a demonstration that supporters of F/OSS were willing to stand behind it financially, critics cast Jones’s involvement as an indication that she thought F/OSS has serious IP problems. Jones disagrees with this characterization, noting that indemnification is simply a business-friendly precaution for companies. To prevent SCO and F/OSS critics from gaining mileage out of their interpretation of her involvement, she resigned from the OSRM,, stating that “money is nice, but integrity is everything” (i-Technology News Desk, Nov. 21, 2004).

Initially, some in the business press were dubious about IBM’s chances. Daniel Lyons, writing for the online version of Forbes, went so far as call IBM’s defenders in the F/OSS community “religious folk” who needed to “wake up.” (Lyons, June 18, 2003). Lyons based his argument not on the strength of SCO’s legal claims, but on its business interest. IT-centric publications also expressed concern, with Jon Dvorak of PC Magazine criticizing the F/OSS community for not “realiz[ing] that Linux and the entire open-source movement are at grave risk,” (Dvorak, June 2, 2004; Cooper, July 18, 2003). and Charles Cooper of CNET arguing that F/OSS’s lack of indemnification posed clear risks for adopters. Yet the press was not entirely cohesive on this topic, and some reports sought viewpoints that examined the legal challenges for SCO (Gaither, Aug. 6, 2003; Galli, Aug. 25, 2003). Reporters have followed, and reported on, recent legal developments indicating weaknesses in SCO’s case (Shankland, Feb. 9, 2005). Further, the F/OSS community itself has been well-represented in press reports around the SCO case (see below).

Legal uncertainty, in the end, is business risk, so analysts’ recommendations can help indicate the effect of uncertainty on the market. Analysts initially split their assessment of SCO v. IBM, with Forrester arguing that IBM would simply buy SCO and Gartner urging companies to “minimize Linux in mission-critical systems (Gilbert, May 27, 2003). According to CNET’s, however, anecdotally, IT managers were not reconsidering deployments of Linux in the face of what they clearly saw as an uncertain situation[32]. By November of 2003, Gartner had seemingly revised its analysis, voiced concerns about SCO’s legal expenses, and began advising companies not to pay SCO license fees unless unequivocally required by a court (Weiss, Nov. 19, 2003). In March 2004, Forrester released a survey of 140 “large American companies,” in which it found that 60 percent of the companies were adopting open source, and only 39 percent planned to “avoid [it] for now.” Ted Schadler, writing for Forrester, trumpeted the benefits of open source and took issue with perceived risks:

The Linux community will rip and replace any contested code, thus giving you a royalty-free product to use. The real risks are more mundane: Who will support the component? Will your commercial application provider support the upgraded open-source component? Did you inadvertently use a General Public License component in a product that you shipped to a customer? (Schadler, Mar. 18. 2004).

While 39 percent is not an insignificant number, the adoption rates overall show that F/OSS is in no danger of being snubbed generally due to SCO’s claims.

The F/OSS Community Response to SCO

Any lawsuit that has the potential to shake up an industry will result in defensive action by competitors, commentary by industry analysts and a reaction by the stock market. What makes the F/OSS market unique is its knowledgeable and dedicated community of F/OSS developers and supporters, who see no reason to stop at developing the code in F/OSS projects when they can actively support the model politically. The F/OSS community’s response to the SCO case provides an example of how its culture of constant public commentary on projects can adapt to new discursive terrain, in the process leveraging some of the same effects of numbers and forms of personal authority that organize F/OSS development work. Self-publishing via the Internet plays a large role in this effort, as does the aura of economic disinterest (whether or not accurate) that frames most of the F/OSS arguments about open code. Technology and business journalists have been increasingly responsive to this strategy, with the effect of forcing SCO to speak directly to the F/OSS community. SCO CEO Darl McBride’s “Open Letter to the Open Source Community,” was the most striking of these efforts, and somewhat notorious for claiming that statements by Bruce Perens constituted proof that Linux infringes Unix (McBride, Sept. 9, 2003).

There has also been substantial grassroots participation in the legal discussions surrounding F/OSS, notably through the Groklaw project ( Groklaw is a website (originally a weblog) founded by a paralegal, Pamela Jones, to provide information on the SCO lawsuits. By her own account, Jones began publishing information about the SCO case as she grew angry at SCO’s legal tactics. Her reasons for becoming involved are illustrative of the ways that the pragmatic commitments of the F/OSS development community translate into action, often despite the fact that members of the F/OSS community do not think of themselves as "political." Certainly Jones does not. In an interview, she stated:

I reasoned like this originally: I am not a lawyer. I am not a programmer. I have no influence. I have few friends in high places. I am not a political person. I belong to no organizations. What can * I* do? … I wanted to do something. I love GNU/Linux software. It taught me how much fun computers can be. I love seeing into the process. I love the ideals behind free software, specifically, caring about other people and not just yourself, and cooperation, and being able to look at the code and even change it and share it freely… All right, I said to myself, what can I do well? The answer was, I can research and I can write (Jordan, July 31, 2003).

Groklaw has grown to include every significant filing in all of the SCO cases—hundreds of documents—most with detailed commentary by Jones or other contributors to the site. Groklaw went beyond this role when, speaking for the “open source community,” contributors posted a very sophisticated response to McBride’s Letter (Orion, Sept. 20. 2004). Groklaw has also remained a key site for collaborative research on important historical aspects of the case. Recently, a contributor posted the original Unix settlement agreement between Unix Systems Laboratories and the University of California, a document which provides important details about the chain of ownership of Unix. The settlement was confidential and has long inspired speculation, yet it was a tenacious independent Groklaw supporter who thought to use California’s version of a FOIA request to obtain the content. The agreement grants the public rights to redistribute much of the Unix source code, and could be a significant development in favor of IBM (Jones, Nov. 28, 2004; McMillan, Dec. 2, 2004). In effect, Groklaw has become an informal research center for the F/OSS community’s efforts to dispel legal uncertainty surrounding Linux, the GPL, and to a lesser extent, F/OSS in general. Such a public resource, explaining litigation in real time to all interested or affected parties, is unusual if not unprecedented.

Groklaw operates on the same volunteer basis as F/OSS development, and with the same informal authority structure built on the credibility and effort of the founder. Like other F/OSS projects, it maintains its centrality in the face of possible ‘forks’ in the epistemic community. Groklaw is not the only F/OSS community discussion of the SCO case, though it is by far the most extensive., a Linux new site, began to track the SCO case and offer documentation, but it eventually deferred to Groklaw (“A Look at,” Feb. 1, 2005). Rob Landley, Eric Raymond, and others published an exhaustive critique of SCO’s Second Amended Complaint on the OSI website (Landley, Feb. 1, 2005). Bruce Perens, Eric Raymond and Greg Leahy have all analyzed SCO’s public presentation of some of the code implicated in its suit, and have published their analyses online[33].

Grassroots engagement has also coalesced around the technical defense of the Linux and other F/OSS projects from SCO-like claims. Developers have mobilized extensively around the search for (and elimination of) potentially infringing code. In the SCO case, this effort has been hampered by the fact that not all of the code at issue has been publicly identified. Nonetheless, the process itself represents a great asset for F/OSS projects—although the openness of the code encourages infringement claims, it also means that they can be addressed in an efficient and timely manner.

Whither SCO?

For purposes of this chapter, the SCO cases are important because they highlight both the legal threats to F/OSS and F/OSS community strategies for managing them[34]. The perceived high stakes for Linux means that a wide range of constituencies have weighed in. It is not entirely clear how meritorious SCO’s claims are, but they have at least had the effect of generating a great deal of press. was the first company to sign a SCO license, citing the need for “certainty,” but it is unclear how many companies have followed suit (Shankland, Mar. 1, 2004). The case has become exceedingly complex, with counterclaims by IBM and the several other lawsuits noted above, making the end result even harder to predict.

The outcome of SCO’s suits will not be known for some time—presently, the IBM case is set for trial in April, 2005, though the parties’ motions for summary judgment may be decided before that[35]. Additionally, the cases may settle, resulting in no guiding case law. (It has been speculated that SCO is actually looking for a settlement or for acquisition by IBM or another interested party, but as of this writing the case has moved forward.) Because of the stakes, F/OSS constituencies have reacted in ways that seek to reduce the perception of Linux-related risk. There is some reason to think that that the publicity surrounding the case has lowered this perception of risk over time. As noted, business analysts have become increasingly dubious about SCO’s claims, and its stock price has plummeted from over $11.00 a share in June 2003[36] to under $3.00 in the latter half of 2004[37]. In January 2004, SCO revised its November 2003 S3 to note various weaknesses in its case, including statements by Novell that SCO does not own the rights to the disputed code. Red Hat, on the other hand, has seen its stock price grow from around $6,00 a share when it filed suit against SCO[38] to nearly $12.00,[39] indicating that the business of F/OSS distribution is still seen as very much a going concern by investors.


Legal uncertainty is a genuine issue for F/OSS. Yet the fiercely rhetorical political and economic debate about F/OSS as both a production model and a legal concept has taken precedence, perhaps obscuring, perhaps actually altering, the true extent of the challenge. While difficulty in managing IP rights, non-traditional license drafting, and a lack of published caselaw reduces adopter confidence in F/OSS solutions, at present the economic and political incentives for F/OSS adoption appear to outweigh concerns about its legal status. The licenses’ ability to serve as a kind of social code among developers has served the F/OSS community well—even without court decisions, and even with the constant debate that characterizes F/OSS development, accepted interpretations of thorny provisions promulgate through the F/OSS community. Simultaneously, the F/OSS system is maturing with its growth: F/OSS licensees and developers are acting to reduce risk in a variety of ways, and F/OSS is also beginning to adopt some traditional safeguards, such as intellectual property indemnities. The ability of the F/OSS community to mobilize around threats to the model has been crucial to this (tentative) success. F/OSS communities have proven adept at undertaking the technical fixes that would guarantee unencumbered code, and, significantly, at conducting the commentary and education campaign—in and outside core F/OSS constituencies—that begin to shift perceptions about F/OSS.


1. See, e.g. Lawrence Rosen, Open Source Licensing : Software Freedom and Intellectual Property Law (2004); Dennis Kennedy 2001, Intellectual Property: Policy Considerations From a Practitioner's Perspecive: A Primer on Open Source Licensing Legal Issues: Copyright, Copyleft and Copyfuture, 20 St. Louis U. Pub. L. Rev. 345 (2001); Christian H. Nadan, Open Source Licensing: Virus or Virtue?, 10 Tex. Intell. Prop. L.J. 349 (2002).

2. Though the image of individual programmers contributing code to in an ad hoc, unplanned manner is central to the story of F/OSS, some projects (notably, high-profile projects such as Linux and Apache) accept code in a highly hierarchal, controlled manner. Conversely, “proprietary” code is generally assumed to be developed in a highly controlled environment, with all intellectual property clearly owned by the developer or the company that employs her--an assumption that is belied by real world examples. One such example, the SCO litigation (see below), dramatically reveals the complexity involved in tracking ownership of a large, legacy code base. Companies vary greatly in their attention to intellectual property auditing and control. As proprietary software is generally kept secret and released only in binary form, the amount of infringing material that leaks in is unknown.

3. 17 U.S.C. §302.

4. The F/OSS model has also been applied directly to digital versions of books, music, etc., for example by the Creative Commons project. See (last visited Feb. 1, 2004).

5. For example, Linus Torvalds holds the trademark LINUX. While the underlying code can be modified by any user, Torvalds reserves the right to decide what changes can be called part of Linux. Similarly, the Apache Foundation holds a trademark in APACHE for web servers. The Open Source Initiative actually holds a trademark in the term “Open Source” and “OSI Certified” for software licenses; it uses these marks to designate licenses that meet its Open Source Definition. As such, OSI has some measure of control over the meaning of “open source” in the context of software licenses.

6. See Eben Moglen, “Why the FSF Gets Copyright Assignments from Contributors,” Free Software Foundation, at (last visited Dec. 6, 2004). For many projects, however, the copyright remains with the contributors.

7. This brings up a possible drafting concern as well: a disclaimer of warranties for noninfringement often has to be explicitly stated in order to be enforceable. Many F/OSS licenses do not specifically disclaim noninfringement.

8. See Section III, infra.

9. Patent’s willful infringement doctrine makes policing patents even more challenging: because patent law allows for treble damages if the infringer knew of the patent he is infringing, there is an enormous incentive not to look at relevant patents, at all. The resulting uncertainty can only increase concerns that problematic patents may exist, likely at any moment to appear in the hands of a litigant and sink a project.

10. Patent litigation is famously complex and expensive, and many companies cannot afford to expend the resources required to defend against a well-funded and determined adversary. Uncertain liability for infringing code within group projects complicates matters further.

11. In order for an enforceable contract to exist, the parties must agree to the terms. (Thus we have clickwrap licenses that insist the user clicks on “I Agree” to the EULA before the software will install.) F/OSS projects generally have as many licensors and licensees as they have contributors, making the relationships that result in enforceable obligations (known as “privity”) difficult to ascertain. The drafters of the GPL attempt to avoid this issue by stating that it is a “bare license”—that is, every requirement is simply a condition of the license grant, which can be revoked at any time. Assent is assumed, because the licensee’s right to use the software would, without the license, not exist at all. GNU General Public License, Terms and Conditions for Copying, Distribution, and Modification, Free Software Foundation, at (last visited Feb. 1, 2005). In theory, no agreement between the parties is needed. While it is well-settled law that a licensor may generally impose restrictions and revoke a license at any time, the GPL relies on an especially expansive interpreation of this doctrine.

12. OSI approves any license that follows the Open Source Definition, although it encourages licensors to use existing licenses, if possible. For a clear example of how a large number of licensing schemes can be issue, see the Free Software Foundation’s discussion of licenses that are “compatible” and “incompatible” with the GPL: Various Licenses and Comments about Them, Free Software Foundation, at (last visited Feb. 1, 2005).. The vast majority of F/OSS projects use one of a few licenses, most commonly the GNU GPL, or the less demanding BSD-type licenses. The Mozilla Public License is also growing in popularity. See, e.g., Statistics on project licenses,, at (last visited Feb. 1, 2005).

13. The Creative Commons website includes a cartoon that explains the system here: Neeru Paharia et al., How It Works, Creative Commons, at (last visited Feb. 1, 2005) (displaying a cartoon that explains the system).

14. See, e.g., Free Software Foundations, “Frequently Asked Questions about the GNU GPL,” at .

15. See, e.g., K.N. Cukier, Chapter 3; Volker Grassmuck, Chapter 2.

16. See Volker Grassmuck , Chapter 2.

17. See Grassmuck, id.

18. See See Ina Fried, Ballmer Attacks Linux on Patent Front, CNET, (Nov. 18, 2004) at

19. See Microsoft, “Research E-Bulletin: Attitudes Towards Shared Source and Open Source Research Study” available at (last visited Feb. 1, 2005). While some corporate sponsors of F/OSS have become evangelists, by far the most enduring, vocal advocates for F/OSS are those from the F/OSS developer community.

20. See supra note 87; the annotated version of the Microsoft memo available on the OSI website includes commentary by Eric Raymond analyzing Microsoft’s concerns and the F/OSS community’s efforts at messaging.

21. For links to translations of the letters, and OSI’s discussion, see OSI, “Peruvian Congressman refutes Microsoft's "Fear, Uncertainty and Doubt" (F.U.D.) concerning free and open source software” at

22. AP, “Brazil Gives Nod to Open Source,” Wired News (Nov. 16, 2003) (quoting da Silva’s National Information Technology Institute head, Sergio Amadeau) at,1377,61257,00.html.

23. See. e.g., David Becker, “Se Habla Open Source?” CNet, (Feb. 16, 2004) at (discussing initiatives in Rwanda, Slovenia and India, among others).

24. A “precedential” decision must be followed by a court; for example, a Supreme Court decision must be followed by any United States federal court. A persuasive decision provides reasoning that might be useful and persuasive to a court that is not bound to follow it.

25. Official Statements and Responses, Furthermore, at (last visited Feb. 1, 2005); Mambo, at (last visited Feb. 1, 2005).

26. See Second Amended Complaint, Paragraphs 1-4, 6 of the prayer for relief.

27. Complaint, Para. XX

28. Complaint para 3 “This case is not about the debate about the relative merits of proprietary versus open source software. Nor is this case about IBM’s right to develop and promote open source software if it decides to do so in furtherance of its independent business objectives, so long as it does so without SCO’s proprietary information. This case is, and is only, about the right of SCO not to have its proprietary software misappropriated and misused in violation of its written agreements and well-settled law.”

29. SCO’s Amended Answer to IBM’s Amended Counterclaims, Groklaw, available at (Feb. 4, 2004).( “EIGHTH AFFIRMATIVE DEFENSE. The GPL violates the U.S. Constitution, together with copyright, antitrust and export control laws, and IBM claims based thereon, or related thereto, are barred.”)

30. Id.

31. See id.

32. See id.

33. See e.g., Bruce Perens, Analysis of SCO’s Las Vegas Slide Show, at (last visited Feb. 1, 2005); Greg Lehey, SCO’s Evidence of Copying Between Linux and UnixWare, at (Jan. 2, 2004).

34. On the other hand, the SCO cases also clearly demonstrate that code ownership and licensing issues are not limited to F/OSS licenses. The Unix code at issue has passed through several sets of hands via a bewildering array of transfer agreements and licenses. Novell, which took ownership of the code from AT&T, expressed doubt that SCO actually had the rights it was suing IBM over. The asset purchase agreement at issue has been described as “murky” and unclear, a reminder that F/OSS licenses are not the only legal documents with interpretation issues. See Stephen Shankland, “Contract Illuminates Novell-SCO Spat,” CNET,at (June 4, 2003). SCO’s predictable response: a lawsuit against Novell, claiming slander of title. See Complaint, The SCO Group, Inc. v Novell, filed Jan. 4, 2004, available at

35. SCO is also seeking to postpone the trial. As amply demonstrated by the document timeline maintained by Groklaw, SCO has repeatedly delayed the case through discovery tactics and requests for more time to comply with court orders.

36. Quotes & Info, SCO GRP INC (THE) (SCOX), Yahoo! Finance, at (last visited Feb. 2, 2005) (reporting for June 2003).

37. Quotes & Info, SCO GRP INC (THE) (SCOX), Yahoo! Finance, at (last visited Feb. 2, 2005) (reporting for July 2004 through December 2004).

38. Quotes & Info, SCO GRP INC (THE) (SCOX), Yahoo! Finance, at (last visited Feb. 2, 2005) (reporting for August 2003).

39. Quotes & Info, SCO GRP INC (THE) (SCOX), Yahoo! Finance, at (last visited Feb. 2, 2005) (reporting for February 2005).


Becker, David, “SCO Sets Linux Licensing Prices,” CNET (Aug. 5, 2003) at

Dvorak, Jon, “Killing Linux,” PC Magazine, at,4149,1115156,00.asp (June 2, 2004); Charles Cooper, “The Next Big Linux Controversy,” CNET,at (July 18, 2003).

Fried, Ina, “HP Outlines Linux Indemnity Plan,” CNET (Sept. 24, 2004) at

Gaither, Chris, “ Sco Seeks Linux User Fees Plans to Sue Firms that Don't Pay Licensing Charges,” The Boston Globe C9 (Aug. 6, 2003).

Galli, Peter, “ SCO Battle Rages On; Use of Open-Source Continues Amid Attacks On GPL, Vendors,” eWeek 9 (Aug. 25, 2003).

Gilbert, Alorie, “IT Managers Scrutinize SCO Suit,” CNET, at (May 27, 2003).

Hatlestad, Luc, “France Open to Open Source,” VARBusiness (July 20, 2004), at

i-Technology News Desk, Money is nice, but integrity is everything, Linux World, at (Nov. 21, 2004)

Jardin, Xeni “Cutting Costs with Open Source,” NPR Day to Day (Audio) (Feb. 3, 2005), at

Jones, Pamela, The 1994 USL-Regents of UC Settlement Agreement, Groklaw, at (Nov. 28, 2004) (commenting on the settlement);

Jordan, Michael J., “Interview with Pamela Jones, Editor of Groklaw,” Linux Online (July 31, 2003) at .

Landley, Rob, et al., Halloween IX: It Ain’t Necessarily SCO, Open Source, at (last visited Feb. 1, 2005)..

A Look At The SCO Complaint,, at (last visited Feb. 1, 2005).

Lyons, Daniel, IBM Refuses to Indemnify Linux Users,, at (Aug. 5, 2003).

Lyons, Daniel, “What SCO Wants, SCO Gets,”, at (June 18, 2003).

MacKinnon, Chris A., Servers: Analyst Says Virtualization Driving Server Marketplace, Processor, at (Nov. 19, 2004).

McBride, Darl, “Open Letter to the Open Source Community,” Linux World, at (Sept. 9, 2003). The “open source community” responded eleven days later; see infra.

McKenzie, Matt, Negotiations Fail in Open-Source Copyright Dispute, Developer Pipeline, at (Sept. 24, 2004).

McMillan, Robert, “Unix Lawsuit Agreement Raises Questions for SCO,” (Dec. 2, 2004) at

Miller, Rich, Interview: Brian Behlendorf, co-founder of Apache, Netcraft, at (May 5, 2004)..

Orion, Egan, Groklaw Sends a Dear Darl Letter, The Inquirer, at (Sept. 20, 2004) (reprinting the open source community’s response to McBride’s “Open Letter to the Open Source Community”; see supra).

Schadler, Ted, (Forrester Research) “Commentary: Linux—Love Me, Love Me Not,” CNET (Jan. 23, 2004) at .

Schadler, Ted, “Commentary: SCO Can’t Slow Open Source,” CNET, at (Mar. 18, 2004).

Shankland, Stephen, “GPL Gains Clout in German Legal Case,” CNET (Apr. 22, 2004) at

Shankland, Stephen, “SCO Suites Target Two Big Linux Users,” CNET at (May 14 2003).

Shankland, Stephen, “SCO Targets Linux Customers,” CNET (May 14, 2004) at .

Shankland, Stephen, “Fact and Fiction in the Microsoft-SCO Relationship,” CNET, (Nov. 15, 2004) at

Shankland, Stephen, and Michael Kanellos, “Red Hat Files Suit Against SCO,” CNET (Aug. 4, 2003) at .

Shankland, Stephen, “Novell Offers Legal Protection for Linux,,” CNET (Jan. 13, 2004) at

Shankland, Stephen, “Red Hat Offers Software Warranty,” CNET ( Jan. 19, 2004) at

Shankland, Stephen, “Seeking ‘Certainty,’ CEO Signs SCO Linux License,” CNET, at (Mar. 1, 2004).

Shankland, Stephen, “Judge Slams SCO's Lack of Evidence Against IBM,” CNET, (Feb. 9, 2005) at

Weiss, Todd R., “OSDL goal: $10M defense fund for Linux users,” Computerworld (Jan. 12, 2004), at,10801,88993,00.html

Weiss, George J., Gartner Research, “SCO’s Legal Fees Could Jeopardize Its Software Business” (Nov. 19, 2003).

Personal tools