prof. michal s. gal and prof. niva elkin-koren: the dark...

Gal & Elkin-Koren The Dark Side of Viral Open Source Draft, May 23, 2011

The Dark Side of Viral Open Source:

Obstacles to Welfare-Enhancing Synergies

Michal S. Gal and Niva Elkin-Koren1

very preliminary draft, comments most welcome

Abstract

The creation of free and open source code through social networks has been celebrated as one of the most interesting and heartening phenomena of the internet age. The main legal platform chosen to facilitate such joint creation is the GNU General Public License (GPL). Software released under the GPL enables anyone to use, modify, and distribute the code. Yet it conditions such rights on virality: every work based on the code must also comply with its restrictions. This article analyzes the welfare effects of virality. It shows that virality can increase motivations for innovation both in open source and in commercial code yet at the same time impede innovation and growth by possibly limiting synergies between technologies. It then analyzes the market responses to the GPL's virality. Such analysis is timely given that the GPL now celebrates exactly 20 years since the inception of its most famous version.

IntroductionChapter 1: The development of open source

The Legal Framework: GPLChapter 2: The Welfare Effects of Virality

A. Possible Positive Effects of ViralityB. Possible negative welfare effects of virality: Limiting SynergiesC. Partial Conclusion: The Tradeoff

Chapter 3: Industry Reactions and Possible (Partial) SolutionsA. Technological Solutions

1. "Write around" the Source Code2. If you can't beat them, join them 3. Require the user to make the linkage4. Create a technological buffer

B. Legal Solutions: Changing licensing terms1. Dual Licenses2. Change from within: Create exceptions in the GPL3. Providing Public Funding for Synergies4. Creation and Use of New Licenses

C. Legal Solutions: Challenging Viral Licenses under Public Policy1. Challenging the scope of Virality under Copyright2. Compulsory Licenses: Virality as an antitrust violation?

Chapter 4: Conclusions

1 Professors, University of Haifa Faculty of Law. We owe thanks for fascinating discussions to Yoav Alkalay, Orna Agmon Ben-Yehuda, Dalit Ken-Dror, and Haim Ravia. Oshrit Aviv and Avital Bruker provided excellent research assistance. All views are explicitly our own.

1


Introduction

The creation of free2 and open source code ("FOSS") through social networks has been celebrated as one of the most interesting and heartening phenomena of the internet age.3 Indeed, the collaboration of numerous software developers, contributing voluntarily and without immediate monetary personal benefit4 to the development of better software to be used and modified freely by all, is an inspirational story, which challenges some of our notions about what motivates people to share resources such as time, skill and effort and about how markets work. It is a story which is told –albeit with different emphasis- by libertarians and anarchists, anti-market activists and free market advocates alike.5

Open source projects have already managed to challenge deep-rooted market structures and behaviors. Their success is astonishing: Linux, the world's largest FOSS platform, has over 5,000 developers and, according to its official site, up to 2.4 million users.6 It is estimated that 5.1% of the market for operating systems use open source codes.7 Some markets are even dominated by FOSS: Apache holds 62% of the world market for web servers,8 and commercial firms such as Microsoft have shrunk their investments in commercial alternatives. Indeed, as Raymond observed, the "bazaars" have taken down some of the "Cathedrals."9 FOSS is encouraged and used by governments in many countries, including Germany, U.S., France, Malaysia and China. It was also embraced by leading

2 The term "free" is used in the context of open source to connote the freedom to use and modify the software, rather than to its price.3 For analysis of open source see, e.g., Eric S. Raymond, The Cathedral and the Bazaar: Musings On Linux And Open Source By An Accidental Revolutionary (2000) at http://www.catb.org/~esr/writings/cathedral-bazaar/cathedralbazaar; Yochai Benkler, Coase's Penguin, or, Linux and The Nature of the Firm, 112 Yale L.J. 369 (2002); Brian W. Carver, Share and Share Alike: Understanding and Enforcing Open Source and Free Software Licenses, 20 Berkeley Tech. L.J. 443 (2005); Ronald J. Mann, Commercializing Open Source Software: Do Property Rights Still Matter?, 20 Harv. J.L. & Tech. 1 (2006); David McGowan, Legal Implications of Open-Source Software, 2001 U. Ill. L. Rev. 241; Daniel B. Ravicher, Facilitating Collaborative Software Development: The Enforceability of Mass-Market Public Software Licenses, 5 Va. J.L. & Tech. 11 (2000); Greg R. Vetter, The Collaborative Integrity of Open-Source Software, 2004 Utah L. Rev. 563; Greg R. Vetter, "Infectious" Open Source Software: Spreading Incentives or Promoting Resistance?, 36 Rutgers L.J. 53 (2004); Jonathan Zittrain, Normative Principles for Evaluating Free and Proprietary Software, 71 U. Chi. L. Rev. 265 (2004). Christopher M. Kelty, Two Bits: The Cultural Significance of Free Software (2008). 4 As elaborated below, today some commercial firms pay their developers to create FOSS. However, a large part of the non-commercial FOSS is still created by volunteers with no immediate monetary gain. 5 Niva, Fordham6 As of May 2010, as published in the formal Linux counter report, available on http://linux.derkeiler.com/Newsgroups/comp.os.linux.misc/2010-05/msg00001.html (Last visited May 11, 2011). Other sites have different estimates. See, e.g., http://www.numberof.net/number-of-linux-users/ 7 http://www.w3schools.com/browsers/browsers_os.asp (last visited May 11, 2011).8 http://w3techs.com/technologies/details/ws-apache/all/all (last visited May 11, 2011).9 Eric S. Raymond, The Cathedral and The Bazaar: Musings On Linux And Open Source By An Accidental Revolutionary (1999).

2

http://w3techs.com/technologies/details/ws-apache/all/all

http://www.w3schools.com/browsers/browsers_os.asp

http://www.numberof.net/number-of-linux-users/

http://www.numberof.net/number-of-linux-users/

http://linux.derkeiler.com/Newsgroups/comp.os.linux.misc/2010-05/msg00001.html


commercial technology firms such as IBM, Google, Amazon, Sun, Netscape, Java and Oracle, and recently even by Microsoft.10 The open source movement has also inspired other industries to adopt somewhat similar models, one major example being Creative Commons, which applies to all copyrighted materials. It is thus safe to say that open source is here to stay, and is likely to continue to shape social and market interactions. It is thus important to determine the welfare effects of FOSS.

Open source is not just a social or technological phenomenon- it is also a legal one: it builds on the existing proprietary system of copyright and on contract law in order to create a set of legal rights and obligations that are attached to the source code. While licenses for the use of FOSS vary, most FOSS projects are still licensed under the GNU General Public License (“GPL”), or relatively similar versions.11 The GPL creates a unique bundle of rights: it allows anyone to copy, modify and distribute its code. In return, it requires that any work based on the code that the user distributes will be licensed under the GPL as well, a condition which has come to be known as virality.12

Virality creates an interesting and important tradeoff in the way it affects incentives for dynamic efficiency. By mandating that all improvements be distributed under the GPL and by preventing the appropriability of the code, virality contributes to incentives for increased innovation within FOSS and facilitates its dissemination. It also increases competitive pressures on commercial competitors to innovate. Yet, at the same time, virality potentially impedes creation and innovation which are based on synergies or complementarities between different codes. This is true with regard to most projects that involve both open and commercial code in the computer ecosystem, given that virality significantly limits the ways that investments in synergies can be commercially appropriated. Such effects might be especially significant where new industries are created under viral licenses and become locked into a strict legal framework. Alternatively, synergies and future innovations might be limited where the dominant platforms are commercial and FOSS code cannot interoperate with them because of its virality. The virality condition even limits some synergies between FOSS projects. The analysis thus reveals not only the benefits of the GPL's virality, which are often availed, but also the dark side of viral open source.

Given these obstacles to synergies, the market has no stayed unresponsive. Rather, the widespread adoption of viral licenses has led market players to try and devise ways to reduce the obstacles created by virality on possible synergies. This article analyzes such ways and evaluates their ability to reduce the obstacles erected, as well as their effects on social welfare. The time to evaluate such market responses is ripe: exactly twenty years ago, the most known version of the GPL, GPL version 2, was released. 10 See, e.g., Stephen M. Maurer, "The Penguin and the Cartel: Rethinking Antitrust and Innovation Policy for the Age of Commercial Open Source" in Berkeley J. of L. and Tech.; vetter, fordham11 See below.12 The term was first coined by Margaret Jane Radin (cite) and relates to contracts which limit the rights of subsequent owners or users of the property. Some virality conditions are prohibited by law, for example, contractual limitations on the ability of a buyer to resell land. When applied to knowledge, the effects of such virality may be different than when applied to physical chattels. This is because it may apply to a much larger group given the public good characteristics of knowledge, and -more importantly and as this article elaborates- the fact that it might affect motivations and the ability to innovate.

3


The rest of the article is structured as follows. The first chapter sets the stage by reviewing the raison d'être as well as the modus operandi of the FOSS movement, with a special focus on viral licenses. The second chapter examines the actual and potential welfare effects of viral FOSS. We identify both welfare-enhancing effects as well as welfare-reducing effects. Most importantly, the analysis focuses on the potential of viral licenses to increase or to reduce innovation and further development of knowledge and ideas.

The third chapter analyzes the market responses and available legal tools that currently exist, both in the antitrust and the intellectual property spheres, in order to ensure that the best incentives for dynamic efficiency are created. We show that the tools adopted by the market do not deal effectively with the GPL's modus operandi. Nonetheless, we show that some legal tools might be used to increase innovation in the market. While not challenging the significant benefits FOSS and the GPL can offer, our conclusions shake some of the most basic assumptions about the welfare effects of viral open source and make a case for placing some limitations on such viral terms.

Chapter 1: The development of open source

FOSS started as a one man revolution to proprietary software where a company keeps the source code of its applications secret (or "closed") thereby making it difficult for others to change it, even for their own non-commercial purposes.13 The creation of a new, free, and open operating system, the Linux code, in 1991, signaled the beginning of a new era. Linux was further developed by a virtual and international community of software developers, connected mainly through the internet,14 who donated their time and effort outside their employment agreements.15 Motivations of contributors were diverse, and included non-market motivations such as social interactions via cooperative creative activity16 and the thrill in taking on proprietary software giants like Microsoft, as well as market motivations, including reputation and experience.17 In addition, the motivating philosophy of software freedom appealed to many software developers who believed that source code should be

13 For further information about the Open Source Movement visit, inter alia, the Open Source website: http://www.opensource.org/. See also RICHARD M. STALLMAN, FREE SOFTWARE, FREE SOCIETY: SELECTED ESSAYS OF RICHARD M. STALLMAN (Joshua Gay ed., Free Software Foundation, 2002).14 Interestingly, in the initial stages of FOSS development the internet was not fast enough. Linux was thus spread in LAN parties, where people would bring their computers to a location where Linux was installed. 15 niva, use generated platforms16 Benkler, wealth in vetter. Niva: Others emphasize social motivations such as adhering to cultural norms connected to positive network externalities. This may be related to software (Weber S. (2000), ‘The Political Economy of Open Source Software’, BRIE Working Paper, 140, http://economy.berkeley.edu/publications/wp/wp140.pdf.), to hacker culture (RAYMOND THECATHEDRAL AND THE BAZAAR, (1999, US: O'Reilly & Associates), or to gaining status in a ‘giftculture’ (Veltman KIM, On the Links between Open Source and Culture, (2002), AT:http://erste.oekonux-konferenz.de/dokumentation/texte/veltman.html). 17 See Int’l Inst. of Infonomics, Free/Libre and Open Source Software: Survey and Study, at http://www.infonomics.nl/FLOSS/? (last visited ...); Lerner J. and Tirole J. , The Simple Economics of Open Source, (2000) at: http://www.people.hbs.edu/jlerner/simple.pdf, pp. 26-28.

4


available for copying, modification, and subsequent distribution in order to facilitate software innovation and improvements.18

This was no less than a revolution in technology production: it enabled cooperation on a scale not envisioned before, as it significantly lowered production costs and was not limited by the traditional boundaries of corporate entities or by informational obstacles, due to the accessibility of the production platform and the transparency of the code. The enabling legal framework allowed users to identify problems and others to fix them without asking for anyone’s permission and without engaging in costly transactions.19 This, in turn, created more flexible and lower cost software with a serious shot at better quality, which in turn attracted more users and developers.20 As Benkler argues, collaborative FOSS is the "quintessential instance of commons-based peer production."21

As one of us noted elsewhere,22 the open source movement situates its activism in civil society, by aiming at changing social practices and social norms related to software. It advocates the use of legal rights in a way that is likely to change their meaning. Developers are called to voluntarily restrain the power they were granted under copyright law for the benefit of society at large. Ultimately, the purpose is to redefine social norms and promote values of sharing and reusing. The vehicle for such social change makes use of existing legal frameworks of copyright and contract, to create a new form of copyright licenses. The concept of the use of existing copyrights in a way which requires anyone who redistributes the work, with or without changes, to pass along the freedom to further copy and change it, has come to be known as "copyleft."23

FOSS has outgrown its humble origins. Today it applies to non-marginal parts of software markets. While in 2002 only 500 FOSS projects existed, by 2007 their number rose dramatically by almost ten-fold.24 This dramatic change was fuelled, inter alia, by the endorsement of OS projects by several large software companies. The most dramatic turning point was when IBM announced that it would invest $1 billion in Linux, paying some of its developers to work as volunteers on FOSS projects and pledging to not enforce some of its patents, if used in connection with Linux. 25 Indeed, FOSS has become a commodity in many internet platform markets. As FOSS becomes more popular and continues to develop, there is a stronger motivation to use it or, at least, to create compatibility with it.

18 Carver, near foot 30. 19 Yochai Benkler, THE WEALTH OF NETWORKS: HOW SOCIAL PRODUCTION TRANSFORMS MARKETS AND FREEDOM, Yale University Press, 2006. 20 CArver, near foot 33.21 Benkler, wealth of nations, in vetter, 23/ . For information on the OS movement see, e.g., the Open Source website: http://www.opensource.org/. See also RICHARD M. STALLMAN, FREE SOFTWARE, FREE SOCIETY: SELECTED ESSAYS OF RICHARD M. STALLMAN (Joshua Gay ed., Free Software Foundation, 2002).22 NIva23 http://www.gnu.org/copyleft/24 Maurer, pinguin, near foot 5.25 Stephen Shankland, IBM Pledges No Patent Attacks Against Linux, CNET News.com, Aug. 4, 2004,

at http://news.zdnet.com/2100-3513_22-5296787.html.

5


Notably, today, many FOSS projects are commercial, funded by for-profit companies, which hybridize proprietary software appropriation techniques with conventional FOSS volunteerism-centric development.26 Dominant firms have invested in such projects, where there is both programmer interest and strategic benefit to the firm. The licensing platforms used for such projects vary greatly and generally do not include viral terms. Still, many important FOSS projects are licensed under the GPL. They are the focus of this paper.

A. The Legal Framework: GPL27

The GPL, which is a non-exclusive public license, adopted many public domain licenses concepts, with the added twist of virality.28 It has been updated twice, but its basic principles still stand.29 We shall refer to version 2, which is used in many major FOSS projects, including Linux.

The GPL has become the standard license for most FOSS projects: it is used by more than 70% of the market for open source. 30 Yet this percentage does not indicate the GPL's real effect, which stems from the importance of several large projects which have adopted it, such as Linux and MySQ, as well as from the fact that in many other cases in which a different license is used, the GPL acts as a benchmark, and thus its major obligations have spill-over effects into other licenses as well. Indeed, more than 85% of active FOSS projects include some version of the GPL or similarly structured license.31 These facts, in themselves, indicate an important potential benefit of the GPL: it creates standardization and thus reduces transaction costs that would arise from studying each license.32 This is especially true given that the GPL is supported by the Free Software Foundation ("FSF"), which provides legal support on an on-going basis.33 Yet this very trait may also increase its negative welfare effects, if the market is locked-in into a sub-optimal license.

26 See, e.g., Greg R. Vetter "Commercial Free and Open Source Software: Knowledge Production, Hybrid Appropriability, and Patents", 77 Fordham L. Rev. 2087 (2009).

27 For the GPL's creation and history see also John Tsai, For Better or Worse: Introducing the GNU General Public License Version 3, Annual Review, Berkeley Technology Law Journal (2008), P. 548-55328THE MYTH OF COPYLEFT PROTECTION: RECONCILING THE GPL AND LINUX WITH THE COPYRIGHT ACT, Douglas A. Hass A.B.A. Intellectual Property Law Newsletter, Vol. 25, Fall 2006 29 The first version, written by Richard Stallman, a computer scientist, was published in 1989. The second version, to which the legal scholar Eben Moglen contributed, was published in 1991. Some downsides of the GPLv2 generated discussions in the FOSS community which led to the adoption of GPLv3 in 200?.30 Oshrit: cite. Tzur and David argue that some developers select by default the de-facto standard, the GPL, without seriously considering later impact it may have. Tzur and David, supra, p. 24.http://sourceforge.net/softwaremap/trove_list.php?form_cat=15 (last visited Oct. 17, 2006) (listing GNU GPL projects only).; OSTG, freshmeat.net: Statistics and Top 20, http://freshmeat.net/stats 31 Benkler book, 90. 32 Niva33 The Free Software Foundation promotes the GNU General Public License (GPL) for softwareThe license was designed by the Free Software Foundation (FSF) for the GNU project. Such support raises interesting questions, such as what is the weight to be given to the FSF's interpretation of the GPL, especially when it applies to code in which it does not have copyrights.

6


The strategy of the GPL for promoting the sharing and reuse of software rests on three pillars: copyright in the code, free and open source code, and virality.

The GPL asserts copyright in the code, thereby enabling the licensors to determine the terms of use and to prevent others from capturing the code and making it proprietary.34

The other two components establish the unique "deal" that the GPL offers to potential users. This "deal" offers significant benefits: Software released under the GPL allows anyone to copy, modify, and distribute the code. The granting of such wide rights is a major component of the FOSS ideology, as the GPL's preamble states: "The licenses for most software...are designed to take away your freedom to share and change the works. By contrast, the [GPL] is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users."35 To facilitate such modifications, the GPL mandates the distribution not only of the object code- which consists of binary instructions to a computer on how to operate the software- but also the source code: such instructions in human language. The benefits are clear: open source makes it much easier for software developers to understand the code, modify it or write applications to it. Such modifications range from minor bug fixes to the reuse of source code in entirely different projects.36 These benefits go well beyond those granted without monetary compensation in most other licenses.

In exchange for such broad rights, the user is required to agree to virality: any distributor of the code, a derivative work or any work "based on the code" must release the entire work under the GPL,37 to ensure that any subsequent work would be subject to the same contractual terms as the original work.38 As a result, incentives to use GPL-covered code in proprietary derivatives are significantly reduced.39 The GPL's preamble justifies this limitation as follows: “To protect your rights, we need to make restrictions that forbid anyone to deny

34 NIva. David McGowan, Legal Aspects of Free and Open Source Software 4-7 (the primary enforcement mechanism for open source licenses is the copyright infringement power),available at http://www.law.umn.edu/uploads/images/253/McGowanD-OpenSource.rtf (Oct. 5, 2004).35 GPLv2 Preamble.36 Heidi S. Bond, What's So Great about Nothing? The GNU General Public License and the Zero-Price-Fixing Problem, 104 Mich. L. Rev. 547 (2005). 37 An important question is whether a copyright owner is allowed to tell others what they can do with their own copyrighted material, since at least part of the new code might belong to the creator of a derivative work. This question is beyond the scope of this paper. We shall assume that it is allowed in some circumstances.38 Section 2(b) of GPLv2 states: ""You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this license." Section 6 of the GPL provides that each time a GPL licensee redistributes "the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program." 39 See, e.g., Tzur and David, p. 22-3.

7


you these rights or to ask you to surrender the rights."40 The GPL includes no exceptions to this condition.41

It is noteworthy that the virality condition does not limit the use of GPL-covered FOSS in private computer ecosystems and in development processes, so long as the protected code does not constitute an integral part of the final product. For example, a commercial firm can freely use FOSS for quality testing of its products or for analyzing the results of such tests, and even configure it for its own internal needs. This results from the fact that virality's triggering event is not copying, using or even modifying of the code, but rather its redistribution. Also, according to the GPL, virality only applies to works "based on" the GPLed code. Thus, any work that does not meet this condition, will automatically be exempt from virality. As elaborated below, the scope of works that meet this definition is unclear.

The GPL also does not place any limitations on the price that can be charged for the code. Rather, the term freedom relates to the freedom to use, redistribute, and modify the code. Yet because everyone is free to distribute the code, its price will tend to be the market price for distribution: Anyone selling the code for a higher price can be easily outbid. 42

The business model on which GPL-covered projects operate enables firms to compete and charge for services and other economic complements related to FOSS, such as its maintenance, support and warranty. Red Hat Inc., for example, sells media, manuals and support for the installation and maintenance of Linux. Such services may be required where the FOSS must be configured to meet a customer's needs or where quality assurance is important.

Chapter 2: The Welfare Effects of Virality43

As GPL-licensed FOSS projects become more prominent in their respective markets, the need to evaluate their welfare effects increases. Accordingly, this chapter evaluates both the positive as well as the possibly negative welfare effects of the GPL's virality. As we shall see, virality creates a unique tradeoff between different types of innovation.

A. Possible Positive Effects of Virality

Virality has several potential positive effects. We indentify and analyze three such effects: facilitating the assimilation of FOSS, foreclosure of proprietary appropriation of FOSS, and strengthening the motivations of peers to contribute to FOSS projects.

The virality condition facilitates the assimilation of GPLed FOSS. Even those who would otherwise not have adopted the GPL for their own code, might do so, if they wish to use the

40 GPL v2 Preamble.41 Although, as discussed later, such an exception can potentially be created.42 Bond.43 For the purposes of this chapter, we shall assume that the GPL is strongly viral, in line with the views of the FSF. This view will be challenged in the next chapter. Also, the analysis is focused on economic welfare considerations only, and gives little weight to other values, such as freedom to contract and moral rights in copyright.

8


protected code.44 As the number and quality of GPLed FOSS increase, so does the incentive to use it. Thereby, the scope of GPLed FOSS software grows much faster than without virality. As Carver pointed out, the self-perpetuating feature of the GPL is its most unique feature and is likely primarily responsible for its widespread adoption.45

Another effect of virality is the foreclosure of proprietary appropriation of the FOSS.46 Virality is used to balance the second pillar of the GPL, which grants everyone the right to use, modify and redistribute the code, which would have otherwise enabled commercial users to benefit commercially from FOSS code, without "giving back" to its developers directly. As Maurer explains, "[a] most profitable business strategy is to copy the underlying [FOSS] module at zero cost and then sell [commercial software] improvements for whatever the market will bear. This, of course, is a formula for disaster: If every company does this [FOSS] will disappear entirely. Viral provisions block this outcome by forcing companies that use [FOSS] code to donate their improvements back to the community."47 Moreover, virality ensures that the code would continue to develop as an open source, as long as there are developers that are willing to contribute to it.

Both effects strengthen the motivations of developers to contribute to FOSS projects. By spreading FOSS, virality strengthens the motivation of volunteer developers, who believe that source code should be free and open, to take part in FOSS creation. By limiting the possibility of private firms to appropriate FOSS' commercial value, virality strengthens these motivations further: it ensures that one could still benefit from his efforts and it prevents unjust enrichment and fairness concerns. Such a stimulant may be especially important where the motivation of the developer is purely innovation-related.48 The importance of such motivations cannot be downplayed, as they are a major force that inspires volunteers from around the world to invest their talent and time to create FOSS without direct monetary compensation. Maintaining the enthusiasm and the sense of trust among potential contributors is crucial for the success of collaborative FOSS projects.49

The analysis so far rests on the assumption that FOSS creation contributes to social welfare. Yet to determine the effects of strengthened motivations to create FOSS on social welfare, the validity of this assumption should be verified. As this has been the focus of other studies, the analysis is brief.

FOSS has many potential positive social welfare effects. Because every user has authorization to modify it, FOSS reduces costs of solving problems in specific computer ecosystems.50 Because everyone has authorization to view it, FOSS creates a greater public repository of solutions to common problems. Because everyone has authorization to use it

44 Carver, 447.45 Carver, 447?. For a similar conclusion see also John Tsai, For Better or Worse: Introducing the GNU General Public License Version 3, Annual Review, Berkeley Technology Law Journal (2008).46 Vetter, fordham, near foot 124.47 Maurer, near foot 17.48 Tzur and David, p. 20. 49 NIva, near foot 43, book; fordham near foot 74.50 Bond, 110.

9


(subject to virality), it can be used as building blocks in other FOSS projects, thereby reducing the need to replicate existing code and increasing interoperability. By creating central repositories of codes, FOSS creates a large basis of modules for reuse, which enables developers to focus their efforts on creating new products rather than reinventing the wheel.51

Moreover, time donations of developers enable FOSS projects to offer software at price levels that are not viable for commercial firms. Another important advantage involves the possibility for continuous comparison of research results. Assume that a firm uses software to test the quality of its products. If the software's code is a "black box" to the user, should the software creator stop supplying the software, the user might not be able to compare results of tests performed with or without the software. Compare it with a situation in which the source code is open and distributed under a FOSS license, so that the user can understand and replicate the sequence of tests performed even if the software disappears from the market. These inherent benefits of FOSS may, by themselves, limit the need for virality, as the market may already have some preference for FOSS.52

FOSS also creates significant benefits in education. Its open source nature supports the study of coding and software technology at every level of complexity and in a diverse array of computer languages and information technology environments. 53

Another potential positive effect of FOSS is that it can create pro-competitive pressures on the behavior of other firms. Most importantly, it can create competition in markets where scale economies or network effects are significant, and thus high obstacles exist to eroding the market power of dominant firms.54 Some of FOSS' characteristics make it easier to reach significant scales. Foremost, the fact that the internalized production costs are low, creates an important advantage over commercial software, which must bear all costs of development. Second, its availability over the internet and the ease of licensing reduce transaction costs. Third, its open source code makes it attractive to many. Indeed, in the last decade, FOSS projects have put tremendous pro-competitive pressure on their proprietary rivals.55 There is a FOSS alternative, and usually a pretty good one, to just about every major commercial software product. For example, Linux challenges Microsoft's Windows (mainly in the servers' market) and Mozilla Firefox Web browser has emerged as the most formidable competitor to Microsoft’s Internet Explorer. This, in turn, forces commercial firms to find better, competing solutions.

Finally, FOSS projects can potentially increase software quality. Cooperation among many minds from different backgrounds may create a level of development and innovation that no commercial firm, operating alone, could achieve. This may lead to the incorporation of new features and the provision of better solutions to existing problems.56 Quality may also 51 Tzur and David, 28-9.52 See also Maurer53 Bond, near 178; Tzur and David, supra, p. 27.54 See discussion below.55 http://www.nytimes.com/2009/11/30/technology/business-computing/30open.html?_r=156 Maurer, near 25.

10


be increased due to the rapid pace of FOSS creation, given the sheer volume of contributors. As Eric Raymond has put it, "with enough eyeballs all bugs are shallow."57 This advantage becomes apparent when considering that for commercial firms, the payoffs from making clever but rapid improvements to existing software may be low relative to the costs of new releases. Quality also benefits from the fact that to a large extent FOSS are user-generated platforms: the developer is often also a user, thereby the informational obstacle about what users want is significantly reduced. While decisions where to contribute are made by each developer privately, trends in contributions signal joint demand patterns and at the same time create supply. Moreover, the open nature of the code creates positive externalities for other software projects by providing easy access to technological solutions to common problems.

Finally, the production model of FOSS- under which each developer contributed where, when and what he wishes- may create a much more efficient allocation of human resources than under an organized production model, where assignments are imposed from higher levels of management.58 This is because each developer is best aware of his comparative advantages as well as his passions and preferences. Indeed, when innovation is concerned, there is no linearity between the number of hours worked and production.59

It is noteworthy, however, that just like some commercial code projects, FOSS does not always increase quality. Empirical evidence on OS code quality is mixed, although many high-profile FOSS projects are clearly of very high quality.60 Thus, some FOSS products might be of lower quality than those developed by commercial firms. This might be due, inter alia, to motivational limitations on the continued goodwill of developers to donate innovative ideas for no direct monetary compensation,61 or to suboptimal incorporation of ideas in FOSS projects.62

This raises an interesting question: Even if we assume that a FOSS product is of inferior quality, is this necessarily harmful to welfare? The basic answer is negative: the market mechanism of consumer demand will reflect the value of relative quality to users. Even in regular, profit-based markets, consumers make their choices based on a combination of benefits and costs of different products. Price, quality, accessibility and other characteristics of competing products are balanced, to seek the optimal mix for each consumer. Thus potentially lowered quality software will only drive out higher quality software when consumers favor lower-priced alternatives over higher quality, since the additional quality is not worth the additional cost.63 Market dynamics play here an interesting role: as the number of users which use a FOSS code grows, the interest in the developers' community to

57 Raymond.58 Benkler?59 For this reasons some innovation firms, such as Google, set aside some time for each developer to work on what he wishes.60 Carver? Vetter?61 Bond, near foot 166.62 We do not deal with strategic use by competitors, as we think that it most cases it will not have negative overall welfare effects. 63 Bond

11


contribute to the development of that code might also grow, thereby potentially closing the quality gap with the commercial code.

Yet the fact that the lower quality product is preferred by consumers is not always an indicator that it is in their long-term interest. Where the market is characterized by significant scale economies and first-mover advantages64 or network effects, the industry might not produce the optimum mix that would further long term efficiencies.65 Network effects arise when the value to each consumer of the product increases with the number of other users of the product. Software markets are characterized by two types of network effects, which are interconnected. First, the need for compatibility of documents sent from one computer to another and the value of moving between computerized workplaces increases the motivation of consumers to use currently dominant software. Second, the wish to serve the highest number of potential consumers creates motivations for program developers to develop their programs to be compatible with the dominant software. This, in turn, increases motivations of consumers to buy the dominant software. Such network effects tend to reduce competition by raising barriers to entry and might limit the ability of producers of superior products to enter the market. This, by itself, is not problematic, if indeed the dominant producer continues to provide the optimal mix to its consumers. Problems arise when consumers are locked-in to a product that fails to maintain its superiority over time. Negative welfare effects may increase where the dominant product serves as an input into other markets, and its low quality significantly harms their performance. Yet the consumer, making the initial choice, might not be aware of such effects due to informational problems, or might not take them into account.

It is noteworthy that virality might strengthen the negative effects were GPL'd FOSS to become dominant in a market in which network effects are significant. This is because it makes it more difficult to switch to a non-FOSS product, if the whole interoperable system is viral and would need to be replaced. At the same time, its popularity will incentivize more developers to increase its quality, a condition which might not be as strong in dominant commercial code.

Accordingly, FOSS carries important welfare benefits, which depend, inter alia, on specific market conditions.

B. Possible negative welfare effects of virality: Limiting Synergies

64 Weber, for example, argues that if the conditions of FOSS increase first-mover advantages in a platform industry, then virality might limit the ability of for-profit firms to create interconnecting software. Steve Weber, THE success of open source. Cambridge, Mass., Harvard University Press. (2004) pp 221-2 (to check again).65 See, generally, Mark A. Lemley & David McGowan, Legal Implications of Network Economic Effects, 86 CAL. L. REV. 479, 483, 491 (1998)., at 500–21 (analyzing several antitrust lawsuits based on network effects concerns).

12


The viral characteristic of the GPL can potentially limit innovation and social welfare in an important way: by limiting incentives to use GPLed FOSS as a foundation for some future projects, virality limits synergies that could have increased social welfare.66

Synergies are created when the value of a product which incorporates different sources is higher than the value of each part standing alone. In economic terms, assume that product A increases social welfare by 50$ per unit, as does product B, whereas a combined product of A and B increases dynamic efficiency significantly, thereby increasing social welfare by 500$. The combined product can be a chattel (e.g. a cell phone), a service (e.g. tech support), or software. Synergies hold the potential to increase efficiency, either by creating higher value products or by reducing production costs, thereby saving resources. As informational technology progresses, more and more products are compound items, made of many components incorporating different pieces of technology, often created by different producers.67 This is enabled by the fact that software is a public good, that can be easily replicated at extremely low costs.

We identify two types of synergies. The first involves a synergy of separate products that have a joint interface based on interoperability. The second involves the creation of a whole new product, combined of both inputs. The first case is much easier to solve, given the separate nature of the two products, although problems with virality might still arise. The second is much more difficult to solve. We shall deal with both below.

For synergies to take place, two conditions must be met:

1. The relevant parties must be aware of possible synergies ("the informational obstacle");

2. All relevant parties find it worthwhile to invest in the realization of potential synergies ("the motivation obstacle").

FOSS often reduces the informational obstacle. This is because FOSS is generally transparent and accessible through the Internet: it allows everyone to observe the code, as well as its development process, as long as they meet certain conditions. In contrast, the source code of proprietary products often cannot be observed. Indeed, it was the "closed" code of the driver of the new printer, which did not enable its users to alter it in a way that would increase the benefit derived from it, that motivated Stallman to start the first FOSS venture.68 Accordingly, developers seeking solutions to problems may find solutions developed in FOSS rather easily. At the same time, proprietary developers might have stronger incentives to actively seek possible synergies, in order to maximize their investment, especially if search costs are high relative to the personal gain of each developer of FOSS. Still, much depends on the model in which the FOSS is created and applied. If, for

66 Tzur and David, 32; Vetter67 Maurts Dolmans and Carlo Piana, "A Tale of Two Tragedies – A plea for open standards," 2(2) Open Source Software Law Journal (2010) at http://www.ifosslr.org/ifosslr/article/view/46

68 See, e.g., ....

13


example, the relevant FOSS community invests in seeking and publishing information on possible synergies, a collective effort may well disperse search costs and further reduce the informational obstacle.

While FOSS generally reduces the informational problem, it aggravates the motivational obstacle in some situations, and reduces it in others. Below we explore two paradigmatic cases: In the first case all synergetic products are FOSS. At this point we assume license compatibility69 between all FOSS, an assumption we will relax later. In the second case one product is FOSS protected by GPL and the other is commercial.

All synergetic products are FOSS Let us first explore a situation in which all synergetic products are FOSS products. The FOSS nature of the product significantly reduces motivational obstacles, since there is no need to invest in contracting and buying any of the synergetic products.

Yet two obstacles to synergy may still emerge, one motivational and one legal. Where FOSS is based on a model of voluntary contribution by private developers, the private benefits to any developer who invests in creating the synergy should be higher than his private costs. This implies that even if the social welfare effects of the synergetic product are high and are much larger than the overall costs in creating the synergy, it would not always be realized.70 External funding to overcome the collective action problem, as well as internal leadership and guidance of voluntary developers to invest in such synergies, might reduce such obstacles. As elaborated below, a legal obstacle might arise when licensing terms which cover the different FOSS clash.

At least one product is proprietary Let us now explore a situation in which at least one of the products is FOSS and at least one other is proprietary. As noted, the FOSS nature of a product may make it easier to overcome the informational obstacle. Yet it significantly increases the motivational obstacle. This is because, for the synergy to accrue, it should be Pareto-optimal for all parties. The private firm will only invest if the expected profits from the investment are higher than costs incurred. But the virality condition significantly reduces its ability to profit from the synergetic product. Moreover, due to the virality, the proprietary technology, which was embedded in the synergetic product, now also turns to FOSS and could only be distributed under the GPL in the synergetic project as well as in any other projects in which it can potentially be used. The result resembles a reverse game of Topple: once you insert a wrong block (FOSS protected by virality), the whole structure (development for economic profit) topples. This implies that for the synergy to take place, the synergetic product would need to create value for the owner of the proprietary code in other ways (e.g. reputation or the provision of related services) which are often hard to create. Furthermore, given the effects of virality proprietary software firms often implement defensive strategies to guard against viral open source. The fact that the GPL does not address innovation by developers driven by financial gain, can thus reduce innovation.71

69 By license compatibility we mean that license terms do not clash with each other.70 This is, of course, also true for commercial firms, however in their case the benefits might be higher and the collective action problem is reduced.71 Tzur and David, 34.

14


[draw a diagram of the prices where synergies would be viable, and not]

Since we cannot assume that developers working in for-profit firms always have better ideas than developers working voluntarily on FOSS, the "next best idea" with a potential to create huge synergies might well be embedded in FOSS. The effects on social welfare can then be significant: loss of dynamic efficiency both in new and improved products and in more efficient and resource-saving processes. Naturally, the scope of the effects of limited synergies cannot be directly observed, given that would-have-been synergies might well have been abandoned due to the FOSS' virality. Yet some indications of such possible synergies can be observed from those cases in which allegations arose that proprietary firms attempted to incorporate into their products parts of FOSS code. The recent allegations against Apple exemplify the possible effects of limited synergies, especially where dominant platforms are proprietary. Apple has been accused by the FSF of including a possibly GPL-infringing software in its application store, GNU Go. As a result, it immediately removed the software,72 thereby preventing the ability of tens of thousands of existing GPL licensed software projects to be used in iPhone applications.73

Indeed, the limitations created by the GPL's virality condition on possible synergies creates what has come to be known a tragedy of the anti-commons, which involves the under-use of private goods controlled by more than one right holder.74 It is worth noting, that the outcome is worse than under a patent regime which limits the use of the protected technology. This is because under a patent regime, the originator of an idea can license its use to others and because patent protection is more limited in time. In contrast, the extremity of the virality condition of the GPL never allows such a synergy.75

Notably, while the GPL was not crafted with an objective to maximize overall software innovation,76 the synergy problem was also recognized by the creators of the GPL, which created a unique license, the so-called Lesser General Public License (“LGPL”). The LGPL is very similar to the GPL, except that it includes an important exception: its virality does not apply to dynamic links between the library that it covers and a completely closed code. The exception was inserted in order to ensure that binary modules which are part of the computer's hardware, and which interact with the FOSS would not be infected by the GPL's

72Harakd Welte, More thoughts on FSF action against Apple over GNU Go, June 15, 2010.

73 check again. 74 This problem was recognized and the term was coined in Michael Heller and Rebecca Eisenberg, "Tragedy of the Anticommons"; Michael Heller, The Gridlock Economy – How Too Much ownership Wrecks Markets, Stops Innovation, and Costs Lives, Basic Books, 2008. In economics this problem is called a problem of “Cournot complements”, named after the French economist who discovered that monopolist producers of complementary products may both block each other to extract monopoly rents, thus reducing output below the level that a single monopolist would have produced. See M. Lemley and C. Shapiro, “Patent Holdup and Royalty Stacking,” (2007) 85 Texas Law Review, 1991. 75 An interesting question is how such potential limitations on synergies affect FOSS developers' motivations to contributed their ideas to GPLed FOSS. This is an empirical question which is beyond the scope of this article.76 Michal Tsur & Shay David, A License to Kill (Innovation)? Open Source Licenses and Their Implications for Innovation 22-23 (Apr. 30, 2005), available at http://ssrn.com/abstract=858104.

15


virality. This was essential because many developers of such binary modules did not agree to release their code openly.

To sum, viral terms produce incentives detrimental to interoperability and coexistence between open and proprietary code.77 Yet such coexistence is an important component of the long-term growth and viability of the software industry, especially since it is unlikely that the entire software industry will convert to the open source approach.

D. Partial Conclusion: The Tradeoff

In light of the possible negative effects of virality, let us ask whether the strict virality condition, which creates no exceptions, is indeed necessary in order to achieve the positive effects discussed above. If the answer is negative, then its negative welfare effects can be erased without real harm. If, however, it is positive, we should then ask whether a better balance can be reached to increase social welfare.

Strict virality may not be needed and might even inhibit some of the positive effects discussed above. It is not needed to ensure that FOSS efforts are not appropriated. Rather, so long as the license includes an suitable compensatory model, this positive effect will not be lost. Note, that such compensation does not necessarily have to be monetary, as will be further discussed below.

Strict virality might also not be needed to create motivations for contribution. As Vetter argued, virality is not always a necessary predicate to a successful FOSS project. Sometimes the FOSS community holds together buoyed by the various other factors underlying the peer-production phenomena, including the furtherance of social welfare.78 Moreover, its possible negative welfare effects might rather limit the motivation of some developers to embed their best ideas in FOSS. This is an empirical question worth studying. Interestingly, strict and wide-scoped virality might also inhibit the spreading of FOSS, as otherwise it could be used on more platforms, as the Apple example indicates.

The analysis becomes more complicated when we turn to the fourth positive effect of strict virality- the strengthening of competition in software markets. Virality advances a unique model of market interaction, which creates (at least) two separate competing spheres: viral FOSS and commercial code, which interact only in competing over the consumer in product and services markets. Closing the door on synergies which involve derivative works of GPL'd FOSS, virality strengthens motivations for commercial firms to develop other solutions to similar problems, thereby increasing innovation. It may also increase the motivation of some developers to innovate and contribute to the code by advancing the vision of the FSF and its supporters in the FOSS community: that in the long run all code would be FOSS. The tradeoff is apparent : this model significantly limits the interoperability between the two spheres, which can potentially increase innovation and create significant welfare benefits. It thus enlivens the debate on the best ways to achieve allocative, productive and dynamic

77 Greg R. Vetter “Infectious” Open Source Software: Spreading Incentives or Promoting Resistance?" 36 Rutgers Law Journal 53, 200478 vetter, 2095

16


efficiency. Yet, once again, the no-exceptions stance of the GPL's virality might not always be easy to justify in light of the nature of development of the software industry. Industry reactions and possible solutions to the synergy problem will be evaluated bearing this tradeoff in mind.

Chapter 3: Industry Reactions and Possible (Partial) Solutions

Given the importance of some FOSS software to further development and innovation, and the limitations on synergies arising from the GPL's virality, the market has reacted in several ways. Such (partial) solutions can be separated into two main groups: technological and legal. Of course, the two groups are interlinked, as technological solutions are limited by legal boundaries. Legal solutions are further separated into the creation of new licenses and challenging the scope of existing licenses. The latter group is highly important, given the lock-in effect created by the widespread of viral licenses in FOSS projects. This chapter focuses on such solutions and also suggests additional ones.

A. Technological Solutions

1. "Write around" the Source Code

Copyright law protects expressions but does not protect ideas.79 Accordingly, if a good idea, which is part of a code, can be used elsewhere, albeit with a different source code, then this would not infringe copyright. Indeed, the fact that the code is open, makes it easier to understand how the code works and to "write around" it, in order to create code that achieves similar results. This implies that good ideas could possibly be used elsewhere. Notably, allowing such "writing around" is part of the balance created in copyright law between creating incentives to innovate and ensuring dynamic growth in a society which builds on new and innovative ideas.80

Yet four obstacles might limit the ability to "write around" the FOSS code- one legal and four technological. Legally, such conduct might be prohibited by contractual terms. Given the wide definition used by the GPL for works to which virality applies, some code that is otherwise not protected by copyright might nonetheless come under its contractual scope.81 This raises an important question: Is it possible to change relationships regarding the use of information within a society which were determined by copyright, simply through contractual transactions? We shall return to this important question below.

But even if the legal obstacle can be overcome, technological barriers may arise. First, the OS code might perform the task much more efficiently than a "write around" code. Second, recreating the code might be lengthy and costly.

79 Section 102(b) of the Copyright Act.80 Whether the open nature of the code changes this balance by making writing around easier is an important question, that will be addressed briefly below, but deserves an article of its own.81 cite.

17


The third technological barrier might be the most difficult to overcome: A "write around" code that only uses part of the FOSS code will lose other benefits of the FOSS code, such as frequent updates, the multi-factored integrated environment in which it operates or its large customer base. Accordingly, if the idea is best used as part of a wider code, once again the barrier might be high, if the competitor would have to develop his own integrated system from scratch. This obstacle to the realization of synergies increases as the scope and degree of internal operability of code written under viral FOSS and used by consumers is increased. The difficulties in "writing-around" FOSS code are reflected, inter alia, in the fact that commercial firms buy non-GPL licensed FOSS firms.

2. If you can't beat them, join them Another market reaction to FOSS and GPL'd-licensed software involves harnessing the power of the crowd for strategic objectives. 82 One way involves supporting OS projects which needle competitors. IBM, for example, announced that it would not enforce some of its patent portfolio against Linux users. This, in turn, enabled IBM to support the strengthening of the operating system which seemed to have the best potential to compete effectively with Microsoft's Windows operating system. Similarly, Google supported the FOSS Mozilla Foundation, which oversees of the development of Firefox, and which competes with Microsoft's internet browser.

Virality both serves and impedes such strategic goals. On the one hand, it may increase the scope of the software which is harmful to their rivals and limit the ability of such rivals to interoperate with the FOSS code, thereby increasing the FOSS' harmful effects. On the other hand, virality might inhibit further growth of the FOSS software due to limitations on possible synergies, thereby reducing its competitive pressures on rivals. In fact, the supporting firm might have benefitted from a truncated virality, which allowed some synergies, so long as they do not involve its rivals.

Another strategic conduct, which embraces FOSS for one's own purposes, involves active participation in FOSS projects. Again, IBM provides an interesting example. IBM created the a FOSS project, which involves a special team of its developers as well as peer volunteers. The project is designed to create FOSS software that makes the best use of IBM computers' unique capabilities of auto-vectorization in order to increase IBM's comparative advantage in the market for computer hardware. One might ask why create FOSS software rather than proprietary one. Several possible motivations may be relevant. First, this strategy disconnects the purchase of this specific software from hardware. Although consumers might pay for IBM's investment through the price of the hardware, perception plays an important role. One of the achievements of the FOSS revolution is a change of perception of many users: why buy software if you can receive software that was developed by a joint effort for free. By disconnecting the acquisition of the software from the hardware, IBM can increase willingness of buyers to prefer its hardware. Moreover, buyers acknowledge that IBM would have a strong incentive to continue and develop the FOSS software that is

82 http://www.nytimes.com/2009/11/30/technology/business-computing/30open.html?_r=1; Tapscott and Williams, Wikinomics: how mass collaboration changes everything 30 (2006).

18


compatible with and maximizes the use of its hardware. The second motivation is to ensure that the FOSS software in your field makes best use of your capabilities. Finally, the project allows IBM to harness the power of the crowd for its own benefit. Observe, however, that IBM does not release all of its software under FOSS. Rather, it operates two parallel systems of design, which are generally kept completely separate in order to ensure that developers are not affected by ideas taken from developers of the other type of code. The fact that all developers are employed by the same firm, allows it to supervise both projects and to ensure that those ideas that are best commercialized, are not embedded in FOSS. Yet since IBM recognizes that virality would limit the motivation to use its FOSS software, it relaxed the virality condition in the license.83 This, however, limits the ability of its FOSS to interact with GPL'd FOSS.

3. Require the user to make the linkage

In order to circumvent virality, some firms sell their software without the FOSS component. The user is then required to download it from the web and make the linkage. The wording of the GPL does not seem to cover this conduct, as it possibly comes under use of the software, which is allowed. However, as elaborated below, some FSF representatives argue that such conduct is covered by the purpose and the spirit of the GPL. This question has not been settled as of yet. Yet, even if legally allowed, this technological solution is effective only to synergies that require interoperability and not to synergies that are embedded in new products, and where such external linkage does not significantly harm the performance of the commercial software.

4. Create a technological buffer

Another way which firms employ to attempt to circumvent the GPL's virality is to architect the interface between the FOSS and the commercial code through a technological buffer, instead of a link. For example, create a software that will call the FOSS to perform a task, and then transfer the output to a commercial software. Under the common interpretation of the GPL in the industry, only the code of the "calling software" is considered a derivative work. As in the previous solution, this solution is limited to a subset of all possible synergies.

B. Legal Solutions: Changing licensing terms

1. Dual Licenses

Some FOSS communities, such as MySQL, have created a dual system of licenses for the use of their code: one with virality and one without virality which allows appropriation for fees. Indeed, the GPL does not prohibit the copyright owner from allowing the use of his copyrighted code under other licenses as well. Such duality is facilitated by the public good nature of software, which enables it to be used simultaneously by many users. The dual contracts are based on the same public good (knowledge in form of software), but the product sold is different, because of the different bundle of rights attached to it.

83 See ? below.

19


This solution has important positive social welfare effects: While still benefitting the community of users, it solves the synergy problem with commercial firms. Importantly, only those synergies that cannot be efficiently realized by the FOSS community will be realized by commercial entities, thereby creating an efficient allocation of synergy projects.

The dual licensing system also serves well the owner of the FOSS, beyond serving the wide community and enabling synergetic projects that would otherwise not be created. Interestingly, the very fact that the product is also available in FOSS form can serve the owner commercially, as it can enlarge the network of users, thereby increasing the awareness of potential buyers to its product as well as their motivation to create a synergy with it. Also, dual licensing creates a more financially viable environment for the FOSS project, thereby strengthening the possibility for its continued operation and for its ability to provide services that will further strengthen FOSS, such as setting a supervisory body that will ensure that only efficient changes to the FOSS code are embedded.84 It is noteworthy that some firms adopt a strategy whereas the code is available in FOSS has more limited features than the code that can be bought, therefore both enabling users to experience and experiment with the code creating while strengthening motivations to buy the enhanced code.

Its main downside is that it might be more difficult to harness the "power of the crowd" to such projects, unless developers are aware of the fact that dual licenses may, in fact, increase social welfare. Yet this solution is limited to FOSS projects which have not as of yet begun to operate under the GPL, or to those in which all copyright owners in the code agree to such licensing and such licensing does not clash with commitments made in other licenses.

2. Change from within: Create exceptions in the GPL

Modifying the GPL, so that it would enable the commercialization of FOSS code in exceptional circumstances, provides a good solution to the synergy problem. Such exceptions should be rare and balance between the conflicting forces observed above, and especially the importance of the synergy for social welfare and the motivations of voluntary contributors to invest in creating OS in the first place. In addition, the decision whether to grant an exception should take into account the market position of the requesting firm. On the one hand, the FOSS community should be cautious not to strengthen the "cathedrals", as they might use FOSS to preserve their competitive edge and their market power, thereby harming consumers by using the very product that was created to take them down. On the other hand, such cathedrals might be best positioned to maximize the social welfare embedded in the new ideas. The analysis should thus be a careful rule of reason.

Applying this solution necessitates the creation of a new business model, to determine the whether a specific case justifies an exemption, and what compensation should be paid for the use of the FOSS code. Most FOSS licenses empower named representatives to issue amended terms. Indeed, the GPL can be amended by the Free Software Foundation.85 Yet changing the license is not simply a formalistic legal step, but involves a deep change in 84 Vetter in Fordham85 GPLv2, section 9, GPLv3 , section14.

20


community values. Reaching a consensus on applying a less viral license would most likely be met with difficult. Such a change might not be problematic for those who, as McGowan suggests, employ the GPL terms not because it is optimal, but because of the GPL's trademark sense as a quasi-brand identity, espousing certain development procedures or ideological beliefs developers may find more important than the terms themselves.86 Yet it clashes with the ideology and vision of members of the FOSS community whose vision and ultimate goal is to create an environment in which all code is FOSS. 87 Giving away some of your best chips by allowing synergy, might be a death bed for reaching the ultimate goal.

Compensation may also be a thorny issue. Distribution of economic profits among developers would generally be problematic, given that this would change the whole motivational structure and might also be open to abuse as well as practical problems. A better solution is to use such profits to further the specific FOSS software or FOSS in general. For example, funds might be used for marketing, distribution, or even buying code that would greatly increase the operation of the FOSS by way of synergy. Funds might also be used to strengthen the internal supervision of the creation of the FOSS, to determine which parts of added code increase its value to users and which parts do not. Finally, funds might be used to seek and invest in additional synergies that have a potential to significantly increase social welfare.

Finally, to apply this solution all the copyrights in the code should belong to the entity making the exception. This might be difficult where part of the code cannot be assigned to others, as in the case of code donated under such conditions. Accordingly, a code repository would need to be built to ensure that rights of use can, indeed, be transferred to others.

3. Providing Public Funding for Synergies

In theory, the fact that a synergy can potentially increase social welfare might lead to another outcome that goes in the other direction: the use of public funding to buy the commercial code needed to create the synergetic good, and provide it under GPL limitations. This is the legal version of "if you can't beat them, join them."

Yet such a solution would meet many practical obstacles. To name but a few, a public committee that would need to evaluate the quality of possible synergies may be subject to informational obstacles as well as to pressures from interest groups. One way to reduce this problem might be to consult the community of FOSS developers. Also, given that the positive welfare effects of a synergetic product might well encompass more than one jurisdiction, there is a risk of free riding, unless all affected jurisdictions join in to finance the synergy.

86 David McGowan, SCO What?, supra note 3, at 33-34

87 Interestingly, the basic stimulus which drives developers to contribute to FOSS affects this analysis. For example, if many developers are motivated by the wish to drive out of the market large, commercial firms, then once FOSS dominates software markets such motivation might be reduced. Of course, then the challenge is to maintain such a market position, but potential competition might create weaker incentives to contribute.

21


4. Creation and Use of New Licenses

The GPL is not the only type of license available for FOSS, although it is commonly used. Indeed, the Open Source Initiative ("OSI")- a body created as a counterpoint to FSF which is less ideological and a more business-friendly voice for FOSS, seeking to combine the open source development methodology with some of the benefits commercial markets have to offer - has certified more than sixty licenses as conforming to their Open Source Definition, which verifies that the license embodies FOSS principles, but do not require virality.88 Additional licenses, not necessarily certified by the OSI, have also emerged.89 Some are stricter than the GPL, but most are more flexible. For example, the Mozilla Public License, which was created by the OSI, enables the commercial distribution of a combination of FOSS and proprietary software, without conditioning it on virality.

What provoked this outpouring of licenses? Some attribute license proliferation to author vanity. Yet the main motivation involves the inability of the GPL to allow different models of cooperation and sharing. The GCC license, for example, includes an exception to virality which applies to applications that link with the GCC libraries. This exception solves the problem created by the wide interpretation of the GPL which limits synergies resulting from a joint interface. Such licenses foster both technological and business model innovation in the information economy: they contribute to technological innovation by providing the mechanism for technology producers to collaborate and share ideas, works, and inventions in a variety of creative ways, and contribute to business model innovation by providing the basis for technology producers to distribute their products to users through a wide range of mechanisms and channels.90

Yet, while such new licenses can solve problems inherent in viral licenses, they do not solve the problems of software already licensed under viral licenses, or software which seeks to create synergies with it.

In addition, license diversity also carries costs. Indeed, the OSI has indentified the issue as one of its most strategic matters.91 The loss of standardization increases the information costs of both the user and the developer, who must understand the intricacies of and choose among the different licenses which are relevant to their actions.92 Such costs might harm not only the specific user or developer, but also the whole FOSS community, as they might make FOSS licenses less attractive. Indeed, the continued domination of the GPL license might be attributed, at least in part, to the wish to limit such costs.

Another cost involves determining the license terms for a bundle of FOSS programs, which are protected by a variety of different license terms. The distributor of such a bundle must 88 http://www.opensource.org/docs/definition.php__(open source initiative).89 Robert W. Gomulkiewicz, Open Source and Proprietary Models of Innovation: Beyond Ideology: PART III: Open Source and Proprietary Software Development: Open Source License Proliferation: Helpful Diversity or Hopeless Confusion?, (2009) 30 Wash. U. J.L. & Pol'y 261

90 Grumelwotz...91 Foot 15 in Grume...92 NIva.; gomu...

22


determine whether the licenses permit the code to be combined in the package and which rights and obligations must be passed downstream.93 Yet while synergies might be limited when the synergetic codes are licensed under incompatible terms, the situation might still be better than if all code was licensed under viral terms .94

C. Legal Solutions: Challenging Viral Licenses under Public Policy

Like all other licensing restrictions, GPL restrictions are subject to scrutiny under a number of different statutes and legal theories, including copyrights, antitrust, and laws against unfair contractual terms. This section explores the two most relevant, copyright laws and antitrust.

1. Challenging the scope of Virality under Copyright

The GPL requires that all "derivative works" or "work based on" the code also be licensed under the GPL.95 Accordingly, an important issue involves the definition of such works.96 For example, if a software only creates a reference to a GPL'd library that would be activated in run-time and does not incorporate any part of the GPL'd code in its own code- will it be considered a work covered by the GPL? Or if the proprietary software only exchanges information with the GPL'd software- does this fall under the GPL? The scope of the GPL and its virality are crucial as nearly all programs today include external components, such as libraries, interfaces, plug-ins, etc. and interact or interoperate with other programs.97

While the FSF generally adopts a wide interpretations of the GPL, some scholars, firms and organizations98 have challenged this view and have argued for a narrower scope. Such an interpretation would allow for more synergy, although it would not solve the problem of completely. The relevant legal analysis regarding the scope of the GPL involves two interrelated questions. First is a factual question: what is covered by the GPL. An important source is, of course, the wording of the GPL itself. Yet the GPL has multiple and sometimes conflicting definitions regarding what it considers falls within its obligations.99 Additional sources are the guidelines and answers published by the FSF,100 especially those which were published before the license was applied in practice. Finally, since the GPL contains some terms of art, their interpretation by legislators and courts may also be relevant.

The second question is legal: if the works covered under the GPL are wider than those protected by copyright and thus restrict otherwise unrestricted acts, what takes precedence. In other words, does the creator of a code have contractual control over his work which 93 Grum, 282.94 iD., FOOT 95/ This problem is especially pronounced in the GPLv2 because it does not permit programmers to add additional conditions to the GPLv2-licensed code. GPLv3 addresses this, but only to a limited degree95 SEctions 2 and ? of the GPLv296 Many have written on this issue. See, e.g., Bain, Malcolm (2010) 'Software Interactions and the GNU General Public License', IFOSS L. Rev, 2(2), 165. http://www.ifosslr.org/ifosslr/article/view/44.97 linking document, p. 45:98 For example, the Freedom Task Force created a Software Interactions Document, the aim of which is to provide some general guidance to lawyers and developers working with free software.99 ifoss, The Free Software Foundation, drafter of GPLv2, gives its view on the issue in the GPL-FAQs.100 FSF website

23


extends beyond that granted by copyright. 101 This is an open question which creates much uncertainty in the market. It is of much importance, since under the FSF's interpretations, the GPL magnifies the rights of the code author beyond that granted by copyright.102 This interpretation is at odds with the attempt of courts to narrow the definition of derivative works, especially for code written to be compatible with underlying original works. This trend toward stricter tests for derivative works contradicts the GPL’s broad assertions of protection for works based on GPL code. Courts are unlikely to reverse course on copyright protection just to fit the GPL. 103

Since the work was created by the author, it might be argued that he should be allowed to determine on what terms he would like to offer it for use by others, especially when the other party agrees to these terms by accepting the license. This argument has, in our view, an inherent flaw, since exclusivity is not an inherent characteristic of the work, but is rather a legal creation, created by copyrights. Yet copyrights, in themselves, incorporate an inherent balance between the state-granted exclusivity which strengthens motivations for creativity and the creation of a public domain for unprotected works, that would facilitate further creativity, a balance which rests on public policy.104 To put it differently, copyright is a "deal" between the author and the state, which draws the boundaries of exclusivity and of the public domain in accordance with public policy. Therefore, by privately extending his rights beyond those granted by copyright, the author is overthrowing the delicate balance reached with regard to the use of information within a society.105 Thus understood, any author restricting the use of works in the public domain is also limiting what he does not own.

We should still check whether FOSS should be treated differently than other creative works, including commercial code, since the "deal" reached in copyright law is not sufficient to motivate its creation, due to its unique characteristics. The most relevant characteristic is the open nature of FOSS, which makes it easier for others to write around the code and might thus limit incentives to create the code in the first place. To make such an argument one would first need to prove that the motivations for the creation of FOSS are even lower than those of a commercial firm operating under similar copyright protection boundaries. Such proof might not be easy, as for commercial firms the bottom line of profit rests almost exclusively on what they can charge for and is not in the public domain. Even if it could be proven, the effect of the boundaries on incentives to create FOSS would have to be balanced against the synergy argument: any limitation imposed on the scope of works in the public domain, limits possible synergies between different products. Yet the analysis does not stop here. Even if FOSS indeed justified a different balance than that provided by copyrights, this would not imply that the change of such boundaries should be done through private contracting rather than though a legislative process that would ensure that all public policy

101 Niva Elkin-Koren, Exploring Creative Commons: A Skeptical View Of A Worthy Pursuit, The Future Of The Public Domain (P. Bernt Hugenholtz & Lucie Guibault, eds.) Kluwer Law International, 2006.102 See also Bond. 103 Haas104 See, e.g., Kenneth Dam, "Some Economic Considerations in the Intellectual Property Protection of Software" 24 J. of Legal Stud. 333 (1995).105 NIva.

24


concerns are addressed. Indeed, as one of us elaborated elsewhere, due to externalities, private ordering cannot be relied upon to protect the public interest.106 Moreover, even if externalities were absent, the bargaining position of the two sides might affect the outcome, once again not reaching the optimal point.

Accordingly, in our view, the GPL cannot enlarge the scope of covered work beyond that which is granted by copyright. If our view is accepted, there is no need to analyze the first question posed above, which relates to the GPL's scope, unless the GPL is narrower than copyright. Nonetheless, since this question was not as of yet answered by courts, the analysis below continues under the assumption that the GPL can extend the scope of rights granted to the code author beyond those granted by copyright.

On the question of the scope of the GPL there is much debate. There seems to be agreement on some types of interactions that come under its scope, such as statically linked programs, where the GPL'd code constitutes an integral part of the new software at the development stage. There also seems to be agreement that other types of interactions are not covered by the GPL. For example, pipes, sockets and command-line arguments which are communication mechanisms normally used between two separate programs generally do not come under its scope.107 Yet there is no agreement on many other types of interactions.

One of the most important and hotly debated issues is whether dynamic linking is covered by the GPL. Dynamic linking occurs when the content of external programs or library files ("external programs") is not copied into the new software, but instead the software refers to those external programs in its code. When the software is run by its user, the external programs may be “called up” and executed. This means that neither the source code of the software nor the compiled and linked executable of that software contain the source code of the external program. Although the external program is linked at run-time, this is only created in the user's computer memory. The question of whether the GPL applies to dynamically linked software is crucial for synergy based on interoperability, which is an important way in which software market evolve.

Some have argued that since the external program is only reproduced and distributed at run time, it is not covered by the GPL. On the other hand, the FSF applies a wide view, which rests on two arguments:108 that the plug-in to the external program is an integral part of the new software, thus the new software is not an “independent and separate” work in itself; and the new software is interdependent on the GPL'd code, since it was designed and written to include and use the functionalities of the external program. As Bain notes, neither of these argument are strong, as the new software could be written to a public interface and use the GPL'd library as an implementation (among others) of that interface. In addition, writing code to use an external program could be considered merely “using” the library in the intended manner covered by the GPL's license conditions. Moreover, if the program can

106 NIva, near 55, book. 107 See FSF FAQ...108 IFOSS

25


run other external programs with similar functionalities, the dependency argument is much weaker. These questions have yet to be determined by courts.109

Yet some features make it quite difficult to challenge the scope of the GPL. First, there is no clear-cut answer in copyright as to what constitutes a “derivative work.” This results, inter alia, from the fact that copyright laws were not created for software, and thus often produce unclear results with regard to the scope of their application. Second, given that disputes are based on technology-intensive facts, there is an inherent risk of indeterminacy in characterizing the underlying facts.110

Third, while the use of technology is not restricted by national boundaries, copyright is a national right and therefore national laws determine its scope in each jurisdiction in which the issue arises. The scope of copyright protection may not be similar for all jurisdictions using the software licensed under the GPL.111Another complication is created if the GPL is considered a contractual document, to which varying jurisdiction-specific rules of contractual interpretation may apply.112 Accordingly, as the number of jurisdictions in which software is designed to apply increases, so does the risk of a GPL infringement, or at least the costs of determining the height of such a risk.

A fourth obstacle involves the height of the penalty. At minimum, the infringer would most likely be mandated to withdraw the infringing product and damages might also be granted. As a result, creative and distributive efforts might be lost. Interestingly, in the few cases brought by the FSF, which were settled out of court, agreed upon sums were not disclosed. This creates a continued vagueness of the extent of risk involved in such infringements. Moreover, and sometimes even more importantly, the penalty for such a challenge is not merely legal. Rather, an important effect is reputational. The GPL is backed by a vociferous community (or possibly just a vocal minority of its members) which invests effort in detecting possible violations and strongly voicing its opposition to the relevant communities.113 Such peer pressure uses two primary techniques: chastisement and denigration. Accordingly, while the battle is over legal interpretations, it is mostly fought outside the courts, on the Internet, in blogs, sites, and documents.

Finally, while the FSF acts as a community with shared interests, private parties face a collective action problem, where each firm, on its own, would not bear the costs and risks of challenging the interpretation of the FSF to the GPL, although it would have such a 109 Bain110 Vetter, rutgers, citing to MELVILLE B. NIMMER & DAVID NIMMER, NIMMER ONCOPYRIGHT § 13.03[A][1][d], at 13-51 (2003) (“[T]he uncertainty created by the ad hoc nature of the software cases . . . hampers development and progress in the computer software field. Software developers have no adequate guidelines regarding what level of independent development is required to avoid copyright infringement.”).111 for example, the US 9th Circuit Abstraction-Filtration-Comparison test for the determination of whether the new work is protected under copyright law would not necessarily - or at all - be used by courts in Spain or France to determine copying or creation of derivative works. IFOSS, near foot 14.112 Bain, foot 29.113 See, e.g., the http://gpl-violations.org which works together with the FSF to search for violations.

26


motivation if all firms joined forces and shared costs and risks. Accordingly, Firms are reluctant to be the first take to court the hard cases. Interestingly, the FSF has not brought hard cases that could have clarified such issues to court and instead focused on cases with outright infringements.114 This might well be an intended strategy, aimed at preserving the risks resulting from the vagueness discussed.

We conclude this sub-chapter by noting another difference between copyright and patent law, which is relevant here. Unlike patent law, copyright law does not provide for a possibility of compulsory licenses.115 Yet given the economic role of software, which is often more similar to patented inventions than to traditional copyrighted works such as books and plays, the rationales for such licensing might also be relevant. A way should thus be sought to allow synergies in those rare cases where a compulsory license would have been granted if patent law applied.

2. Compulsory Licenses: Virality as an antitrust violation?

[very rough draft. this part is not as of yet well thought through. please give very little weight at this stage]

An interesting and important question is whether antitrust places some limitations on the virality of the GPL. The question is interesting because FOSS created a new model of production in markets, which is not necessarily based on monetary profit, whereas antitrust doctrines were designed to apply in for-profit markets. Antitrust, whose major task is to ensure that no artificial barriers to competition are created, may thus be relevant. Should we find such artificial barriers, the next question to be asked is whether antitrust's existing rules are fit to the task, or whether dealing with FOSS might require new thinking in established antitrust doctrines.116

We assume that the FOSS software does not enjoy a monopoly position in its market and raises no concerns of attempted monopolization, an assumption which generally holds true.117 Accordingly, we focus on the prohibitions against agreements in restraint of trade.118

The first question to be determined is whether the GPL is a horizontal or a vertical agreement. Where the software is developed by a community of FOSS developers, it has elements of a horizontal agreement. Yet the unique nature of some FOSS projects challenges this view. This is because in the peer collaborative model, developers are usually not potential rivals, but rather parties to a joint collaborative effort that would not otherwise

114 straight forward cases such as against verison and busybox- simply copied and used os code115 Gustavo Ghuidi.116 Predatory pricing serves as one example, where established doctrines require monetary recouperation of costs, a condition which is not relevant when the product is distributed for free. See, e.g., Daniel Wallace vs. IBM Inc., Red Hat Inc., and Novell Inc. (no. 06-2454, 7th cir., Nov. 9 2006). 467 F.3d 1104 (7th Cir. 2006).117 For some discussions of monopoly violations see, e.g. See Charles M. Gastle & Susan Boughs, Microsoft III and the Metes and Bounds of Software Design and Technological Tying Doctrine, 6 VA. J.L. & TECH. 7, 39–43 (2001) (discussing technological tying violations); ? on predatory pricing.118 Section 1 of the Sherman Act; Section ? of the FTC Act.

27

http://en.wikipedia.org/wiki/Case_citation

http://en.wikipedia.org/wiki/Case_citation


compete with each other.119 The more relevant relationship is vertical, as the GPL creates an arrangement between the owner of the FOSS and the user. This implies that the GPL would be analyzed under a rule of reason, given that vertical agreements generally raise less anti-competitive concerns relative to horizontal agreements.

The second, and more fundamental issue, is whether the GPL's virality condition creates an antitrust injury.120 Should anti-competitive effects be found, it would then need to be determined whether the pro-competitive benefits of FOSS can be achieved by adopting some less restrictive alternative.

In Wallace, the 7th circuit found that the GPL does not restrain trade. Rather, it is a cooperative agreement that facilitates production of new derivative works, and as such is lawful.121 Yet the focus of the court was not on virality, but rather of the fact that the code was distributed for free. The court's analysis thus leaves the door open for future analysis of claims that certain GPL conditions pose a threat to welfare in the long run. We shall thus focus on the effects of virality.

The first stage of the analysis is determining whether virality creates anti-competitive effects. As noted above, virality creates potential harmful effects on social welfare by reducing quality. Most importantly, it limits potential synergies between FOSS and commercial code. The more dominant viral FOSS in its market, and the wider the extent to which such virality applies, the stronger this effect. An important issue regards the scope of the antitrust injury: whether the focus is on the competitive process itself, or whether it also encompasses the outcomes of competition: low prices and higher quality products. For the purposes of this analysis, we shall assume that it encompasses both effects, and thus an antitrust injury arises.122

The next stage of the analysis determines whether virality serves a pro-competitive purpose that is sufficient to offset the anti-competitive harm. Indeed, as elaborated above, viral terms limit appropriation by other entities and facilitate the spread of FOSS code, thereby strengthening motivations for collaboration in FOSS production. Virality also strengthens pro-competitive pressures in the markets in which they operate, thereby possibly increasing quality and reducing price.

Yet such pro-competitive effects do not automatically justify virality. Rather, it should be determined whether there exists a less restrictive alternative that would still ensure that

119 Note that developers generally do not compete among themselves in the software market, although they may compete on the provision of software development services for firms which compete in software markets. Exceptions may arise, for example, when competitors join efforts to create a FOSS. See, e.g. Maurer. 120 United States v. Trenton Potteries Co., 273 U.S. 392 (1927) .121 Wallace122 Anticompetitive effect has been described as a reduction of output, increase in price, or deterioration in quality of goods and services. Generac Corp. v. Caterpillar Inc., 172 F.3d 971, 978 (7th Cir. 1999); Wilk v. Am. Med. Ass’n, 895 F.2d 352, 360-62 (7th Cir. 1990); United States v. Brown Univ., 5 F.3d 658, 668 (3d Cir. 1993).

28


(most) pro-competitive effects are realized, while limiting anti-competitive effects, to create a better balance. In other words, it should be determined how narrow need virality be to still ensure the pro-competitive effects of FOSS: what works should it encompass and what duties should it impose on the user of such works.

The works covered At minimum, it should encompass the FOSS code in its entirety, which is also protected by copyright. But given the special nature of software, which enables parts of the code to be copied and used in other software, viral clauses may also have to apply to parts of the code. Yet not all parts of the code should be automatically protected. If we assume that copyright correctly balances public policy considerations, virality should be not be allowed to encompass any type of work in which the author does not enjoy exclusivity. Accordingly, parts of the code should also be allowed to come under virality, so long as they are not exempt under copyright. It is much more questionable whether virality should apply to code that does not come under the protection of copyright laws, such as code that creates dynamic linking. The burden of proof that including such code will indeed serve social welfare rests on those who make such claims. The popularity of much more limited FOSS licenses may provide evidence that even narrower viral terms are enough to create FOSS collaborations.123 It would need to be proven that such licenses benefit social welfare less than the GPL. The duties imposed The second dimension regards the strength of virality: whether the strong version, included in the GPL is broader than required to achieve the protected code's pro-competitive effects. Indeed, the existence of the LGPL that allows commercial software to dynamically link to FOSS libraries indicates that strong virality is not necessarily needed in order to protect the FOSS.124 But more importantly, as noted above strong virality might sometimes limit the pro-competitive effects of FOSS rather than further them, especially when compared to less strict alternatives. Indeed, relaxing virality might increase FOSS proliferation, as it would create motivations for more firms to use it. It might also increase motivations to contribute to FOSS creation, since the code could then further both social welfare and benefit the FOSS code in a better way.

Accordingly, a case can be made for challenging the GPL's viraity under antitrust laws. Yet such a case would need to overcome significant realistic problems, given courts’ reluctance to second-guess software designers’ architectural and motivational choices. A further obstacle is created by the reluctance to facilitate cooperation, where at last one of the parties seems reluctant to do so. Yet this argument can be counteracted, at least in part, by the fact that it is virality itself and the GPL's first-mover advantage which limited the choices of many FOSS projects to use other, possibly preferable, licenses.

Should we find an antitrust violation, a copyright misuse could possibly also be proven, since most elements of such an offense generally go along the same line as antitrust violations.125

123 Maurer near foot 142, for the analysis of additional types of licenses. 124 Maurer. 125 See, e.g., Christian H. Nadan, Open Source Licensing: Virus or Virtue?, 10 TEX. INTELL. PROP. L.J. 349, 368 (2002). Cf. Robin Feldman, The Open Source Biotechnology Movement: Is It Patent Misuse?,

29


Chapter 4: Conclusions

FOSS has emerged as a major cultural and economic phenomenon. The paradigmatic shift in the ideology regarding the openness of the source code and the freedom to modify it was accompanied and facilitated by a change in production models, towards collaborative and often voluntary peer production.126 These changes brought about significant benefits to social welfare, resulting, inter alia, from increased innovation and pro-competitive pressures in many software markets.

The GPL has emerged as the main legal tool used to facilitate non-commercial FOSS projects. It incorporates several public domain licensing features. Most importantly, it grants anyone the freedom to use, distribute and modify the OS. It also includes a unique condition: an viral term, which requires that any work based on the code or derived from it must also be licensed under the GPL, including granting others the right to use it. This virality condition serves several important purposes: it limits the ability of commercial firms to appropriate the source code, it may strengthen the incentives of some developers to contribute to FOSS, and it contributes to the spreading of FOSS .

At the same time, however, it creates potentially negative welfare effects. Its extremity, which allows no exceptions to its virality, creates (at least) two separate and competing spheres: GPL'd FOSS and proprietary code. Competition between different spheres carries many advantages, since it creates motivations to build "the better mouse trap". Yet by completely separating both spheres, it prevents possible symbiotic commercial/open source software synergies and sometimes even synergies between different types of FOSS, thereby limiting synergetic development and innovation. Accordingly, the extremity of the virality condition and the wide interpretation given to it by the FSF may be social welfare reducing. In addition, it does not necessarily serve the FOSS movement, as it blocks some important ways for growth and for FOSS to enhance social welfare.

[Conclusion subject to change in next drafts: This article analyzed technological and legal responses to virality. As shown, most responses are partial and do not solve the synergy issues, but only possibly limit them. Only the relaxation of the GPL's virality condition, or a significant change in its adoption patterns in FOSS projects- possibly facilitated by the understanding of the effects of its extremity on social welfare- can bring about the needed change.

Until then, the GPL's virality condition serves as an important obstacle to the vision of a hybrid economy , in which integration of peer production and commercial entities will become the dominant architecture for commerce on the internet, affecting future innovation.127 Indeed, as technology development progresses, and as FOSS becomes more

6 MINN. J.L. SCI. & TECH. 117, 118 (2004); Greg Vetter, Infectious Open Source Software: Spreading Incentives or Promoting Resistance?, 36 RUTGERS L.J. 53, 143 n.229 (2004) ( arguing that the possibility of copyright misuse increases when GPL terms are interpreted broadly).126 Eric von Hippel, Democratizing Innovation 99 (2005), available at http://web.mit.edu/evhippel/www/democ1.htm127 Lessig

30


prominent in software markets, the social welfare price paid for the prevention of synergies may increase. To give but one example, GPL'd OS might create issues for cloud computing. Under this new model computing tasks, such as storage of information the management of free-flowing digital information would be done on large-scale systems that connect many computers, rather than desktop computers or in corporate computer centers. Yet incorporating computers which use GPL'd FOSS into the new system would not be possible, it if triggered the virality condition, thereby limiting the ability of cloud computing to provide efficient solutions for existing problems. ]

31

prof. michal s. gal and prof. niva elkin-koren: the dark...

Documents