Content uploaded by Massimo D'Antoni
Author content
All content in this area was uploaded by Massimo D'Antoni on Sep 11, 2014
Content may be subject to copyright.
COPYLEFT LICENSING
AND SOFTWARE DEVELOPMENT˜
Massimo D’AntoniyMaria Alessandra Rossiz
Dipartimento di Economia Politica, Universit„a di Siena
Piazza S. Francesco 7, 53100 Siena (Italy)
September 27, 2007
˜We thank Simone Piccardi for his help and encouragement, and for providing invaluable in-
formation on the open source world, and Sam Bowles for his comments and suggestions. We also
thank participants to the Siena-Toronto-Tel Aviv workshop on law and economics, to the ISNIE
conference 2007 and to the EALE conference 2007. However, all errors remain ours.
yEmail: dantoni@unisi.it
zEmail: alessandra.rossi@unisi.it
Abstract
This article aims at clarifying the role played by licenses within the increas-
ingly relevant Open Source Software (OSS) phenomenon. In particular, the
article explores from a theoretical point of view the comparative proper-
ties of the two main categories of OSS licenses|copyleft and non-copyleft
licenses|in terms of their ability to stimulate innovation and coordination
of development e¸orts. In order to do so, the paper relies on an incomplete
contracting model. The model shows that, in spite of the fact that copyleft
licenses entail the enjoyment of a narrower set of rights by both licensors and
licensees, they may be preferred to non-copyleft licenses when coordination
of complementary investments in development is important. It thus provides
a non-ideologically-based explanation for the puzzling evidence showing the
dominance, in terms of di¸usion, of copyleft licenses.
Keywords: intellectual property rights, open source, copyright, copyleft,
GPL license, incentives to innovation.
JEL classification: L17, O34.
1. Introduction
Open Source Software (OSS) has reached a signi˛cant extent of market penetration
in recent years. A June 2006 report by research ˛rm Gartner suggested that OSS
would take away 22% of the traditional software market over the next ˛ve years. In
July 2006 IDC estimated that OSS held 7% of IT software revenue and projected
an increase to 15% of IT software budgets in the next four years. Considering
that a signi˛cant part of OSS products is distributed for free, the latter projection
may well underestimate the extent of OSS di¸usion. Moreover, OSS is the market
leader in the web server segment, where Apache holds about 50% of the market
according to the latest Netcraft survey (September 2007) and holds relevant market
shares in the mail server market (47,8%, according to the FalkoTimme mail server
survey) and in the database market (33% of European ˛rms use OSS databases,
according to IDC).
Economic scholarship has kept up with the pace of OSS market di¸usion, ex-
ploring a wide range of OSS-related issues and reconciling many apparently puz-
zling characteristics with conventional economic analysis (for a survey, see Rossi,
2006). Yet, a few relevant issues|and particularly the role played by licenses|
remain under-researched. Indeed, the search for economics-based explanations for
the OSS phenomenon has led to the identi˛cation of features, such as the inter-
play between intrinsic and extrinsic motivations to contribute, that may make
appear the very existence of licenses redundant, so that OSS is often assimilated
to software in the public domain.
However, although it is usually freely available to anyone who cares about
making use of it, OSS di¸ers from software in the public domain in that it is
protected by copyright and distributed under various sorts of licenses that may
set restrictions to its redistribution. The rationale for the existence of various
sorts of licenses is also still relatively unclear. Indeed, OSS licenses vary greatly
1
as regards the amount of restrictions they impose on licensees. In particular, so-
called copyleft licenses grant developers a narrower set of rights with respect to
non-copyleft licenses and thus dramatically reduce their ability to pro˛t from the
direct sale of the software and make more di‹cult the combined commercialization
of OSS and proprietary software programs.
In this regard Maurer and Scotchmer (2006), for instance, note that:
\[T]he need for licenses is not entirely obvious nor, assuming that li-
censes are needed, is it clear which restrictions are necessary or de-
sirable. From a welfare standpoint, the best way to ensure use and
re-use of software would be to place it in the public domain without
any license at all." (p. 17)
Thus, it is not entirely clear whether licenses play a role in ensuring the viability
of OSS nor is it clear whether di¸erent types of OSS licenses do have di¸erent
implications for the pace and dynamics of development.
In this paper, we aim to contribute to the understanding of the OSS phe-
nomenon by focusing on the role licenses play within OSS projects, and particu-
larly on the comparative properties of the copyleft and non-copyleft licenses (as
exempli˛ed respectively by the GPL and the BSD license, the most popular in
their classes). We build a formal model that takes as a starting point the recogni-
tion of the speci˛c nature of the investments in software development{an aspect
too often overlooked{and the associated ex-ante ine‹ciencies in the investment
choices arising as a consequence of contractual incompleteness. The model high-
lights the implications in terms of incentives to invest in software development of
the alternative property rights allocations realized through di¸erent OSS licenses.
The model shows the (perhaps counterintuitive) result that, in spite of the
fact that copyleft licenses impose more stringent restrictions on both licensors’
and licensees’ residual rights of control relative to non-copyleft licenses, they may
induce higher levels of coordination of investment and thus be preferred to non-
2
copyleft licenses in order to enhance the degree of co-speci˛city of the investment
e¸orts. In so doing, it allows both to shed light on a number of empirical observa-
tions that have so far escaped theoretical scrutiny and to provide insights on the
implications of di¸erent OSS licensing choices for ˛rms.
The incomplete contracting framework we adopt is loosely related to the \GHM
approach", namely the collection of contributions by Sanford Grossman, Oliver
Hart and John Moore (Grossman and Hart, 1986; Hart and Moore, 1990; Hart,
1995), and to the other few contributions that have applied some insights from
the GHM approach to the analysis of issues arising in innovative contexts (see,
e.g. Aghion and Tirole, 1994; Arora and Merges, 2001). Di¸erently from the GHM
approach and from the other mentioned contributions, however, we introduce an
additional dimension to the choice of investments by agents. While in GHM-style
models agents choose only the level or intensity of speci˛c investments, agents
in our model may choose both the intensity and the degree of complementar-
ity/speci˛city of investments1. Adding this further dimension is important be-
cause our focus is on contexts of cumulative innovation in which it is important
to assess not only the intensity of incentives to invest but also the extent of co-
ordination of investment. This, in turn, implies that in evaluating the e¸ects of
di¸erent licenses their impact on both of these dimensions should be taken into
account.
The paper is organized as follows. Section 2 explores the very rationale of
the choice of opening the source code. Section 3 describes the principal types
of OSS licenses, introducing the di¸erence between copyleft and non-copyleft li-
censes. Section 4 presents a formal model that captures the main elements of the
comparison between copyleft and non-copyleft licenses. Section 5 discusses the
main results of the model, introduces some stylized facts on which the model may
shed light, and concludes.
3
2. The choice of opening the source code
The de˛ning characteristics of OSS are (a) the free availability of its source code,
i.e. of the human-readable instructions expressing the di¸erent tasks that have to
be performed by the computer, and (b) the nature of the license under which it
is distributed, which grants licensees a number of rights, namely the right to use
(run) the program, to study how it works, to modify and improve it, to redistribute
it with or without modi˛cations2. Of course, the ˛rst condition (free access to the
source code) is a precondition for the second in that no improvement is possible
in absence of access to the source code3.
It is important to note that the choice to release a piece of software under an
OSS license does not involve giving up the copyright over it. This distinguishes
the choice to distribute the software under an OSS license from the choice to re-
lease it in the public domain4. The release of the software in the public domain
entails that the consent of the author of the software is no longer required for third
parties to use and modify it. The same result is achieved by OSS licenses through
contractual means, rather than through renouncing to property altogether. How-
ever, di¸erently from public domain software, by using an OSS license the licensor
may impose speci˛c restrictions to some aspects of the redistribution of the soft-
ware. This will become clearer in what follows and will play an important role in
explaining the comparative properties of di¸erent types of OSS licenses.
Of course, in any case opening the source code reduces the extent to which
the developer of the software licensed under OSS terms (or any other software
developer) may pro˛t from the direct sale of it, although important di¸erences
exist in this regard in relation to the speci˛c type of OSS license chosen (on which
more will be said in the following section). The question therefore arises of why
a rational individual would ever choose to release her software under an OSS
license. This question|a \puzzle" for many|has been for long prominent in the
4
literature on OSS. Answers range from the identi˛cation of the reputational and
signalling bene˛ts of contributing to OSS projects (Lerner and Tirole, 2002), to the
recognition of bene˛ts in terms of satisfaction of speci˛c user needs (von Hippel,
2002; Johnson, 2002), to the pinpointing of various sorts of intrinsic motivations,
including the enjoyment of programming per se (Moglen, 1999) and an ideological
commitment to the norms of OSS communities and the very idea that source code
should be open (Raymond, 1998; Bergquist and Ljungberg, 2001).
In this paper, we disregard ideological explanations for the choice of an OSS
license by focusing on the incentives of pro˛t-oriented individuals or ˛rms, inter-
ested in maximizing the value of the software they work with5. For this sort of
agents, opening the source code is crucial to enable investment by multiple par-
ties with heterogeneous human capital. Indeed, the combination of free access to
the source code and the wide scope of rights over the licensed software creates an
opportunity for multiple agents to have simultaneous access to the same software
program and eventually invest in its development. This is particularly relevant
in light of two characteristics of software development: cumulativeness and in-
vestment speci˛city. These characteristics imply that, although an OSS strategy
reduces the pro˛ts from the direct sale of the software, it might entail greater
bene˛ts than costs6.
Consider the two aspects in turn. First, an OSS strategy entails important
technical bene˛ts in a context of cumulative innovation such as software develop-
ment. Software innovation is strongly incremental, i.e. it results from a cumulative
process in which improvements build on previous versions and developers rely both
on their own and on others’ existing designs and examples in order to incorporate
them into new programs or adapt them to serve new purposes.
Cumulativeness implies that a given software constitutes the input into further
development e¸orts. In this context, it is technically possible to independently
develop two programs or software modules meant to be used jointly without hav-
5
ing access to the source code as long as some instructions on the realization of
interfaces are provided by the licensor of the original software input. However,
in keeping the source code secret, important gains in technical e‹ciency are fore-
gone. By opening the source code, by contrast, improvements and complementary
programs can be developed in a way that increases the value of joint use of the
software and optimizes the interaction between the di¸erent programs/modules.
In particular, only if the source code of a given software is open it is possible to
coordinate the development e¸orts of di¸erent agents operating in a decentralized
fashion (i.e. outside of the boundaries of a ˛rm). In addition to this, access to the
source code can bring about as a side e¸ect improvements in the form of bugs or
error corrections or of the provision of more substantial additions.
Secondly, the existence of an incentive to open the source code may become
even more apparent in light of the fact that investments made in the development
of a given software program are speci˛c. That investments in software development
are speci˛c is a truism too often overlooked in analyses of software innovation that
we think is crucial to understand both an initial developer’s decision to release
a piece of software under OSS terms and the decision by other developers to
subsequently contribute to the improvement of that software7.
Investment speci˛city implies, on one side, that developers may pro˛t from
the sale of complementary services or customized solutions that include but do
not coincide with the software program8. On the other side it implies that, in
a context of cumulative innovation, they are interested in having access to the
software they invest in also in the future. Indeed, being denied access to future
versions of the software in which they have made investments would imply the
loss of these investments.
Now consider how the two aspects|investment speci˛city and cumulative-
ness|interact. Cumulativeness entails that (a) the initial innovation(s) on which
improvements build upon is (are) always totally or partly incorporated into the
6
˛nal output; or that (b) even if not incorporated, the initial innovation has to be
available to developers/consumers in order for them to be willing to use/buy the
program. As a consequence, if the original innovation input enjoys legal protection
in the form of patents or copyright and unless its improver is given ex ante a de˛ned
set of rights to modify and redistribute modi˛cations of the input, development
through software-speci˛c investment gives rise to a situation of hold up between
the producer/owner of the input and the subsequent innovator.
Thus, the choice to open the source code under OSS licensing terms might
be considered the choice of a contractual mechanism that provides safeguards
against opportunism to all the potential contributors to development. Indeed, such
contractual mechanism ensures that both the original and subsequent developers
will have continued access to the software they use to produce services in the ˛nal
market. In so doing, it allows the original developer to gather contributions from
other developers similarly interested in increasing the value of a software they use
to provide complementary services9. This turns out to be of particular relevance
when the market value of a given software is declining and the original developer
risks losing the speci˛c investment made in the ˛rst place.
3. The choice of the OSS license: copyleft vs. non-copyleft licenses
As mentioned before, OSS licenses can be roughly said to belong to two types:
copyleft and non-copyleft. The di¸erence between the two types resides in the
nature of the constraints they impose on licensees’ freedom to redistribute the
modi˛ed version of the OSS-licensed software under terms of their choice.
Non-copyleft licenses. This sort of licenses allows to release modi˛cations of the
software under a di¸erent license, even a proprietary one. Well known examples
are the Berkeley Software Distribution (or BSD) license, the Apache License and
the X11 license. The main obligation imposed by these licenses concerns the need
7
to give credit to contributors. All that is needed for anyone to freely use non-
copyleft-licensed software is to include in the redistributed software the copyright
notices (one of the notices, in turn, requires that subsequent distributors also
include the notice, so that it passes from user to user).
Software put in the public domain (i.e. software whose author has explicitly
given up copyright) can be described, in terms of its implications for incentives,
as a nonproprietary license with no associated constraints|although in this case
there is neither an owner nor a license.
Copyleft licenses. Copyleft licenses impose more stringent constraints relative to
non-copyleft licenses. From our point of view, the most relevant of such additional
constraints concerns the obligation to license future developments under the same
terms. Thus, developers of contributions to the original software code retain
copyright over their creations but they must distribute them under the terms
of the initial license. This constraint is imposed, among others, by the General
Public License, or GPL (see section 2(b) of the GPL)10 , which is therefore a
copyleft license and on which we will focus in this paper.
Thus, copyleft and non-copyleft licenses di¸er in that the former signi˛cantly
restrict both the original licensors’ and licensees’ freedoms with respect to the
latter. The most relevant of these restrictions relates to the fact that the BSD (and
in general all non-copyleft open source licenses) grants developers the freedom to
develop the OSS-licensed software and license developments as proprietary, while
the GPL does not. In other words, the BSD, di¸erently from the GPL, grants
developers the possibility to exclude other users and developers from access to an
improved version of the software or from a software using the original one as a
component. This implies that the BSD opens up the possibility to charge a price
for access.
It is perhaps important to note that the wording of the GPL license does
8
not prevent developers from charging a fee as high as they wish (or can) for the
distribution of software. In fact, GPL licenses do not impose an express obligation
to release the software itself for free, although they impose an obligation to apply
the terms of the original license at no charge to all third parties (see, for instance,
section 2(b) of the GPL)11. However, the latter provision, combined with the public
good characteristics of software (and thus with the possibility to reproduce copies
of software code at virtually zero cost by anyone), implies that the equilibrium
price of the right of access to the software is likely to be zero.
Given that conventional wisdom has it that the broader the rights granted to
an economic agent, the greater the stream of bene˛ts she can derive from her
property and therefore the greater her incentives, the absolute dominance of the
GPL in quantitative terms appears puzzling. Given that the BSD grants a broader
set of rights to both licensors and licensees, we should observe a prevalence of
the BSD over the GPL. Instead, copyleft licenses are much more widely adopted
than non-copyleft licenses, in spite of the more stringent restrictions they impose.
Lerner and Tirole (2005), for instance, report that 72% of OSS projects on the
Sourgeforge database adopt a GPL license, while only 7% of the projects in their
sample adopt the BSD.
Looking at \big" projects, there are many well known examples of projects that
turned from a proprietary to a GPL license: OpenO‹ce, Mozilla/Firefox, MySQL,
Virtualbox, QEMU, OpenSolaris, Xsara Xtreme, the Qt libraries and (announced)
Java. There are no similar examples of software turned to a BSD-like license; the
only case of software moved from a GPL to a BSD license we are aware of is that
of the OSS standard for music compression (an alternative to MP3).
Perhaps because the prevalence of the GPL appears to run counter to economic
intuition, most of the explanations o¸ered for why the GPL may work have to do
with ideology, either in the sense that the GPL constitutes a means to ensure
that the expectations of ideologically-motivated contributors are not frustrated
9
by the commercialization of the result of their e¸ort (see, for instance, Frank and
Jungwirth, 2001) or in the sense that the GPL allows to attract ideologically-
motivated contributions when other sources of motivation are weak (Lerner and
Tirole, 2005). Other reasons have to do with GPL’s ability to prevent forking
(Maurer and Scotchmer, 2006) or to reduce the extent of free-riding, particularly
in the form of the privatization of existing OSS projects (Gambardella and Hall,
2005)12.
Although we do not deny the importance of ideology, we contend that there
is no reason why the dominance of the GPL should be explained only in terms
of an ideological preference of developers. In our view, an important element of
the explanation of the relative success in terms of di¸usion of copyleft and non-
copyleft licenses is the fact that the two types of licenses impact di¸erently on
developers’ ability to access future versions of the software originally released un-
der OSS terms. This, in turn, in‚uences developers’ investment choices. While
both types of OSS licenses mitigate to some extent the mentioned hold up problem
arising from the combination of cumulativeness and investment speci˛city relative
to proprietary licenses, copyleft and non-copyleft licenses have very di¸erent im-
plications in this regard. In particular, although copyleft licenses entail a narrower
set of freedoms for both the original licensor and licensees, they guarantee to both
that they will have continued access to the software in whose knowledge and cre-
ation they have invested in and in all future versions of it and therefore constitute
a strong safeguard against the threat of hold up.
Non-copyleft licenses, by contrast, allow subsequent developers to turn their
contributions into proprietary and thus expose those developers that stick to the
OSS strategy to the the risk of opportunism and to a form of ex-post hold up
of the speci˛c investment in human capital they have made. This holds even
if developers are not excluded from access to older versions of the software, as
they might be excluded from the subsequent versions of the software, which may
10
include contributions important from a technical and commercial viewpoint. This
impacts both on the level and on the nature of the investment chosen ex-ante, as
it will become clear in the following section.
4. A formal model of investment choice under different licenses
The previous section has explained that the principal di¸erence between GPL and
BSD licenses resides in the fact that the latter allows developers, both licensors
and licensees, to license their developments under proprietary terms. Hence, if
the choice between the BSD and the GPL is of some relevance, it is because
with positive probability, at a certain future stage, the latest and most valuable
version of a project under BSD can be excluded from access and no longer be open
source. Since the possibility to exclude and make the project proprietary allows
the developer to collect a price from other users and developers, here is where the
superiority of the BSD in terms of incentives is alleged to reside.
In order to emphasize the di¸erence between the BSD and the GPL we consider
an \ideal" case where ex post contracting is without cost and there are no \social
norms" in the community of developers that keep developers from excluding others
and negotiating the conditions of access to their developments13. By focusing on
a simple single-period model, we assume that after development has taken place
all developers may choose to sell their contributions to others. We assume that
bargaining is e‹cient, so that ex post each developer has access to each other’s
contribution. In so doing, we consider a case which is at the same time more
favourable to the choice of the BSD than real world conditions are, and which
makes the di¸erence between the BSD and the GPL larger than it actually is.
We consider a software which is an input to the production by each developer
in the ˛nal market. Agents do not pro˛t from the direct sale of the software but
rather from providing assistance, customization or other services to end-users and
access to the source code constitutes a necessary input into the provision of such
11
services, so that software development constitutes a byproduct of these activities,
rather than the opposite.
4.1. Model setup
We assume that each developer imakes an investment yispeci˛c to software under
an open source license, whose technical quality is represented by an index X.
After the investment is made, she develops an innovation. Innovations increase
the value of Xfor developers as they use Xto produce services in their ˛nal
market. Considering the set Nof all developers, let XSbe the level of Xwhen
contributions by developers in Sare included. Clearly, XS–XRif RS.
Let ıibe developer i’s pro˛t in the ˛nal market. We have ıi=ıi(yi; X), with
@ıi(yi; X)
@yi
>0@ıi(yi; X)
@X >0@2ıi(yi; X )
@X @yi
>0 (1)
We allow for an e¸ect of yion ıindependent of the e¸ect through Xin order to
consider that (1) the investment by iin the development of Xcan increase her (X-
speci˛c) human capital, or can have a signalling e¸ect on the ˛nal market; (2) the
investment can improve the software in a developer-speci˛c way, since developers
can use \specialized" versions of X. In this sense, the e¸ect of yion Xmust be
thought of as the transferrable e¸ect of yi, the e¸ect of yiwhich bene˛ts the whole
community.
As mentioned in the previous paragraphs, the presence of the \direct" e¸ect
of yion ıiis very important in the explanation of why developers may choose an
open source solution.
We consider the ex post interaction under the two cases of GPL and BSD
license.
GPL. In the GPL case, contributions can be freely accessed by other developers;
they will be included in X, and developers are rewarded for using Xto provide
12
services in the ˛nal market. The payo¸ of developer iis:
ıi(yi; XN)`yi:(2)
BSD. When instead developers are allowed to exclude other developers from
access to their contribution, innovations are merged only after the innovator grants
access to other developers. In order to make the innovation available, the developer
can ask a price, so that bargaining will take place among developers in order to
allocate the surplus from innovations. Each developer’s share in this surplus is
determined by her bargaining power, which in turn is a function of how important
is her own contribution.
Considering that bargaining is e‹cient, we will make use of the concept of
Shapley value. The use of this concept has an established tradition in the economic
analysis of incomplete contracts and property rights (see, for instance, Hart and
Moore, 1990). The Shapley value considers the share of a bargainer as a function
of her value for each possible coalition of bargainers S„N.
The value for developer iis
X
S„Nji2S
(S)h˝(S)`˝(Snfig)i; (3)
where
(S) = (jSj ` 1)!(jNj`jSj)!
jNj!(4)
and where ˝(S) is the total pro˛t obtained by coalition S, or
˝(S) = X
j2S
ıj(yj; XS) (5)
so that ˝(S)`˝(Snfig) is how much the pro˛t of coalition Sis reduced if ileaves
it.
The share represented by the Shapley value is a weighted average of the contri-
13
bution of i’s development to all possible subsets of developments14. The formula
is often justi˛ed by imagining that the coalition Nis formed one actor at a time,
with each agent obtaining her contribution (as if she could make a take-it-or-leave
o¸er to the agents already in the coalition), and then averaging over the possible
di¸erent permutations in which the coalition can be formed15.
4.2. The choice of the level of co-speci˛city
In addition to the choice of the investment level yi, we consider as very important
the choice of the nature of the investment in development. Each developer can
choose to make her development based on Xmore or less co-speci˛c to develop-
ments made by others. At one extreme, developer i’s contribution can be stand
alone and require only the basic version of the software. At the other extreme, her
contribution can have value only if used together with all the other contributions.
More generally, each developer can decide to make her development more or less
speci˛c to other developments.
Software development e¸orts are always to some extent co-speci˛c. However,
increasing the degree of co-speci˛city of e¸orts generally allows to reap important
technical bene˛ts, by enhancing the e¸ectiveness of the combination of the various
modules or functionalities. This is particularly important in the context of decen-
tralized innovation typical of OSS development, where generally each contribution
is soon made available and \used" by other developers.
We will say that the contribution by iis speci˛c to the subset of contributions
R„Nif its value is enhanced by the fact that it is used together with the
contributions in R, or
@XS
@yi
>@XS0
@yi
when R„Sand R6„ S0:(6)
We will say that a developer whose contribution is speci˛c to Rcan increase
14
the level of cospeci˛city by choosing to make it speci˛c to R0such that RR0;
we assume that, as a consequence of increased cospeci˛city, @XS=@yiis increased
for all Ssuch that R0„S, while it is decreased for Ssuch that (S\R0)„R.
In other words, more cospeci˛city increases the value of the investment when all
contributions in R0are included in S, while it decreases it when it is made speci˛c
to additional contributions which are not included in S.
A somehow extreme assumption is that i’s R-speci˛c contribution doesn’t add
anything to XS(@XS=@yi= 0) if R6„ S.
Hence, there is a trade-o¸ from increasing co-speci˛city (i.e. from choosing to
make an investment speci˛c to a larger set of contributions R0) when we are not
sure that all contributions in R0are included, while cospeci˛city is always good
when all contributions in Nare used.
When the objective is to maximize the development of X, co-speci˛city should
always be encouraged, since more cospeci˛city means a higher XN, and under the
assumption of e‹cient ex post bargaining the coalition Nwill always be formed
(i.e. all contributions will be included).
Since the degree of co-speci˛city is an individual choice of each developer, the
license can a¸ect this choice. Under the GPL, developers are sure coalition Nis
always formed, and take their investment decisions on the basis of this expectation.
Under the BSD, conversely, the bargaining power of the parties depends on their
\outside" options, i.e. the value with all coalitions di¸erent from N. In other
words, under the BSD increasing the value of coalitions di¸erent from Swill be
optimal from an individual point of view16.
We summarize this ˛rst conclusion in the following
Proposition 1. Under the GPL, each developer will choose to be speci˛c to
all of the other developers (N-speci˛c), i.e. she will choose the highest possible
degree of co-speci˛city. Under a BSD license, a lower degree of co-speci˛city
will be chosen.
15
The second part of the proposition is best illustrated by using a simple two-
agents speci˛cation of the model presented above. This allows to discuss the basic
characteristics of the interaction in the simplest possible setting.
Let Xbe Xf1;2g=„1y1+„2y2when contributions are merged together, and
Xfig=—
„iyiwhen only i’s contribution is used17.
Depending on the choice of the parties with regard to the degree of co-speci˛city,
„1can assume the following values:
co-speci˛c investment by: both only 1 only 2 none
contributions merged „1
12 „1
1„1
2„1
0
contributions not merged —
„1
1—
„1
0
Hence, we indicate by „i
12 the marginal e¸ect of yion Xwhen both 1 and 2
choose to work on co-speci˛c projects and the two contributions are merged; if
the contributions are not merged, the e¸ect is —
„i
i(note that in this case it is not
relevant if the other developer has chosen a co-speci˛c investment or not). The
remaining notation is intuitive.
The assumption above about the e¸ects of incresed speci˛city translates into
„i
12 > „i
j> „i
0: the choice of a co-speci˛c investment increases the value of the
investment when contributions are merged, and the value is maximum when both
choose the co-speci˛c investment. Although this is not necessary to our result,
it might be reasonable to assume strategic complementarity in the choice to be
co-speci˛c: „i
12 `„i
j> „i
i`„i
0.
If contributions are not merged, it is better not to make a co-speci˛c invest-
ment, hence —
„i
0>—
„i
i. We assume without loss of generality that —
„i
i= 0 (i= 1;2):
the value of the contribution is zero if ihas chosen to be co-speci˛c and the
contributions are not merged.
Note that from a collective point of view the optimal choice is the co-speci˛c
investment, since in equilibrium all contributions are merged, and all contributors
16
have access to Xf1;2g.
Let us compare the GPL and BSD licensing regimes.
Under the GPL, each developer has access to Xafter development activity
has taken place. There is no reason not to contribute one’s development. Each
developer gets (2). The level of co-speci˛city will be chosen so that Xf1;2gis
maximized: the \socially" optimal outcome „i
12 will result.
Things are di¸erent under the BSD. In this case, developers’ payo¸s depend on
their contractual force, which in turn depends on the value of their contribution to
all possible coalitions, not only to N(in the two-agents case, each developer can
belong to a coalition with the other developer or simply stay alone). According to
the solution de˛ned in (3), which in the two-agent case coincides with the Nash
bargaining rule (the parties split 50:50 the di¸erence between the payo¸ with
cooperation and the payo¸ when they do not cooperate), igets
1
2hı1(y1; Xf1;2g) + ı2(y2; Xf1;2g)`ı1(y1; Xf1g)`ı2(y2; Xf2g)i+ıi(yi; Xfig) (7)
or, for developer 1:
1
2hı1(y1; Xf1;2g) + ı2(y2; Xf1;2g)`ı2(y2; Xf2g)i+1
2ı1(y1; Xf1g) (8)
with a similar payo¸ function for developer 2.
We now consider the optimal choice of the level of co-speci˛city by the parties.
To simplify the analysis and make our conclusion more clear-cut, we disregard
the choice of yiassuming yi= 1. We will remove this restriction in the following
section.
Substituting for Xin the payo¸ function (7), and de˛ning for notational con-
venience ^ı(X) = ı1(X) + ı2(X), we can consider the (noncooperative Nash)
equilibrium of the choice of co-speci˛city by the parties.
Consider the case that developer 2 chooses co-speci˛city. Developer 1 will
17
choose co-speci˛city only if
1
2ı1(—
„1
0) + 1
2“^ı(„1
2+„2
2)`ı2(0)”(9)
is lower than
1
2ı1(0) + 1
2“^ı(„1
12 +„2
12)`ı2(0)”(10)
or
ı1(—
„1
0)`ı1(0) <^ı(„1
12 +„2
12)`^ı(„1
2+„2
2) (11)
On the other hand, if developer 1 does not choose co-speci˛city, developer 2
will choose co-speci˛city only if
1
2ı2(—
„2
0) + 1
2“^ı(„1
0+„2
0)`ı1(—
„1
0)”(12)
is lower than
1
2ı2(0) + 1
2“^ı(„1
2+„2
2)`ı1(—
„1
0)”(13)
or
ı2(—
„2
0)`ı2(0) <^ı(„1
2+„2
2)`^ı(„1
0+„2
0) (14)
Therefore co-speci˛city, though e‹cient, might not be an equilibrium strategy
under the BSD. This will be the case if ıi(—
„i
0)`ıi(0) is high enough with respect
to the gains from co-speci˛city.
A numerical example To show that the e‹ciency loss can be substantial, con-
sider the following example with n+ 1 developers, with a large agent (named
n+ 1) and nsmall agents. By \large" and \small" we mean, respectively, \with
a large potential contribution" and \with a small potential contribution". We as-
sume that coalitions of small agents not involving the large one give no advantage
in terms of co-speci˛city, so that this example can be seen as a straightforward
18
extension of the simple two-agents case.
Assume that, when it is merged into X, developer i’s (i < n) contribution to
^ıis equal to:
- 24 both agent iand agent n+ 1 have chosen co-speci˛city;
- 20 if ihas chosen co-speci˛city but n+ 1 has not;
- 12 if neither inor n+ 1 has chosen co-speci˛city.
We are assuming that developers other than n+ 1 do not a¸ect developer i’s
contribution.
Assume that ıi(the stand alone pro˛t for a small developer) is equal to 10
when she chooses not to be co-speci˛c, zero when co-speci˛city is chosen.
Finally, assume that by not being co-speci˛c the stand alone pro˛t ın+1 is
higher by Fthan if she chooses to be co-speci˛c, with F > n ˆ2.
Consider the case that all nsmall developers choose co-speci˛city. The total
pro˛t is nˆ24 if n+ 1 is co-speci˛c. However, this is not optimal for n+ 1,
since her payo¸ is 1
2^ı+1
2ın+1 and she can increase ın+1 by Fby decreasing ^ıby
nˆ2< F (this is the e¸ect of choosing not to be co-speci˛c).
However, if n+ 1 chooses not to be co-speci˛c, each imust compare his pro˛t
when co-speci˛c ( 1
220) and when not co-speci˛c ( 1
212 + 1
210). She will choose not
to be co-speci˛c, and this will be the only Nash equilibrium of the game.
Note that, in the example, there is no real advantage from merging the contri-
butions: the total pro˛t is nˆ12 if contributions are merged, and nˆ10 + Fif
they are not. In any case, it is much lower than if co-speci˛city is chosen by all of
the developers, in which case we would have nˆ24.
4.3. The choice of the level of investment
The analysis of the previous sections disregarded the incentive to invest, i.e. the
choice of yi. Although the conclusion of proposition 1 is not a¸ected by this
simpli˛cation, the comparison between the two licenses is about the level of X
19
and of ıi, and the level of yiis relevant in this regard. Moreover, recall that it is
because it allegedly induces a higher level of yithat the BSD is often considered
superior to the GPL in terms of incentives, so that it is important to consider this
aspect explicitly.
In the GPL case, the value of a marginal increase in yiis:
@ıi(yi; XN)
@yi
+@ıi(yi; XN)
@X
@XN
@yi
`1 (15)
developers will invest as long as this is higher than zero.
In the case of the BSD, the marginal e¸ect of an increase in yiis (we di¸erentiate
(3)):
X
S„Nji2S
(S)"@ıi(yi; XS)
@yi
+X
j2S
@ıj(yj; XS)
@X
@XS
@yi3
5`1 (16)
Comparing this expression with (15), we notice that:
›the incentive to invest due to the direct (hydiosincratic) e¸ect of yion i’s
pro˛t on the ˛nal market, is lower under the BSD as, because of (1),
@ıi(yi; XN)
@yi
>X
S„Nji2S
(S)@ıi(yi; XS)
@yi
; (17)
›in the BSD case, each developer reaps a share of the bene˛ts of her develop-
ment on the pro˛ts of all developers. If this is higher than the bene˛t on ıi
only, or
@ıi(yi; XN)
@X
@XN
@yi
<X
S„Nji2S
(S)X
j2S
@ıj(yj; XS)
@X
@XS
@yi
(18)
then the BSD scores better in this regard.
Under the GPL, the incentive to invest is given by the perspective to use
the software in one’s ˛nal market. Development is somehow a byproduct of the
investment to enhance one’s X-speci˛c skills and to introduce those improvements
20
in Xthat a¸ect most ıi.
Under the BSD, the incentive to increase ıiis less important, but there is the
opportunity to \sell" innovations to other developers.
Although it is not possible in general to conclude that the incentive to invest
by those who participate to the development of Xis higher under one system or
the other, the presumption is that in many cases the second of the two e¸ects is
more important, and the BSD might induce a higher level of yi.
It is worth emphasizing that even when the BSD induces a higher yi, it is
not possible to draw a conclusion on the superiority in general of one license of
the other, since the overall e¸ect of investments on X(hence on ˝), depends on
the combined e¸ect of the choice of the nature of the investment (more or less
co-speci˛c) and the intensity of investments.
However, a conclusion can be reached in some special cases.
Note that the inequality (18) is less likely to be veri˛ed the lower are the
terms @XS=@yiwith respect to @XN=@yi, i.e. the more important is the e¸ect of
co-speci˛city.
This suggests what are the circumstances whereby the GPL induces a higher
yi. Once again, co-speci˛city can play a central role.
Consider the case in which developers choose to make a co-speci˛c investment,
and make the assumption that their investment is valuable only if the coalition
Nis formed (note that, under these circumstances, the choice of a co-speci˛c
investment is an equilibrium both with GPL and with BSD). In other words, we
are considering that @XS=@yi= 0 for SN. In the two agents case, this amounts
to the assumption that —
„i
i= 0.
From (16), we have that the ˛rst order condition with regard to the choice of
yiis now:
1
jNj
@ıi(yi; XN)
@yi
+1
jNjX
j2N
@ıj(yj; XN)
@X
@XN
@yi
= 1 (19)
The second term on the left hand side represents the average e¸ect of an increase
21
in yion the individual pro˛t of developers. Depending on the cases, this can be
higher or lower than the second term in the expression (15).
By comparing (19) with (15), we realize that the level of yiis likely to be higher
under the GPL for most i. The loss in incentives (with respect to the GPL) is
higher the more important is the e¸ect of yion ıi,@ıi(yi; XN)=@yi.
A similar result is obtained under less extreme hypotheses on @XS=@yi, if
we assume that the use of the software is pro˛table only when the technological
index XSreaches a certain threshold level. Hence, if we assume that ıi(X)=0
for X < —
Xand XN–—
Xonly when the co-speci˛c investment is chosen, the ˛rst
order condition is once again (19), and the GPL will be more attractive in terms
of incentives to invest.
Such an assumption may be justi˛able in contexts where the degree of techno-
logical advancement of Xis the crucial variable to secure pro˛tability. We expect
this can be the case, for instance, in a market where competing projects struggle
for technological leadership. This is consistent with the observation that the fact
that a software is \lagging behind" is often a reason why the open source solution
is chosen, in the hope of spurring technological advancement.
We summarize the conclusion of this section in the following
Proposition 2. Taking into account incentives to invest, the BSD license can
be expected to induce a higher level of yi. However, the more important is
the e¸ect of co-speci˛city on Xor on ˝, the lower is the chance that yiwill
be higher under the BSD.
5. Discussion
The model introduced in the previous section may help to shed light on three
stylized facts. The ˛rst is the mentioned quantitative dominance of the GPL
license in the OSS world. The model suggests that, although the BSD might have
an advantage over the BSD in terms of incentives to expend e¸ort in software
22
development, it tends to distort the nature of development, by providing sub-
optimal incentives to make investments co-speci˛c to those of other developers.
This, in turn, suggests a reason why the GPL license might be preferred to the
BSD by a developer interested in maximizing the subsequent rate of development,
as we claim it is the case for many projects adopting an OSS licensing strategy.
The second is the fact that there tends to be a correlation between the type
of OSS project and the type of license adopted. BSD-like licenses seem to be
more widespread for setting standards that give rise to the articulation of di¸erent
projects, and they are often used for projects funded by third parties (government,
universities etc.)18. They are practically never observed for end-user projects|
i.e. for projects meant to produce a software that can be directly used by ˛nal
customers. GPL licenses are, by contrast, routinely adopted for the latter type of
projects. An interesting example that may con˛rm this observation is given by the
GNOME project{aimed at building a complete desktop environment{that contains
software packages licensed under both BSD and GPL. Within this project, not a
single end-user application is licensed under BSD, although there is no restriction
on the choice of the kind of license to use. Consistently with these empirical
observations, our model identi˛es the di¸erential advantages of the two licenses,
pointing out that:
1. the GPL is better suited than the BSD to coordinate and encourage joint
e¸ort by many (possibly small) developers; while
2. the BSD is better suited than the GPL to generate positive spillovers to
other developers, when no feedback is required.
Indeed, standard-setting requires a relatively limited amount of feedback and it
is generally performed by a limited number of agents. By contrast, end-user
applications tend to require a much greater amount of co-speci˛c investment.
Finally, a third relevant but relatively unnoticed empirical regularity is the
23
fact that BSD and GPL communities tend to be rather di¸erent. In particular,
BSD communities tend to be close-knit groups of developers who work on projects
where feedbacks from outside the relatively stable community are limited and tend
to rely on strong social norms, repeated interaction as well as relatively structured
coordination mechanisms other than the license itself (one example is the adoption
of a voting committee of co-developers within the Apache community, which uses
a variant of the BSD license; another example is the setting up of a consortium
within the X11 project). GPL communities, by contrast, tend to involve a higher
number of participants and a less prominent role of social norms.
In this regard, our model might be taken to suggest that, if co-speci˛city of
development e¸orts is important for a given BSD-based project, the license alone
may not be an e¸ective coordination mechanism, so that other means of coor-
dination should come into play. Thus, within BSD communities the major role
played by \face-to-face" interaction or the adoption of other formal coordination
arrangements may make the license of secondary importance in securing co-speci˛c
e¸ort, while at the same time a less constrained license can encourage indepen-
dent investments by other developers. The GPL is, by contrast, a better choice
when development feedbacks are important in a context where relations between
developers are more \anonymous".
As a ˛nal note, it is perhaps important to stress that, in spite of the important
di¸erences in the wording of the license, projects under BSD and under GPL may
show a similar degree of \persistence" as open source projects. In other words,
di¸erently from the assumptions we make in the model, real world developers,
though allowed to do so, can decide not to exclude other developers from access
to their contributions. This can be explained by the existence of social norms,
of other coordination mechanisms or of ideological reasons, as well as by the fact
that the conditions that made the choice of an OSS strategy the best solution
at the ˛rst stage may be still valid at subsequent stages for all developers. A
24
complementary reason is that, contrary to what we have assumed throughout the
model, there might be high contracting and marketing costs, and this is expecially
true when the development is of small importance and/or the contributor must
incur high ˛xed costs to market and enforce her property rights. When ex post
contracting costs are very high, the BSD behaves like a GPL19.
Future research might take into explicit account contracting costs. However,
we think that the basic result in terms of di¸erences between the two licenses
should not be a¸ected.
Notes
1In this respect, our approach can remind of Cai (2003), where the choice of the degree of
speci˛city is used to justify forms of common property.
2The free software de˛nition makes explicit reference to the large set of rights (freedoms)
accorded by OSS licenses:
Free software is a matter of the users’ freedom to run, copy, distribute, study, change
and improve the software. More precisely, it refers to four kinds of freedoms, for the
users of the software: The freedom to run the program, for any purpose (freedom 0).
The freedom to study how the program works, and adapt it to your needs (freedom
1). Access to the source code is a precondition for this. The freedom to redistribute
copies so you can help your neighbor (freedom 2). The freedom to improve the
program, and release your improvements to the public, so that the whole community
bene˛ts (freedom 3). Access to the source code is a precondition for this. A program
is free software if users have all of these freedoms. Thus, you should be free to
redistribute copies, either with or without modi˛cations, either gratis or charging a
fee for distribution, to anyone anywhere. Being free to do these things means (among
other things) that you do not have to ask or pay for permission.
3Note that OS software is to be distinguished from software whose license allows to use it
freely, but not to modify it (e.g. Acrobat). In this case the software is free, in the sense that is it
distributed at no cost, but it is not open source.
25
4In order to release his own work in the public domain, the author of a piece of software must
take some explicit legal steps in order to disclaim the copyright over it, given that copyright im-
mediately attaches to original creations under the Berne Convention for the Protection of Literary
and Artistic Works of 1886.
5Note that this does not mean taking any particular stance on the comparative relevance of
di¸erent motivations for releasing software under OSS licenses. In other words, we do not rule out
the possibility that in many cases intrinsic motivations may play an important (and sometimes
even prominent) role.
6It is important to note that the assumptions we make on the choice to open the source code
imply that we do not directly address the question whether software development under an OSS
license is superior to software development under proprietary licenses in absolute terms. In other
words, we do not explore here the issue of whether means alternative to OSS licensing, such as for
instance a centralized organizational solution involving the hiring of developers to work in-house
on the project, would allow to achieve comparable or better results(on some aspects of this issue
see, for instance, Johnson, 2006).
7One important exception in this regard in the OSS context is the mentioned 2005 paper
by Lerner and Tirole where the authors stress in a footnote that the "hijacking" possible under
permissive licensing terms may deprive contributors of some of the bene˛ts from participating to
a project because it creates the possibility of hold up and that restrictive licensing terms may be
interpreted as a contractual response to this problem.
8This is consistent with the fact that the business models currently adopted in the software
industry are increasingly based upon the idea that it is service provision that should be sold rather
than binary code (think about the increasing importance of the Software as a Service model|SAAS
model).
9This is consistent with all of the empirical analyses available to date that con˛rm the relevance
of user needs as the single most important driver of contributions to OSS projects. Lakhani and
Wolf (2003) in a web-based survey administered to 684 software developers in 287 F/OSS projects
˛nd user needs, both work- and non-work-related, to be the overwhelming reason for contribution
and participation. Similar results are obtained also by Gosh, Glott, Kreiger and Robles (2002);
Hertel, Niedner and Hermann (2002)
10Section 2(b) of the GPL reads:
You must cause any work that you distribute or publish, that in whole or in part
26
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.
11For more information refer, for instance, to the GPL FAQ webpage, available at
http://www.gnu.org/licenses/gpl-faq.html.
12Note that the comparison of the costs and bene˛ts of these two forms of licensing from an
economic viewpoint has so far received relatively scant attention, with the exception of Gaudeul
(2005) and Bezroukov (1999). Indeed, while the literature highlights a number of reasons why
recourse to the GPL may make sense, it does not explore the question whether the GPL may make
more or less sense than the BSD and under what circumstances this is likely to be the case.
13The presence of social norms in the OSS community might be considered a substitute for
licenses as a means of coordination. More on this will be said in section 5.
14Note that PS„Nji2S(S) = 1.
15Taking all possible orderings of jNjagents as equally likely, (S) represent the probability that
iwill be ranked just after the agents in the set Snfig.
16Note that if we took into account transaction costs, hence the possibility that the coalition N
is not formed in the end, this would only reinforce our point, as it would make it less important
to increase XN.
17Therefore, @Xf1;2g=@yi=„iand @Xfig=@yi=—
„i.
18Another case is the development of drivers for peripherals.
19When they are high but not high enough, contracting takes place, though some cost is paid.
The project becomes proprietary and transaction costs reduce the payo¸.
References
Aghion, P., Tirole, J., 1994. \On the management of innovation". Quarterly
Journal of Economics, vol. 109, pp. 1185{1207.
Arora, A., Merges, R. P., 2001. \Property rights, ˛rm boundaries and r&d inputs".
mimeo, Carnegie Mellon University and U.C. Berkeley School of Law.
Bergquist, M., Ljungberg, J., 2001. \The power of gifts: organizing social rela-
27
tionships in open source communities". Information Systems Journal, vol. 11,
pp. 305{320.
Bezroukov, N., 1999. \Open source software development as a special type of
academic research: critique of vulgar raymondism". First Monday, vol. 4.
Cai, H., 2003. \A theory of joint asset owneship". RAND Journal of Economics,
vol. 34, pp. 63{77.
Frank, E., Jungwirth, C., 2001. \Reconciling investors and donators|the gover-
nance structure of open source". Working paper, University of Zurich.
Gambardella, A., Hall, B. H., 2005. \Proprietary vs. public domain licensing of
software and research products". Working Paper 11120, NBER.
Gaudeul, A., 2005. \Public provision of a private good: What is the point of the
BSD license?"
http://ideas.repec.org/p/wpa/wuwpio/0511002.html.
Gosh, R. A., Glott, R., Kreiger, B., Robles, G., 2002. \The free/libre and open
source software developers survey and study".
http://www.infonomics.nl/FLOSS/report.
Grossman, S. J., Hart, O. D., 1986. \The costs and bene˛ts of ownership: a
theory of vertical and lateral integration". Journal of Political Economy,
vol. 94, no. 4, pp. 691{719.
Hart, O. D., 1995. \Corporate governance: some theory and implications". Eco-
nomic Journal, vol. 105, pp. 678{89.
Hart, O. D., Moore, J., 1990. \Property rights and the nature of the ˛rm". Journal
of Political Economy, vol. 98, pp. 1119{1158.
28
Hertel, G., Niedner, S., Hermann, S., 2002. \Motivation of software developers in
the open source projects: an internet-based survey of contributors to the Linux
kernel". Research Policy, vol. 327, pp. 1159{1177.
Johnson, J. P., 2002. \Open source software: public provision of a public good".
Journal of Economics and Management Strategy, vol. 11, no. 4, pp. 637{62.
Johnson, J. P., 2006. \Collaboration, peer review and open source software".
Information Economics and Policy, , no. 18, pp. 477{497.
Lakhani, K., Wolf, R. G., 2003. \Why hackers do what they do: understanding
motivation e¸orts in free/open source projects". Working Paper 4425-03, MIT
Sloan School of Management.
Lerner, J., Tirole, J., 2002. \Some simple economics of open source". Journal of
Industrial Economics, vol. 52, pp. 197{234.
Lerner, J., Tirole, J., 2005. \The scope of open source licensing". Journal of Law
Economics and Organization, vol. 21, no. 1, pp. 20{56.
Maurer, S. M., Scotchmer, S., 2006. \Open source software: the new intellectual
property paradigm". In: Hendershott, T. (ed.), Handbook of Economics and
Information Systems, Elsevier, Amsterdam.
Moglen, E., 1999. \Anarchism triumphant: free software and the death of copy-
right". First Monday, vol. 48.
Raymond, E. S., 1998. \The cathedral and the bazaar". First Monday, vol. 330.
Rossi, M. A., 2006. \Decoding the Open Source puzzle: a survey of theoretical and
empirical contributions". In: Bitzer, J., Schroder, P. (eds.), The economics of
Open Source Software development, Elsevier, Amsterdam.
von Hippel, E., 2002. \Horizontal innovation networks: by and for users". Tech.
Rep., MIT Sloan School of Management.
29
