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.
Introduction
Chapter 1: The development of open source
The Legal Framework: GPL
Chapter 2: The Welfare Effects of Virality
A. Possible Positive Effects of Virality
B. Possible negative welfare effects of virality: Limiting Synergies
C. Partial Conclusion: The Tradeoff
Chapter 3: Industry Reactions and Possible (Partial) Solutions
A. Technological Solutions
1. "Write around" the Source Code
2. If you can't beat them, join them
3. Require the user to make the linkage
4. Create a technological buffer
B. Legal Solutions: Changing licensing terms
1. Dual Licenses
2. Change from within: Create exceptions in the GPL
3. Providing Public Funding for Synergies
4. Creation and Use of New Licenses
C. Legal Solutions: Challenging Viral Licenses under Public Policy
1. Challenging the scope of Virality under Copyright
2. 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
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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, Fordham
6
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-oflinux-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
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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
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, fordham
11
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
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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.
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 nonmarket 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
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 platforms
16
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 ‘gift
culture’ (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
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
freedom appealed to many software developers who believed that source code should be
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.
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
NIva
23
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.
19
5
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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-553
28
THE 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
Niva
33
The Free Software Foundation promotes the GNU General Public License (GPL) for software
The 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
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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
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-PriceFixing 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
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
anyone to deny 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.
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.
41
8
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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.
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.
45
9
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
(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
51
Tzur and David, 28-9.
See also Maurer
53
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=1
52
10
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
new features and the provision of better solutions to existing problems.56 Quality may also
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 highprofile 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
56
Maurer, near 25.
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.
57
11
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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
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.
63
Bond
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).
64
12
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
B. Possible negative welfare effects of virality: Limiting Synergies
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
66
Tzur and David, 32; Vetter
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
67
68
See, e.g., ....
13
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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
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
69
By license compatibility we mean that license terms do not clash with each other.
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.
70
14
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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
[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 GPLinfringing 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
71
Tzur and David, 34.
Harakd Welte, More thoughts on FSF action against Apple over GNU Go, June 15, 2010.
72
73
check again.
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.
74
15
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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
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
77
Greg R. Vetter “Infectious” Open Source Software: Spreading Incentives or Promoting Resistance?"
36 Rutgers Law Journal 53, 2004
78
vetter, 2095
16
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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
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.
79
Section 102(b) of the Copyright Act.
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.
80
17
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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.
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
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
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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
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
83
See ? below.
19
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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.
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.
84
Vetter in Fordham
20
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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
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."
85
GPLv2, section 9, GPLv3 , section14.
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
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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.
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
88
http://www.opensource.org/docs/definition.php__(open source initiative).
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
89
90
91
Grumelwotz...
Foot 15 in Grume...
22
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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
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
92
NIva.; gomu...
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 degree
95
SEctions 2 and ? of the GPLv2
96
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.
93
23
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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
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.
100
FSF website
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
Haas
104
See, e.g., Kenneth Dam, "Some Economic Considerations in the Intellectual Property Protection of
Software" 24 J. of Legal Stud. 333 (1995).
105
NIva.
101
24
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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
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
106
107
NIva, near 55, book.
See FSF FAQ...
25
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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 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
108
IFOSS
Bain
110
Vetter, rutgers, citing to MELVILLE B. NIMMER & DAVID NIMMER, NIMMER ON
COPYRIGHT § 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.
109
26
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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
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
113
See, e.g., the http://gpl-violations.org which works together with the FSF to search for violations.
straight forward cases such as against verison and busybox- simply copied and used os code
115
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).
114
27
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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
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 anticompetitive 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
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.
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
Wallace
28
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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
(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
122
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).
123
124
Maurer near foot 142, for the analysis of additional types of licenses.
Maurer.
29
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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
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
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?,
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.htm
30
Gal & Elkin-Koren
The Dark Side of Viral Open Source
Draft, May 23, 2011
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
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. ]
127
Lessig
31