Designing Open Source Licenses*
Kim-Sau Chung†

Melody Lo‡

May 30, 2024

Abstract
Open source licenses are noted for being self-referential. The two mostpopular licenses are GPL and BSD. GPL says the next developer cannot go
proprietary, and can only go open source with the same license, namely GPL.
BSD says the next developer can go proprietary, and can also go open sourcewith any license, including BSD. We provide a framework to study all selfreferential licenses. When developers discount the future exponentially, andwhen forking is unlikely, there is no need to consider any self-referential
licenses other than GPL and BSD. With hyperbolic discounting, or if forking
is likely, there are other simple self-referential licenses that can do better than
GPL and BSD.
Keywords: open source, licenses, self-referential, GPL, BSD
JEL Classifications: L86, O36* We thank Jimmy Chan, Yeon-Koo Che, Yi-Chun Chen, Sambuddha Gosh, Junichiro Ishida,

Chia-hui Lu, Thomas Mariotti, Balazs Szentes, William Taysom, Kelvin Yuen, and participants
at various seminars and conferences for very helpful discussions. Chung and Lo are co-firstauthors. Chung acknowledges the support of the Research Grants Council of Hong Kong (via
grant GRF12502121) and HKBU (via grant RC-IG-FNRA/17-18/01). Lo acknowledges the supportof the Higher Education Sprout Project of the Ministry of Education in Taiwan (via grant 113L900303
to the Taiwan Social Resilience Research Center).
† Centre for Business Analytics and the Digital Economy, Hong Kong Baptist University; email:kimsauchung@gmail.com‡ Department of Economics, National Taiwan University; email: peiyulo2006@gmail.com

1

1

Introduction
Once a software is developed, its developer has at least two ways to distribute

it. The first is to go proprietary, meaning that she sells copies of the binary code
for a profit. Since the binary code is difficult to interpret, it deters the others fromdisabling its security device and making illegal copies. But it also makes it difficult
for future developers to learn from her source code. In other words, while goingproprietary allows the developer to profit from her effort, it also stifles further
development of her original idea.
Another way the developer can distribute her software is to go open source,
meaning that she makes her source code open for everyone to see and copy. By
going open source, she forgoes the profit she could have made from selling copiesof the binary code, but she can gain utilities when future developers, inspired byher source code, develop more advanced versions. Such utilities may come frompride, prestige, sheer joy of seeing her idea further developed, or the satisfactionof using a more advanced version of her original software.
There are two major kinds of license a developer may use when she decides togo open source. The first is the restrictive kind, exemplified by the GPL license.1
By sharing her source code using GPL, the developer tells future developers, “Youcan use my source code to develop a more advanced version. But if you ever want
to distribute your advanced version, you have to go open source instead of goingproprietary, and you have to go open source with the same license I am using,namely GPL.” This kind of open source licenses are restrictive because they restrict
how future developers can distribute their softwares. In particular, the restriction
is a “share-alike” requirement, requiring that future developers share in the samemanner as the original developer.
One of the most famous developers who went open source using GPL is Linus
Torvalds. Ever since Linus Torvalds distributed the source code of the first versionof Linux using GPL, all subsequent versions have to be shared alike using the same
1 GPL stands for “general public license”.

2license. Even when Red Hat, a for-profit company, developed their commercial
version of Linux, called Red Hat Enterprise Linux, they were also bound by
GPL to share their source code. It means that they could not make a profit by
selling copies of the binary code. Instead, they could only make a profit by
selling complementary services.2 Today, Linux powers millions of smart devices,
including smart phones, smart TVs, tablet computers, etc.
The second kind of license a developer can use when she goes open source isthe permissive kind, exemplified by the BSD license.3 By sharing her source codeusing BSD, the developer tells future developers, “You can use my source code to
develop a more advanced version, and you can distribute your advanced version
in whichever way you like. You can go proprietary, you can also go open source.
If you choose to go open source, you can use any license you like, including BSD.”
One of the most famous developers who went open source using a BSD-likepermissive license is Donald Knuth. While the core of TEX is copyrighted by Donald Knuth and no changes are permitted, add-on programs are licensed under the
LATEX Project Public License (LPPL), which is very much like BSD (Gaudeul, 2007).
The permissive nature of LPPL allowed subsequent developers to go proprietaryand profit from their efforts. This option encouraged many developers to participate in developing various add-on programs, with Scientific Workplace being oneof the most profitable examples.
The open source movement is nothing short of a revolution in how production
is organized. Many of the most valuable softwares (such as Linux, LATEX, Apache,etc.) might never have been developed if developers had not learned how to share
their contributions using open source licenses. The movement also had impacts
2 See Llanes and de Elejalde (2013) for a beautiful model of for-profit (and hence non-altruistic)firms choosing to participate in an open-source project and selling complementary products, andhow such “OS firms” coexist with proprietary firms.
3 BSD stands for ”Berkeley software distribution”. We use BSD as an umbrella term referring
to various BSD-like licenses including, for example, LPPL (to be discussed below), MIT (which iseven more permissive than BSD by not requiring acknowledgement of the licensor), and Apache(which makes explicit certain permissions that are only implicit in BSD). See, for example, Smith(2022).

3reaching far beyond the software industry. Projects with user-generated contentssuch as Wikipedia might never have been possible if contributors had not learned
how to share their contributions using Creative Common licenses, which in turnwere inspired by open source licenses.
While GPL and BSD are the two dominant open source licenses, with their
dominance especially pronounced at the early stage of the open source movement,4
it is important to recognize that they were inventions of idealistic developers, whoinvented them more as their anti-capitalist manifestos, instead of as calculated
designs that maximize productivity. Therefore, it is conceivable that a more careful
design exercise can unleash even more productivity.
A prerequisite of this design exercise is, of course, a theoretical framework
to study all possible open source licenses, which is the first contribution of thispaper. Since open source licenses restrict future developers’ choices of open source
licenses, they are necessarily self-referential in nature. Open source licenses hence
resemble types in epistemic game theory, where a type describes a belief overtypes. A key element of our theoretical framework is hence the spaces of open
source licenses, which have a similar structure as type spaces.
Our theoretical framework makes it easy to conceive of many more open source
licenses other than GPL and BSD. Many of them cannot be easily pigeonholed intoeither the restrictive or the permissive camp. For example, a license may be
restrictive in the sense that it restricts what restrictions the next developer can
impose on the next-next developer, but is permissive at the same time exactly
because the next-next developer is less restricted.
Once we can conceive of many more open source licenses other than GPL
and BSD, a natural question is why they are not as popular among open source
developers. One possibility is that the developers were simply not imaginative
4 Vendome et al. (2017) study 16,221 Java projects on GitHub. They find that, by 2012, BSD-likelicenses (including MIT and Apache) and various versions of GPL still accounted for more than
90% of all open source licenses used. Balter (2015) reports that, up to 2015, only 15% of open source
projects on GitHub used a license other than MIT, Apache, or GPL.

4

enough. Had they been equipped with our theoretical framework, they would
have expanded their imagination and conceived of many more open source licenses other than the two everyone is using. Another possibility is that there exist
simple, easy-to-understand models—perhaps not realistic but still good enoughapproximations of the reality—where GPL and BSD are indeed the two best open
source licenses. These models are what developers subconsciously use to reason
about their own community, and hence also lead them to stick with GPL and BSD.
We provide supports for both possibilities. In Section 6, we present a settingthat is a plausible approximation of reality, where it is indeed the case that all otheropen source licenses can be ignored without loss of generality. We develop ourargument in two steps. First, we introduce an axiom called imposture-proofness
to exclude open source licenses that can be gamed by a developer by splitting
her version of the software into two consecutive versions, with only the firstversion subject to the restrictions contained in the previous developer’s open
source license. Among other implications of imposture-proofness, we show that
any imposture-proof open source license that does not allow the next developer
to go proprietary is essentially the same as GPL.
In the second step, we show that, with a linear structure of developers andexponential discounting, a developer going open source cannot do better thanusing either GPL or BSD. If she does not allow the next developer to go proprietary,then her license is essentially the same as GPL, per the result in the first step. If
she does, then BSD gives the next developer maximum freedom, which is good forher as well. The key in this last step is that exponential discounting and a linear
structure of developers render the interests of the current and the next developer
perfectly aligned when it comes to putting restrictions on the next-next developer.
We also provide support for the other possibility. In Section 7, we demonstrate how the sufficiency result in Section 6 breaks down if we relax either theassumption of a linear structure of developers or the assumption of exponential
discounting.

5This paper is structured as follows. The rest of this section reviews the related
literature. In Section 2, we starts with a basic model that only allows for GPL
and BSD. In Section 3, we slightly extend our basic model by introducing three
new open source licenses. This exercise illustrates how our theoretical framework
allows us to conceive of new, never-heard-of open source licenses. The three
new open source licences introduced in this section will also play important roles
in our subsequent analysis. This section also explains why it can be difficult tosummarize an open source license by a single parameter called “permissiveness”
as in Lerner and Tirole (2005b).
In Sections 4 and 5, we introduce two important concepts, irreducibility andimposture-proofness, that are crucial in our statement of the sufficiency result,which in turn is presented and proved in Section 6. The sufficiency result saysthat it is without loss of generality to focus only on GPL and BSD under the assumptions of a linear structure of developers and exponential discounting. These
two assumptions will be relaxed in Section 7, where we show how two of the newopen source licenses introduced in Section 3 can each be better than GPL and BSD
if one of these two assumptions are relaxed. Section 8 concludes.

1.1

Related Literature

The open source revolution has rightfully attracted a lot of economic studies.
Lerner and Tirole (2002, 2005a) provide some early introduction of this revolution,
and Fershtman and Gandal (2011) a brief survey of the related economics, toeconomists. Subsequent studies can be roughly divided into four strands. The first
focuses on the competition between commercial software companies and the open
source community—what prices the companies would set, the chance that they cansurvive this competition, etc. The open source community is typically modelled
as a group of altruistic individuals or for-profit firms5 who both contribute to and
5 For-profit (and hence non-altruistic) firms can benefit from participating in an open source

project as well if they can learn from their participation and enhance the quality of their comple-

6

benefit from the open source movement. How their collaboration is facilitatedor jeopardised by different choices of licenses is typically not the focus.6 Factors
other than the license are instead the focus. For example, Johnson (2002) focuseson the size of the open source community, Casadesus-Masanell and Ghgemawat(2006) on demand-side learning, Economides and Katsamakas (2006) on network
externalities, Llanes and de Elejalde (2013) on complementary products, and Ataland Shankar (2014) on heterogeneous end-users.
This paper differs from this strand of studies in that it focuses explicitly on
open source licenses—what options other than GPL and BSD do we have, can they
serve purposes that neither GPL nor BSD can serve, and when can they be ignored
without loss of generality?
The second strand is concerned with the kind of altruism that motivates members of the open source community—are they motivated by warm glow, pride,
consumer surplus, or are they merely motivated by the material payoffs fromsignalling their competence? Athey and Ellison (2014) theoretically study how
different kinds of altruism affect the competition between commercial software
companies and the open source community; while Hertel, Niedner, and Herrmann (2003), Lerner, Pathak, and Tirole (2006), Roberts, Hann, and Slaughter(2006), Comino, Manenti, and Parisi (2007), and Fershtman and Gandal (2007)
empirically study related questions.
In comparison to this strand of studies, our model makes specific assumptions
on the kind of altruism that motivates a developer to go open source. In particular,
we assume that he internalizes part of the consumer surplus that may be generated
by future developers.7 We have not explored the implications of other kinds ofaltruism such as warm glow.
The third strand is interested in the governance structure of the open source
mentary products; see, for example, Llanes and de Elejalde (2013).
6 Presumably the license being used is not BSD, as members do not have the option of goingproprietary.
7 Or, alternatively, he gains an “egoboo” everytime a more advanced version of his software isdeveloped. See Footnote 10 for this this alternative interpretation.

7

community. Most of these studies are empirical in nature, taking the form of
meticulous case studies of selected open source projects, and taking advantage ofthe fact that, for most such projects, the whole history of interactions is stored aslog files in the public domain. Examples of these studies include Fielding (1999)
on the Apache project, Mockus, Fielding, and Herbsleb (2002) on the Apache andMozilla projects, and Han and Xu (2019) on the Python project. See also von Hippel
and von Krogh (2003) and Johnson (2006) for some general insights distilled fromthese studies.
In comparison to this strand of studies, our model assumes that each generationof the software is developed by one and only one developer. The very interesting
topic of intra-generation coordination hence cannot be studied in our stylized
model.
The final strand is the only strand that explicitly studies open source licenses.
It is also by far the smallest strand, with literally fewer than a handful of studies.
Lerner and Tirole (2005b) provide a stylized model that differentiates different open
source licenses by a single parameter, namely their “permissiveness”. Their model
abstracts away the defining features of different open source licenses, such as GPL’s“share-alike” requirement and BSD’s permission to go proprietary, rendering it
impossible to discuss the optimality of mixing-and-matching these features. As
we shall explain in Section 3, “permissiveness” is also an ambiguous concept. One
can easily construct examples that are permissive and restrictive at the same time.
Gaudeul (2004, 2005) and Atal and Shankar (2015) compare open source licenses
using models that are more explicit about GPL’s “share-alike” requirement and
BSD’s permission to go proprietary. But they focus only on GPL and BSD, and do
not consider other possible open source licenses. Their models also allow for only
up to three stages of development, rendering open source licenses in their models
not self-referential.8
In comparison to this strand of studies, our model has the following two
8 For example, the penultimate generation’s licenses do not restrict the ultimate generation’s

choices of licenses.

8

properties. First, it is rich enough that the defining features of GPL (its “sharealike” requirement) and BSD (its permission to go proprietary) can be described
explicitly, and hence the optimality of mixing-and-matching these features can bemeaningfully discussed (in contrast to Lerner and Tirole, 2005b). Second, it isa model with infinitely many generations of developers, and hence open source
licenses in the model are self-referential (in contrast to Gaudeul, 2004, 2005 andAtal and Shankar, 2015).

2

The Basic ModelIn this section, we shall first describe a basic model that is barely rich enough toaccommodate GPL and BSD. We will explain how this basic model can be extended
to accommodate other open source licenses in subsequent sections.
Consider a discrete-time model, where time is indexed by t = 0, 1, 2, . . .. Inevery period t, there is one and only one developer, called developer t, who has
the potential of developing a software, called software t. Note that we abusenotation by using the same index, t, for time, for developer, and for software.
We can think of developer 0 as an original developer such as Linus Torvalds or
Donald Knuth, and software 0 his original software. For any t > 0, we can think ofsoftware t as a more advanced version of software t − 1, perhaps by adding extra
functionalities. Of course, indirectly via software t − 1, software t is also a moreadvanced version of any software s < t − 1.
Developer t will be able to develop software t only if he has an opportunity
to learn from the source code of software t − 1. Apparently, this cannot happen if
developer t − 1 chose to go proprietary (i.e., to sell copies of the binary code fora profit), instead of sharing the source code with the others. Therefore, we shallassume that, if developer t − 1 goes proprietary, none of the software s ≥ t can be
developed. In other words, the game ends after developer t − 1 goes proprietary.
We assume that if developer t − 1 did not go proprietary, then he must go open

9source; i.e, sharing his source code with the others using one of the open source
licenses. In other words, keeping the software private is not an option. This is nota strong assumption. When a developer is not going to make a profit out of his
creation, any tiny preference of sharing will prompt him to share.
If developer t − 1 chose to go open source, thus enabling developer t to develop
software t, the game continues to period t. In period t, developer t first draws
a tuple of four variables, θt = (ct , πt , wt , Wt ), where ct is his cost of developing
software t, πt and wt are the potential profit and consumer surplus, respectively, if
he develops software t and then goes proprietary, and Wt is the consumer surplus
if he develops software t and then goes open source instead.9 The tuple θt is drawn
from the probability law P θt | θt−1 , where θt−1 = (θ0 , . . . , θt−1 ). We assume thatthe realization of θt is observable to all developers s ≥ t.
Upon observing θt , developer t then decides whether to pay the development
cost ct and develop software t. If he decides not to (an option denoted by Q, which
stands for quitting), the game ends.
If he decides to develop software t, he then decides whether to go proprietaryor to go open source using one of the open source licenses. Some of these options
may not be available, depending on the open source license chosen by developert − 1. We first enumerate the three different options developer t may have, andthen explain which subsets of these options are available to him given different
open source licenses chosen by developer t − 1.
P: going proprietary
Developer t goes proprietary, realizing potential profit πt and consumer
surplus wt , and the game ends.
G: going open source using the GPL license
Developer t goes open source, thus enabling developer t + 1 to develop
software t + 1. However, if developer t + 1 chooses to develop software t + 1,
9 It is natural to assume that W > w . None of our results, however, require this assumption.
ttAll of our examples, meanwhile, satisfy this extra assumption.

10

he has to go open source using GPL (i.e., choosing G) as well. For developert, potential profit πt is forgone, and the consumer surplus is Wt .
B: going open source using the BSD license
Developer t goes open source, thus enabling developer t + 1 to develop
software t + 1. If developer t + 1 chooses to develop software t + 1, he caneither go proprietary (i.e., choosing P), or go open source using any of thetwo licenses (i.e., choosing G or B). For developer t, potential profit πt isforgone, and the consumer surplus is Wt .
We should hasten to emphasize that what we called the consumer surplus(either wt or Wt ) should more appropriately be understood as the internalizable
part of the consumer surplus. It is the part that current and past developers(i.e., developers s ≤ t) who went open source can internalize. It is likely onlya small part of the whole consumer surplus. In particular, we do not presume
that Wt > πt + wt , which would have been a natural inequality to assume had weinterpreted these as the whole consumer surplus that can potentially be generated.
Indeed, allowing for Wt < πt + wt is necessary to explain why developer t may
sometimes go proprietary.10
For developer t > 0, which of these three options (P, G, and B) are available
depends on what open source license he is subject to (i.e., what open source licensedeveloper t − 1 chose). We enumerate these different situations in Table 1.
For developer 0, we assume that all three options (P, G, and B) are available tohim, and hence we may treat him as if he is subject to license B.
Let T be the period when the game ends. The game ends in period T iff (1)∀t < T, developer t decided to develop software t and then went open sourse, and(2) developer T either (2a) decides not to develop software T, or (2b) decides todevelop software T and then goes proprietary. If the game never ends, let T = ∞.
10 While our favorite interpretation of w

t and Wt is the (internalizable part of the) consumer
surplus, this is not the only possible interpretation. Alternatively, one can interpret them as what
Raymond (1999) calls “egoboo”; i.e., the ego boost all developers s ≤ t can gain from their increased
visibility and recognition when the more advanced software t is developed.

11

what developer t can choose
what developer t − 1 chose
after developing software t
P
the game ended in period t − 1 alreadyG
G
B
P, G, and B
Table 1: The basic model.
For most of this paper (except for Subsection 7.2), we assume exponential
discounting. For any developer t < T, his payoff is



0
s−t
T−t 
β Ws + β × 
Ut := −ct +


w T
s=t
T−1
X

if developer T does not develop software T
if developer T develops software T and goes proprietary(1)

where β ∈ (0, 1) is the common discount factor. In other words, we assume that
if developer t ever incurs the development cost ct but then forgoes his potential
profit πt , he does so because he is altruistic enough to care about current and future
consumer surplus.11
As for developer T, his utility is 0 if he decides not to develop software T, or isπT + wT − cT if he decides to develop software T and then goes proprietary.
We assume that developer t’s choice is observable to all developers s > t. We
have thus described an infinite-horizon observable-action game. The primitivesof the game are the probability law P(· | ·) and the common discount factor β. Our
solution concept is subgame perfect equilibrium.
It is easy to see that, depending on the probability law P(· | ·), it can be strictly
optimal for developer 0 to choose each of the four options (Q, P, G, and B). For
example, he would Quit if c0 is prohibitively large; goes Proprietary if W0 is small
compared to π0 + w0 and all (wt , Wt ), t ≥ 1, are likely to be negligible; goes open
11 One may wonder whether the consumer surplus W

t generated by software t depends onwhether software t + 1 will be developed, as the latter may supersede the former. In that case we
may reinterpret Wt+1 as the marginal increase in total consumer surplus generated by the creationof software t + 1, taking into account the creative destruction effect on software t (as well as all theearlier softwares).

12,source using GPL if π0 + w0 is small compared to W0 and all wt , t ≥ 1, are likely
to be negligible; and goes open source using BSD if π0 + w0 is small compared toW0 , w1 is likely to be similar to W1 , and all Wt , t ≥ 2 are likely to be negligible.
Without imposing significantly more structure on the probability law P(· | ·), it
seems difficult to fully characterize the conditions under which developer 0 would
choose each of these options. Since our main focus is on what other open source
licenses are available, we shall not pursue such a full characterization here, andshall leave it for future research. Appendix A, however, demonstrates how, if
we are willing to impose strong assumptions on the probability law P(· | ·), someinteresting characterizations can be obtained.

3

A Simple Extension
The basic model in Section 2 is so flexible that adding new open source licenses

is easy. For example, it is easy to see how anyone, by playing with Table 1, would
naturally come up with the new licenses depicted in Table 2.12 In Table 2, R is
simply the mirror image of G. It refers to itself in its own definition, in exactly
the same self-referential manner as G. But it deviates from G by allowing the next
developer to go proprietary. License 1 is derived from G in a different way. It puts
the same restriction on the next developer’s choices of open source licenses, butdeviates from G by also allowing the next developer to go proprietary. Finally,1license is derived from R in exactly the same way as how 1 is derived from G. It
puts the same restriction on the next developer’s choices of open source licenses,
but deviates from R by not allowing the next developer to go proprietary.
We call R the recursive-BSD license. It pushes the defining feature of BSD(its permission to go proprietary) to its limit. Not only that the next developer
is allowed to go proprietary, all future developers, to the extent that they have achance to move, are allowed to go proprietary as well. This is because, for example,
12 These authors confess that they had lots of fun filling out Table 2.

13what developer t − 1 choseGR
1what developer t can choose
after developing software t
G
P and RP and G
R

1

Table 2: A simple extension.
the next developer cannot use GPL to forbid the next-next developer from goingproprietary. In this sense, R is even more permissive than BSD. Of course, one canalso argue that R is more restrictive than BSD, as it puts more restrictions on how
the next developer can restrict the next-next developer. This is a perfect example of
why it can be difficult to summarize an open source license by a single parameter
called “permissiveness” as in Lerner and Tirole (2005b).
We call license 1 the 1-chance-only license. License 1 is unambiguously more
restrictive than R. While it, like R, gives the next developer the permission to go
proprietary, it forbids the next developer from giving the same permission to thenext-next developer. In other words, license 1 gives future developers one andonly one chance to go proprietary, namely in the next period and in the next period
only.
1

license1

We call licensethe 1-time-forbiddance license. As suggested by the symbol,

in effect turns the idea of license 1 upside-down. While license 1 allows

the next developer to go proprietary but forbids him and any future developer1from allowing their successors to do the same, licensedoes not allow the next

developer to go proprietary but requires that he and any future developer allow
their successors to do so.
Are these new licenses bogus? Are there any reasons why an open source
developer may consider using them? Are there situations where they may serve
purposes that neither GPL nor BSD serve? The answer is a qualified “no”. Indeed,in Section 6, we shall prove that, within our current model setup, these new licenses

14

can all be ignored without loss of generality (see Theorem 2). This is a surprising
result, given that the proof requires almost no restrictions on the probability law
P(· | ·) except for absolute continuity. This is the strongest explanation to date of
why GPL and BSD stood out from other licenses as the most popular two amongopen source developers.
However, that our “no” answer needs to be qualified also means that it is notuniversally true. In Section 7, we shall demonstrate how these new licenses canbeat GPL and BSD once we deviate from our current model setup. Specifically, in
Subsection 7.1, we show how license R can beat GPL and BSD if developers form atree instead of a linear structure. In Subsection 7.2, we show how license 1 can beat
GPL and BSD if developers have hyperbolic instead of exponential discounting.
Before we can formally state our sufficiency and insufficiency results in Sections
6 and 7, respectively, we have to first introduce two more concepts: irreducibility(Section 4), and imposture proofness (Section 5).

4

Irreducible Space of Open Source Licenses
The new licenses introduced in Section 3 are not the only possible new open

source licenses. Indeed, a little thought would suggest that infinitely many can begenerated in a similar manner. It is hence important to have a sense of how theset of all possible open source licenses looks like, and then impose some intuitive
axioms to weed out the less interesting ones.
We can define a general space of open source licenses in a manner similar tothat in Sections 2 and 3. For any set X, let P(X) be the set of all nonempty subsetsof X.13
Definition 1 Let O be an arbitrary set, with each element o ∈ O corresponding to an open
13 In mathematics, the notation P(X) typically stands for the power set of X, which is the set of

all subsets of X, including the empty set. Here, it will ease our notation if we re-define P(X) as theset of all nonempty subsets of X instead.

15

source license. Let g : O → P({P} ∪ O) be a nonempty correspondence such that, for anyo ∈ O, g(o) ∩ O , ∅. Then, S = (O, g) is a space of open source licenses.
Intuitively, g(o) specifies the (nonempty) set of options available to a developer
who is subject to open source license o.14 We assume that going open source(using some open source license) must always be an option, which translates
into the requirement that g(o) ∩ O , ∅. This assumption is natural, as it seems
impossible to design any open source license that forces the next developer to go
proprietary.15
A space of open source licenses may contain duplicates of otherwise identicalopen source licenses. For example, consider O = {G1 , G2 }, with g(G1 ) = {G2 } andg(G2 ) = {G2 }. Then the differences between G1 and G2 are superfluous, and one
may for all purposes regard both as being identical to GPL.
Formally, for any space of open source license S = (O, g), let ∼ be an equivalence
relation on O.16 For any o ∈ O, let [o] denote the equivalence class of o. We
shall abuse notation by sometimes writing P as [P] as well. Let O∼ denote thecorresponding quotient set (i.e., the set of equivalence classes of elements in O). Letµ : O ∪ {P} → O∼ ∪ {P} be the canonical mapping such that, ∀x ∈ O ∪ {P}, µ(x) = [x].
For any o ∈ O, let (µ ◦ g)(o) = {[x] ∈ O∼ ∪ {P} : x ∈ g(o)}, which is nonempty
because g(o) is nonempty. We say that g and ∼ are compatible if (µ ◦ g)(o) = (µ ◦ g)(o0 )whenever o ∼ o0 . If g is compatible with ∼, we can define g∼ : O∼ → P (O∼ ∪ {P})such that g∼ ([o]) = (µ ◦ g)(o) for any o ∈ O. Then S∼ = (O∼ , g∼ ) is a space of open
source licenses. We say that ∼ is nontrivial if there exist distinct o, o0 ∈ O suchthat o ∼ o0 . If there exists a nontrivial equivalence relation ∼ compatible with g,
14 It goes without saying that quitting, Q, is always an option.

We hence omit it from thedeveloper’s choice set for brevity.
15 It seems impossible to stop the next developer from giving up his copyright and putting his
source code in the public domain, which in our model is equivalent to going open source using
BSD. It should however be pointed out that, in reality, there are subtle differences between “putting
the source code in the public domain” and “going open source with the BSD licenses”, and thesesubtle differences are not captured by our model.
16 A binary relation ∼ is an equivalence relation if it is reflexive, symmetric, and transitive.

16

we say that S = (O, g) is reducible to S∼ = (O∼ , g∼ ) (or simply reducible); otherwise
S = (O, g) is irreducible.
Consider our earlier example where O = {G1 , G2 }, g(G1 ) = {G2 }, and g(G2 ) ={G2 }. The only nontrivial equivalence relation is such that G1 ∼ G2 . This equivalence relation is compatible with g, because (µ ◦ g)(G1 ) = {[G2 ]} = (µ ◦ g)(G2 ).
Therefore, S = (O, g) is reducible to S∼ = (O∼ , g∼ ), where O∼ = {[G2 ]} andg∼ ([G2 ]) = {[G2 ]}.
Consider the basic model in Section 2 where O = {G, B}, g(G) = {G}, andg(B) = {P, G, B}. The only nontrivial equivalence relation is such that G ∼ B.
This equivalence relation is not compatible with g, however, because (µ ◦ g)(G) ={[G]} , {P, [G]} = (µ ◦ g)(B). Therefore, S = (O, g) is irreducible.
One interesting question is whether there exists a universal space of opensource licenses, SU = OU , gU , that contains every space of open source licenses
as its sub-space. The answer is yes. The construction of such a universal space issimilar to that of the universal type space in epistemic game theory. We include
this construction in Appendix B for completeness.

5

Imposture-Proof Open Source Licenses
To motivate the idea of imposture-proofness, let’s revisit the 1-time-forbiddance

license introduced in Section 3:
going open source with the 1-time-forbiddance license

1

Developer t goes open source. If developer t + 1 chooses to develop softwaret + 1, he has to go open source with the recursive-BSD license (i.e., choosingR), thus enabling future developers to go proprietary.
1

Imagine that developer t − 1 goes open source with license , hoping to prohibit
developer t from going proprietary. One possible way for developer t to game
this license is to split his software t into two successive versions, version t.1 and17version t.2, with version t.1 a more advanced version of software t − 1, and version
t.2 a more advanced version of version t.1. He can roll out version t.1 first, go
open source with license R, thus satisfying the terms in developer t − 1’s license
1. He can then roll out version t.2, possibly using a different identity, and then go

proprietary, which is allowed by the terms in version t.1’s license R.
is that, while

1

1

The reason why developer t can game license

precludes P, it

allows for R which in turn allows for P. More generally, any license that tries topreclude option x but allows for some open source license o that allows for option
x can be gamed in a similar manner. This motivates the following axiom.
Definition 2 Let S = (O, g) be a space of open source licenses. An open source licenseo ∈ O is said to be imposture-proof if
o0 ∈ g(o) ∩ O=⇒

g (o0 ) ⊆ g (o) .

The space S is said to be imposture-proof if every open source license o ∈ O is impostureproof.
Note that all the other open source licenses studied in Section 3 (i.e., G, R, and
1) are imposture-proof open source licenses.
The following theorem is the main result of this section that we shall use in
Section 6.
Theorem 1 Let S = (O, g) be an irreducible space of open source licenses that is
imposture-proof. Any open source license o ∈ O that does not allow the next developer to go proprietary (i.e., P < g(o)) is identical to the GPL license G in the sense thatg(o) = {o}.
Proof:

Consider any open source license o ∈ O such that P < g(o). If o0 < g(o)for any o0 , o, then by the nonemptyness of g(o) ∩ O we must have g(o) = {o},and we are done. Therefore, let’s suppose there exists o0 , o such that o0 ∈ g(o).
18Let’s define an equivalence relation ∼ such that [o] = g(o) ∪ {o}, and [o00 ] = {o00 } forany o00 < g(o) ∪ {o}. This is a nontrivial equivalence relation because o0 , o andyet o0 ∼ o. We shall prove that g and ∼ are compatible, and hence S = (O, g) is
reducible. To prove compatibility, it suffices to prove that (µ ◦ g) (o0 ) = (µ ◦ g)(o)for any o0 ∈ g(o). By imposture-proofness, we haveg (o0 ) ⊆ g(o) ⊆ g(o) ∪ {o} = [o],and hence (µ ◦ g) (o0 ) = {[o]} = (µ ◦ g)(o) as claimed.



In Appendix C, we shall categorize different imposture-proof open source
licenses. This categorization is independent of the results in Section 6, which deals
with the question of why GPL and BSD stood out from other open source licenses
as the most popular two among open source developers. The categorization,
however, may be useful for future research, especially in light of our results in
Section 7, which demonstrate how open source licenses other than GPL and BSD
can be useful if we go beyond our current model setup.

6

Sufficiency of GPL and BSD
In this section, we shall prove that, in any subgame perfect equilibrium, ifdeveloper 0 is ever going to go open source, he cannot do better than going open
source with either GPL or BSD. This result is of interest because it sheds light on
why GPL and BSD stood out from other open source licenses as the most popular
two among open source developers.
Theorem 2 Assume that the probability law P(· | ·) is absolutely continuous. Let S =(O, g) be an irreducible space of open source licenses that is imposture-proof and contains
open source licenses G, B ∈ O such that g(G) = {G} and g(B) = {P} ∪ O. Then, in any
subgame perfect equilibrium, if developer 0 is ever going to go open source, he cannot do
19

better than going open source using either G or B.
Proof:We have already argued in Section 2 that either G or B can be strictly

optimal for developer 0 if these are the only two open source licenses available tohim. Since S = (O, g) is irreducible and imposture-proof, by Theorem 1, any open
source license o ∈ O other than G must have the property that P ∈ g(o). Therefore,
it suffices to prove that, in any subgame perfect equilibrium, choosing B is weakly
better than choosing any of these open source licenses for developer 0.
Consider any open source license o ∈ O such that P ∈ g(o). Suppose developer
0 goes open source using license o. For any o1 ∈ g(o) ∩ O, let v1 (o1 ) be developer
1’s gross expected payoff (gross of development cost c1 ) if he goes open sourcewith o1 , where the expectation is taken over the realizations of {θt }t≥2 , and istaken conditional on the equilibrium strategies of developers t ≥ 2. Note thatv1 (o1 ) = W1 + β × (· · · ) ≥ W1 . Let v∗1 = supo1 ∈g(o)∩O v1 (o1 ). Developer 1’s optimal
strategy is hence
1. not to develop software 1 if θ1 ∈ E01 := {θ1 | c1 > max{π1 + w1 , v∗1 }};2. to develop software 1 and go proprietary if θ1 ∈ EP1 := {θ1 | π1 + w1 >max{c1 , v∗1 }}; and3. to develop software 1 and go open source with one of the open source licenses
in argmaxo1 ∈g(o)∩O v1 (o1 ) if θ1 ∈ E∗1 := {θ1 | v∗1 > max{c1 , π1 + w1 }}.17
Since P(· | ·) is absolutely continuous, the boundaries of events E01 , EP1 , and E∗1have probability 0 and hence can be ignored.
By going open source with o, developer 0’s gross expected payoff (gross ofdevelopment cost c0 ) is hence
W0 + βE0 × 1E0 + w1 × 1EP + v∗1 × 1E∗
1
1
1



θ0 ,

(2)

17 The sup v∗ is attainable in this last case because an optimal strategy exists in a subgame perfect1equilibrium.

20

where 1E is the indicator function of event E, and E[·] is the expectation operator.
Note that v∗1 is weakly increasing in the set g(o) ∩ O (according to the order of
set inclusion), and is maximized at B. When v∗1 increases, there are three effects on
the expression (2):
1. an increase in v∗1 directly increases the expression (2);
2. some θ1 move from event E01 to event E∗1 , which weakly increases the expression (2) because any such θ1 must feature v∗1 ≥ 0;

3. some θ1 move from event EP1 to event E∗1 , which weakly increases the expression (2) because any such θ1 must feature v∗1 ≥ π1 + w1 ≥ w1 .
This proves that, in any subgame perfect equilibrium, choosing B is weakly
better than choosing any open source license o ∈ O such that P ∈ g(o).

In the proof of Theorem 2, the assumption of an absolutely continuous probability law P(· | ·) implies that developer 1 is indifferent (between developing software
1 or not, and between going proprietary or going open source) with probability 0.
If developer 1 is indifferent with strictly positive probability, how he breaks ties
has non-trivial implications on developer 0’s gross expected payoff. If developer
1 breaks ties in a manner that depends on some payoff-irrelevant details—suchas the name of the license, or whether the license allows for certain irrelevant
options—then it is possible that BSD does not fare as well as another license simply because the former leads developer 1 to break ties in a way that is unfavorable
to developer 0. If we alternatively assume that, say, developers always break ties
in favor of developing the software, and in favor of going open source, then we
can relax the assumption of absolute continuous P(· | ·) in Theorem 2.
Theorem 2 is silent on the existence of an equilibrium. It is easy to constructsimple examples where equilibria exist, and hence Theorem 2 is definitely not acharacterization of the empty set. It is also easy to construct (not necessarily interesting) sufficient conditions for existence of an equilibrium. But the applicability21

of Theorem 2 goes beyond the class of games confined by these sufficient conditions. It says that whenever an equilibrium exists, regardless of whether these
sufficient conditions are satisfied, developer 0 cannot do worse by ignoring open
source licenses other than GPL and BSD.

7

Insufficiency of GPL and BSD
The sufficiency result in Section 6 is surprising, especially given how little

restriction on the probability law P(· | ·) it relies on. Nevertheless, the proof of
Theorem 2 does rely on two particular assumptions that we have maintained up
to this point. The first is a linear structure of developers. The second is exponential discounting. These two assumptions together imply that the interests ofdevelopers 0 and 1 are aligned conditional on the event that developer 1 goes open
source. This alignment explains why developer 0 would like to give developer 1
the maximum freedom to choose which open source license to license software 1.
In this section, we shall show how the sufficiency result in Section 6 breaks
down once we relax any one of these two assumptions. Specifically, in Subsection
7.1, we shall show how license R can beat GPL and BSD if developers form atree instead of a linear structure. In Subsection 7.2, we shall show how license
1 can beat GPL and BSD if developers have hyperbolic instead of exponential
discounting.

7.1

An Example with a Tree Structure

Suppose developer 0, if going open source, can inspire two instead of only one
developers — call them developers 1A and 1B, respectively. Suppose this is the
only time that an open source software can inspire two developers. It means that
we will have a linear structure again starting from developer 1A: ∀n = 1, 2, . . ., an
open source software nA inspires one and only one developer, namely developer22

(n + 1)A, and so on. Likewise, there is a linear structure starting from developer
1B.
It is natural to assume that every developer cares only about the consumer
surplus generated by the offsprings of his own software. Therefore, for example,
developer 1A cares only about the consumer surplus generated by softwares 1A,
2A, 3A. . . , and developer 1B cares only about the consumer surplus generated bysoftwares 1B, 2B, 3B. . . , while developer 0 cares about consumer surplus generated
by all softwares. This creates a new wedge between the interests of developers 0
and 1A, for example, even conditional on the event that developer 1A develops
software 1A and goes open source. This wedge results in a breakdown of the proofof Theorem 2.
Suppose S = {O, g} is such that O = {G, R, B}, whereg(G) = {G},g(R) = {P, R},
andg(B) = {P} ∪ O.

Suppose developer 0 draws (c0 , π0 , w0 , W0 ) = (0, 0, 0, 1) with certainty. Apparently, he strictly prefers to develop software 0 and then go open source. Knowingthat his open source software will for sure inspire two developers, but not knowing their identities ex ante, he uses a single open source license o ∈ O to license his
software to both of them.
Suppose softwares 1A and 1B are “independent” of each other; roughly speaking, it means they neither complement nor substitute each other. Specifically, eachof developers 1A and 1B draws (c1 , π1 , w1 , W1 ) = (0, 0, 0, 1) with certainty, whereW1 = 1, for example, is the (internalizable) (marginal increase in) consumer surplus generated by an open source software 1A (1B) regardless of whether software
1B (1A) is developed and how it is distributed. Apparently, developer 1A (1B)
strictly prefers to develop software 1A (1B) and then go open source. What open

23

source licenses he can choose, however, depends on developer 0’s license o.
We assume that developers 1A and 1B choose their licenses oA and oB , respectively, simultaneously. Their choices are then observable to both developers 2A
and 2B.
Most of the actions in this example will take place in the game between developers 2A and 2B. Specifically, we “truncate” the game after generation 2 as follows:∀n ≥ 3, developer nA (nB) draws (cn , πn , wn , Wn ) = (1, 0, 0, 0) with certainty, andhence no developers after generation 2 will bother to develop their respective
softwares even if they have the chance to do so.
Before we describe the game between developers 2A and 2B in details, let’s firstsketch the main idea behind the construction. Softwares 2A and 2B are imperfect
substitutes. The two softwares together can generate more consumer surplus
than, but not as much as two times of, what a single software can generate. Itmeans the consumer surplus attributable to software 2B, for example, is smallerin the presence of software 2A, and gets even smaller if 2A goes open source.
When developer 1A forces software 2A to go open source, say by using licenseG, he generates a negative externality on developer 1B by reducing the consumer
surplus attributable to software 2B. While developer 1A does not internalize thisnegative externality, developer 0 does. Developer 0 hence may want to choose alicense that forbids developer 1A from using license G and generating this negative
externality. License R serves exactly this purpose.
We now describe the game between developers 2A and 2B. The game is symmetric, so we describe only the half from the perspective of developer 2A. Specifically, developer 2A’s (W, w, π) depends on the presence and the mode of distribution of software 2B as in Table 3.
The first notable feature of Table 3 is that, as explained earlier, the consumer
surplus attributable to software 2A is smaller in the presence of software 2B, andgets even smaller if 2B goes open source. The second notable feature is thatdeveloper 2A always strictly prefers going proprietary to going open source (i.e.,

24

2A’s

W
w
π

quitting
100
50
200

conditional on 2B
going proprietary going open source
90
60
40
20
160
70

Table 3: 2A’s (W, w, π) conditional on 2B’s action.
w + π > W) regardless of what developer 2B does (recall that their generation iseffectively the last generation). Only a license G from developer 1A will be able toforce developer 2A to go open source. Since the game is symmetric, Table 3 is also
the table of developer 2B’s (W, w, π) conditional on the presence and the mode of
distribution of software 2A.
The developing costs, cA and cB , of developers 2A and 2B, respectively, aredrawn from the joint distribution depicted in Table 4.
cB
cA

85
0

85
0.4
0.3

0
0.3
0

Table 4: Joint distribution of cA and cB .
Note that, when cA = 0, developer 2A strictly prefers to develop software 2A;
and likewise for the case of cB = 0. When cA = 85, he will still strictly prefers todevelop if he is allowed (say by a licence R) to go proprietary, because w + π isalways strictly bigger than 85 regardless of what developer 2B does. It remains tostudy his entry decision if he is only allowed to go open source (by a license G).
We consider two cases.
The first case is that his opponent, developer 2B, is allowed to go proprietary(say by a license R). In this case, as we have argued earlier, developer 2B will forsure develop and go proprietary regardless of cB . Therefore, by developing andgoing open source, developer 2A can obtain W = 90 > 85 according to Table 3. Hewill hence develop even when cA = 85.
25

The second case is that his opponent, developer 2B, is also only allowed to go
open source (by a license G). In this case, as we have argued earlier, developer 2B
will for sure develop and go open source if cB = 0. This in itself is bad enoughnews for developer 2A, because it happens with conditional probability 3/7 whencA = 85. Even in the best case scenario where developer 2B quits when cB = 85,
developer 2A’s conditional expected W is still only (4/7) × 100 + (3/7) × 60 < 85when cA = 85. Therefore, he will not develop when cA = 85.
We summarize the entry decisions of developers 2A and 2B, conditional on
the licenses they are subject to, in Table 5. We do not include license B in thetable, because it is effectively the same as license R from the perspective of thesedevelopers (recall that they are effectively the last generation).

if 2A is subject to licenseRG

if 2B is subject to licenseRG
yes \ yes
yes \ yes
yes \ yesno \ noTable 5: Will 2A (2B) develop if cA = 85 (cB = 85)?
We now use Table 5 to study the licensing game between developers 1A and 1B.
The game will be trivial if developer 0 used license G, in which case developers
1A and 1B have no choice but to use license G as well. According to Table 5,developer 2A (2B) will develop software 2A (2B) and go open source iff cA = 0(cB = 0). According to Table 4, it will never happen that both softwares 2A and2B are developed. Each software will be developed with probability 0.3. And
whenever it is developed, it is developed alone, generating consumer surplus
100. The expected consumer surplus attributable to software 2A (2B) and henceinternalized by developer 1A (1B) is hence 0.3 × 100 = 30, whereas developer 0
internalizes the sum 60.
The game will also be trivial if developer 0 used license R, in which case developers 1A and 1B have no choice but to use license R as well (recall that they bothstrictly prefer to go open source rather than proprietary). According to Table 5,26

developer 2A (2B) will always develop software 2A (2B) and go proprietary regardless of cA (cB ). The market will hence always have two proprietary generation-2
softwares available. According to Table 3, each proprietary software generates
consumer surplus 40, which is internalized by developers 1A and 1B, whereas
developer 0 internalizes the sum 80.
The game is non-trivial only if developer 0 used license B, in which case bothdevelopers 1A and 1B have the freedom to choose between licenses R and G.18 We
shall argue that using license G is the dominant strategy for both developers.
First consider the case where opponent 1B uses license R. In this case, according
to Table 5, whether 1A uses license R or G will not affect developer 2A’s entry
decision. Since, according to Table 3, W > w regardless of what developer 2B
does, developer 1A strictly prefers that developer 2A goes open source, and hence
strictly prefers to respond with license G rather than R.
Then consider the case where opponent 1B uses license G. If 1A uses license R,
according to Table 5, both softwares 2A and 2B will be developed for sure, with 2A
going proprietary and 2B going open source. According to Table 3, the consumer
surplus generated by the proprietary software 2A will be 20. If 1A uses license G
instead, according to the analysis two paragraphs earlier, the expected consumer
surplus generated by software 2A will be 30. Therefore, once again, developer 1A
strictly prefers to respond with license G rather than R.
To summarize, if developer 0 used license B, the unique continuation equilibrium is such that both developers 1A and 1B play their dominant strategy of using
license G. This is the same outcome as in the case had developer 0 used license
G. In both cases the total expected consumer surplus generated by generation-2
softwares is 60. If developer 0 uses license R instead, the total consumer surplus
generated by generation-2 softwares will be 80. Developer 0 hence strictly prefers
license R to licenses B and G.
18 Again, we ignore the choice of license B, which is effectively the same as license R from theperspective of developers 2A and 2B, who are effectively the last generation.

27

Proposition 1 In the example in this subsection, there is a unique subgame perfectequilibrium, where developer 0 develops software 0 and goes open source with license
R, developers 1A and 1B both develop their respective softwares and go open sourcewith license R, and developers 2A and 2B both develop their respective softwares and go
proprietary. Specifically, developer 0 strictly prefers using license R rather than licenses
B and G, even though the latters are also available.

7.2

An Example with Hyperbolic Discounting

It has become a common practice in behavioral economics to approximate hyperbolic discounting using an (α, β)-formulation. Here, we shall instead adopt an(α1 , α2 , β)-formulation. Specifically, given any infinite sequence of dated payoffs,{ut , ut+1 , ut+2 , . . .}, we assume that developer t’s present discounted value is
Ut = ut + α1 ut+1 + α2 ut+2 + βut+3 + β2 ut+4 + · · · ,where α1 ≤ α2 ≤ β.19
Consider the following example with hyperbolic discounting. Suppose α1 =1/4, α2 = 2/4, and β = 3/4; and ∀t ≥ 0, wt ≡ w = 15, and Wt ≡ W = 20. Suppose
the joint distribution of ct and πt is iid across t, and is as depicted in Table 6.
P(ct , πt )ct = 10ct = 20ct = 40πt = 0≈000πt = 200(1 − )/20

πt = 3500(1 − )/2

Table 6: Joint distribution of ct and πt .
19 As will be explained later, α

1 actually does not play any role, and hence the restriction α1 ≤ α2is redundant. We maintain this restriction only to stay in sync with the hyperbolic-discounting
literature.

28

Suppose S = {O, g} is such that O = {G, R, 1, B}, whereg(G) = {G},g(R) = {P, R},
g(1) = {P, G},
andg(B) = {P} ∪ O.

Since this is a stationary environment, we shall further restrict our attention topure-strategy Markov perfect equilibrium, in which every developer t follows thesame pure Markov strategy that depends only on (i) the open source license he issubject to, which in turn is chosen by developer t − 1,20,21 and (ii) the realization of(ct , πt ). More formally, a pure Markov strategy is a function σ : (c, π, o) 7→ {Q, P} ∪ Othat describes any developer’s choice over {Q, P} ∪ O given his draw of (c, π) andthe open source license o ∈ O that he is subject to, with the restriction that ∀(c, π, o),σ(c, π, o) ∈ {Q} ∪ g(o). A pure-strategy Markov perfect equilibrium (hereafter, anequilibrium) is a Markov strategy σ∗ that is optimal for any developer t among
all pure Markov strategies if all future developers s > t follow the pure Markov
strategy σ∗ .
Consider any developer t. If he develops software t and goes open source,
his gross payoff (gross of development cost ct ) is at least Wt = W = 20 (which isachived if no future software is developed), and is at most






Wt + α1 Wt+1 + α2 Wt+2 + βWt+3 + β2 Wt+4 + · · · = W + α1 W + α2 W + βW + β2 W + · · ·= 35(which is achieved if all future developers develop their softwares and go open
20 Recall that if developer t − 1 did not choose any open source license, then either he did not
develop software t − 1, or he did but chose to go proprietary. In either case, developer t would nothave a chance to move.
21 Recall that we can treat developer 0 as if he is subject to license B.

29

source). We can obtain a number of observations from these lower and upperbounds.
First, from the lower bound we can infer that σ(10, 0, ·) ∈ O (because the grossexpected payoff of going open source is at least 20). This in turn implies that thegross expected payoff of going open source is strictly higher than 20, because theprobability that the next developer developing his software is strictly positive.
Second, from the upper bound we can infer that σ(40, 35, G) = Q and σ(40, 35, B) =σ(40, 35, R) = σ(40, 35, 1) = P (because by going open source the gross expected
payoff is at most 35 < 50 = πt + wt ). It means the probability of any developer t
going open source is at most 1 − P(40, 35) = (1 + )/2 ≈ 1/2. This in turn implies atighter upper bound for the gross expected payoff of going open source, which isapproximately


W+w
W+w
W+w
1
2W + w
W + α1+ α2+β+β+ · · · = 33 < 35.
2
2
2
2
8


From this tighter upper bound we can infer that σ(20, 20, B) = σ(20, 20, R) =σ(20, 20, 1) = P (because by going open source the gross expected payoff is strictly
less than 35 = πt + wt ).
Finally, since the gross expected payoff of going open source is strictly higher
than 20, we have σ(20, 20, G) = G.
These observations imply that the equilibrium Markov strategy must be as
depicted in Tables 7 and 8.
σ(c, π, G)
c = 10c = 20c = 40π=0G––

π = 20 π = 35
–
–
G
–
–
Q

Table 7: The equilibrium Markov strategy for a developer who is subject to G.
Now consider the problem of a developer t who is subject to license B and has
drawn (ct , πt ) = (10, 0). If he chooses G, all future developers’ behavior will be30

σ(c, π, B/R/1)
c = 10c = 20c = 40

π=0
o∈O
–
–

π = 20 π = 35
–
–
P
–
–
P

Table 8: The equilibrium Markov strategy for a developer who is subject to B, R,
or 1.
described by Table 7, and hence his gross expected payoff will be approximately



!

β
β 2
1
α2 
α1 
W + · · ·  = 23 .
VG = W +W +W + W +222
22
If he chooses either B, R, or 1, with probability close to 1 the next developer
will go proprietary, and hence his gross expected payoff is approximately
3
1
VB/R/1 = W + α1 w = 23 > 23 = VG .
4
2
Therefore, σ(10, 0, B) ∈ {B, R, 1}. To compare these three contenders, note thatthey differ only in developer t’s continuation payoff conditional on the event that(ct+1 , πt+1 ) = (10, 0), and hence it suffices to ask what developer t may want toallow developer t + 1 to choose in that event (hereafter event E).
Conditional on event E, if developer t + 1 chooses G, the present value ofdeveloper t’s continuation payoff will be approximately



!



β
β 2
α
2
W + W +VE:G = α1 W +
W + · · ·  = α1 × 28.
2
22
Conditional on event E, if developer t + 1 chooses either B, R, or 1, the present
value of developer t’s continuation payoff will be approximately
1
VE:B/R/1 = α1 (W + α2 w) = α1 × 27 < α × 28 = VE:G .
2

31

Therefore, when choosing among B, R, and 1, developer t would like to choose
the one that only allows developer t + 1 to choose G. This goal can be achieved bychoosing 1. We summarize these with the following proposition.
Proposition 2 In the example in this subsection, a pure-strategy Markov perfect equilibrium always exists and is unique. In a pure-strategy Markov perfect equilibrium, developer0
1. develops software 0 and goes proprietary when (c0 , π0 ) = (20, 20) or (40, 35); and2. develops software 0 and goes open source with the 1-chance-only license 1 when(c0 , π0 ) = (10, 0).
What is going on? Intuitively, if developer t + 2 is allowed to go proprietary, heis more likely to develop software t + 2, but the stream of consumer surplus will also
more likely terminate in period t + 2. To decide whether to allow developer t + 2
to go proprietary, one is hence trading off consumer surplus in period t + 2 versus
consumer surplus in periods s ≥ t + 3, which depends on that decision maker’s
discount rate between periods t + 2 and t + 3. With hyperbolic discounting, this
discount rate is higher for developer t + 1 than for developer t, meaning thatdeveloper t + 1 is more tempted, compared to developer t, to allow developer t + 2
to go proprietary. Developer t hence may want to choose an open source licensethat forbids developer t + 1 from allowing developer t + 2 to go proprietary. Whileboth G and 1 come with this same forbiddance, 1 has the extra benefit over G inallowing developer t + 1 to go proprietary. This is a benefit for developer t because,just like developer t + 1, developer t discounts the future hyperbolically and henceis equally tempted to allow the next developer to go proprietary.
The above intuition also explains why we need an (α1 , α2 , β)-formulation toapproximate hyperbolic discounting, instead of the more traditional (α, β) one. The
key misalignment between developers t’s and t + 1’s interests lies in their discountrates between periods t + 2 and t + 3; i.e., between α2 and β. The assumption that32α2 ≤ β implies that developer t is more patient than developer t + 1, and hence will
like to limit the latter’s ability to reap an earlier reward. In contrast, α1 does notplay any role in this story, and the assumption that α1 ≤ α2 can be relaxed without
affecting our results.

8

Concluding Remarks
The open source movement is nothing short of a revolution in how production

is organized. It has rightfully attracted a lot of economic studies, but very few on
the very licenses that made this revolution possible. This paper is the first attempt
to provide a theoretical framework to study all open source licenses, including
but not limited to the two most popular ones, namely GPL and BSD. We haveprovided an explanation of why GPL and BSD stood out from all these open
source licenses as the most popular among open source developers. We have alsopresented settings where there are other open source licenses better than GPL and
BSD.
One of the settings is where developers form a tree instead of a linear structure(see Subsection 7.1). Looking forward, we believe the most fertile ground for
future research is to study how a developer can use different open source licenses
to moderate the competition among his offsprings.
Studying a tree structure of developers, however, is exponentially more complicated than studying a linear structure of developers. Our example in Subsection
7.1 has already given a hint on one such complication, namely the necessity to
specify the substitutability among softwares within the same generation. Whilethe example in Subsection 7.1 involves only a minimal tree structure, the task of
specifying substitutability can quickly become exponentially daunting in a morenaturally-looking tree structure. For example, imagine a tree structure where every developer has two immediate offsprings: 1A and 1B from developer 0, 2Aaand 2Ab from developer 1A, 2Ba and 2Bb from developer 1B. . . , etc. It is natu-

33

ral to assume that software 2Aa is a closer substitute for software 2Ab than forsoftware 2Ba. It means there are already two different levels of substitutability
among generation-2 softwares. In general, there are at least n different levels of
substitutability among generation-n softwares. It will need some clever modellingto keep such complications manageable without reducing the model back to one
with a linear structure. We leave this difficult task for future research.

References[1] Atal, Vidya and Kameshwari Shankar (2014), “Open Source Software: Competition with a Public Good.” Atlantic Economic Journal, 42: 333-345.
[2] Atal, Vidya and Kameshwari Shankar (2015), “Developers’ Incentives andOpen-Source Software Licensing: GPL vs BSD.” B.E. Journal of Economic Analysis and Policy, 15(3): 1381-1416.
[3] Athey, Susan and Glenn Ellison (2014), “Dynamics of Open Source Movements.” Journal of Economics and Management Strategy, 23(2): 294-316.
[4] Balter, Ben (2015), “Open Source License Usage on GitHub.com.”
https://github.blog/2015-03-09-open-source-license-usage-on-github-com/(last accessed on November 23, 2022)[5] Brandenburger, Adam and Eddie Dekel (1993), “Hierarchies of Beliefs andCommon Knowledge.” Journal of Economic Theory, 59: 189-198.
[6] Casadesus-Masanell, Ramon and Pankaj Ghemawat (2006), “Dynamic Mixed
Duopoly: A Model Motivated by Linux vs. Windows.” Management Science,52(7): 1072-1084.
[7] Comino, Stefano, Fabio M. Manenti, and Maria Laura Parisi (2007), “From
Planning to Mature: On the Success of Open Source Projects.” Research Policy,
36: 1575-1586.
34

[8] Economides, Nicholas and Evangelos Katsamakas (2006), “Two-Sided Competition of Proprietary vs. Open Source Technology Platforms and the Implications for the Software Industry.” Management Science, 52(7): 1057-1071.
[9] Fershtman, Chaim and Neil Gandal (2007), “Open Source Software: Motivation and Restrictive Licensing.” International Economics and Economic Policy, 4:
209-225.
[10] Fershtman, Chaim and Neil Gandal (2011), “A Brief Survey of the Economics
of Open Source Software.” In Palgrave Macmillan (ed.), The New Palgrave
Dictionary of Economics, online edition.
[11] Fielding, Roy T. (1999), “Shared Leadership in the Apache Project.” Communications of the ACM, 42(4): 42-43.
[12] Gaudeul, Alex (2004), “Open Source Software Development Patterns andLicense Terms.” Toulouse working paper.
[13] Gaudeul, Alex (2005), “ Public Provision of a Private Good: What is the Pointof the BSD License?” Toulouse working paper.
[14] Gaudeul, Alex (2007), “Do Open Source Developers Respond to Competition?
The (La)TEXCase Study.” Review of Network Economics, 6(2): 239-263.
[15] Han, Xintong and Lei Xu (2019), “Technology Adoption in Input-Output
Networks.” Bank of Canada Staff Working Paper 2019-51.
[16] Hertel, Guido, Sven Niedner, and Stefanie Herrmann (2003), “Motivation ofSoftware Developers in Open Source Projects: An Internet-Based Survey ofContributors to the Linux Kernel.” Research Policy, 32: 1159-1177.
[17] Johnson, Justin P. (2002), “Open Source Software: Private Provision of a Public
Good.” Journal of Economics and Management Strategy, 11(4): 637-662.

35

[18] Johnson, Justin P. (2006), “Collaboration, Peer Review and Open Source Software.” Information Economics and Policy, 18: 477-497.
[19] Lerner, Josh, Parag A. Pathak, and Jean Tirole (2006), “The Dynamics ofOpen-Source Contributors.” American Economic Review, 96(2): 114-118.
[20] Lerner, Josh and Jean Tirole (2002), “Some Simple Economics of Open Source.”
Journal of Industrial Economics, 50(2): 197-234.
[21] Lerner, Josh and Jean Tirole (2005a), “The Economics of Technology Sharing:
Open Source and Beyond.” Journal of Economic Perspectives, 19(2): 99-120.
[22] Lerner, Josh and Jean Tirole (2005b), “The Scope of Open Source Licensing.”
Journal of Law, Economics, and Organization, 21(1): 20-56.
[23] Llanes, Gastón and Ramiro de Elejalde (2013), “Industry Equilibrium with
Open Source and Proprietary firms.” International Journal of Industrial Organization, 31(1): 36-49.
[24] Mariotti, Thomas, Martin Meier, and Michele Piccione (2005), “Hierarchies
of Beliefs for Compact Possibility Models.” Journal of Mathematical Economics,
41: 303-324.
[25] Mertens, Jean-François and Shmuel Zamir (1985), “Formulation of Bayesian
Analysis for Games with Incomplete Information.” International Journal ofGame Theory, 14: 1-29.
[26] Mockus, Audris, Roy T. Fielding, and James D. Herbsleb (2002), “Two Case
Studies of Open Source Software Development: Apache and Mozilla.” ACM
Transactions on Software Engineering and Methodology, 11(3): 309-346.
[27] Raymond, Eric S. (1999), The Cathedral and the Bazaar: Musings on Linux andOpen Source by an Accidental Revolutionary, O’Reilly.

36[28] Roberts, Jeffrey A., Il-Horn Hann, and Sandra A. Slaughter (2006), “Understanding the Motivations, Participation, and Performance of Open Source
Software Developers: A Longitudinal Study of the Apache Projects.” Management Science, 52(7): 984-999.
[29] Smith, P. McCoy (2022), “Copyright, Contract, and Licensing in Open Source.”
In Amanda Brock (ed.), Open Source Law, Policy and Practice, Oxford University
Press.
[30] Vendome, Christopher, Gabriele Bavota, Massimiliano Di Penta, Mario
Linares-Vásquez, Daniel Germán, and Denys Poshyvanyk (2017), “License
Usage and Changes: A Large-Scale Study on GitHub.” Empirical Software
Engineering, 22: 1537-1577.
[31] von Hippel, Eric and Georg von Krogh (2003), “Open Source Software andthe ‘Private-Collective’ Innovation Model: Issues for Organization Science.”
Organization Science, 14(2): 209-223.

37

Appendix A: GPL vs BSD
In this appendix, we shall demonstrate how, if we are willing to impose strong
assumptions on the probability law P(· | ·), we can obtain some interesting characterizations on when developer 0 will choose GPL rather than BSD, and viceversa.
Consider the following example. Suppose β = 1/2; and ∀t ≥ 0, wt ≡ w = 1 andWt ≡ W = 3. Suppose the joint distribution of ct and πt is iid across t, and is as
depicted in Table 9, where z indexes the correlation between ct and πt (with z = 1
means perfect positive correlation, and z = −1 means perfect negative correlation).
P(ct , πt )ct = 1ct = 7πt = 1(1 + z)/4(1 − z)/4πt = 7(1 − z)/4(1 + z)/4

Table 9: Joint distribution of ct and πt .
Note that ct = 1 or 7 with the same marginal probability, and πt = 1 or 7 withthe same marginal probability.
Since this is a stationary environment, we shall further restrict our attention topure-strategy Markov perfect equilibrium. Our notations and definitions follow
closely those in Subsection 7.2, with the exception that O = {G, B}, g(G) = {G}, andg(B) = {P} ∪ O.
Consider any developer t. If he develops software t and goes open source,
his gross payoff (gross of development cost ct ) is at least Wt = W = 3 (which isachieved if no future software is developed), and is at mostWt + βWt+1 + β2 Wt+2 + · · · = W/(1 − β) = 3/(1 − 1/2) = 6(which is achieved if all future developers develop their softwares and go open
source). Therefore,
1. if ct = 1, he should develop software t, he should go open source if πt = 1
38

(because by going open source he can get at least 3 > 2 = πt + wt ), and heshould go proprietary if πt = 7 (provided he has such an option);
2. if ct = 7, he should never go open source (because by going open source he
can get at most 6), and he should not even develop software t if πt + wt < 7(or, equivalently, if πt < 6); and3. if πt = 7 and he has the option to go proprietary, he should develop softwaret and then go proprietary.
These observations imply that the equilibrium strategy for a developer who issubject to license G (and hence cannot choose P or B) and for a developer who issubject to license B, respectively, must be the ones depicted in Tables 10 and 11.
σ(c, π, G)
c=1
c=7

π=1
G
Q

π=7
G
Q

Table 10: The equilibrium Markov strategy for a developer who is subject to G.
σ(c, π, B)
c=1
c=7

π=1
o∈O
Q

π=7
P
P

Table 11: The equilibrium Markov strategy for a developer who is subject to B.
Now consider the problem of a developer t who is subject to license B when
(ct , πt ) = (1, 1). If he chooses G, all future developers’ behavior will be describedby Table 10, and hence his gross expected payoff (gross of development cost) willbe
VG = Wt + (β/2)Wt+1 + (β/2)2 Wt+2 + · · · = W/(1 − 1/4) = 3/(1 − 1/4) = 4.
If he chooses B, his payoff will depend on future developers’ license decisions
in the same situation; i.e., it will depend on σ(1, 1, B). Suppose σ(1, 1, B) = B, then39his gross expected payoff will be
VBB = W + β





 
1+z
1−z 1+z
26
VBB +
+
w =
.
4
4
4
7−z

Suppose, instead, σ(1, 1, B) = G, then his gross expected payoff will be
VBG = W + β





 
1+z
1−z 1+z
15 + 2z
VG +
+
w =
.
4
4
4
4

An equilibrium with σ(1, 1, B) = B exists iff VBB ≥ VG ; i.e., iff z ≥ 1/2. An
equilibrium with σ(1, 1, B) = G exists iff VG ≥ VBG ; i.e., iff z ≤ 1/2. We summarize
these with the following proposition.
Proposition 3 In the example in this appendix a pure-strategy Markov perfect equilibrium always exists, and is generically unique. In a pure-strategy Markov perfectequilibrium, developer 0
1. does not develop software 0 if development cost is high and potential profit is low(i.e., when (c0 , π0 ) = (7, 1));
2. develops software 0 and goes proprietary whenever potential profit is high (i.e.,
whenever π0 = 7);
3. develops software 0 and goes open source when both development cost and potential
profit are low (i.e., when (c0 , π0 ) = (1, 1)); he goes open source using BSD if future
development costs and potential profits are sufficiently positively correlated (i.e., ifz ≥ 1/2), and using GPL otherwise.
Intuitively, developer 0 would like to see his idea further developed. However,development incurs development costs. In the unfortunate event that the next developer (i.e., developer 1) finds his development cost high, he will be discouraged
from further developing developer 0’s idea, especially if he is also prohibited fromgoing proprietary and making a profit out of his effort. If development cost and40potential profit are positively correlated such that a higher potential profit typically accompanies a higher development cost, then BSD, by allowing developer 1
to go proprietary, will help encourage developer 1 to further develop developer
0’s idea even in this unfortunate event. BSD hence can be the optimal choice
for a developer going open source if development cost and potential profit are
positively correlated, while GPL can be the optimal choice in the case of negative
correlation.

41

Appendix B: The Universal Space of Open Source Licenses
In this appendix, we shall construct the universal space of open source licenses,
OU , gU , that contains every space of open source licenses as its sub-space.

SU =The construction is similar to that of the universal type space in epistemic gametheory.
We say that a space of open source licenses S = (O, g) is finite if g(o) is finite
for every o ∈ O. Note that the set of open source licenses O needs not be finite
even when the space S = (O, g) is finite, as finiteness refers only to the number of
options, |g(o)|, allowed by each open source license o ∈ O.

To construct the universal space of open source licenses, SU = OU , gU , we firstrecursively construct a sequence of nonempty sets (Θ0 , Ω0 , Θ1 , Ω1 , . . .) as follows.
Let Θ0 = Ω0 = {0, 1}. For n ≥ 1, letΘn = P(Ωn−1 )Ωn = Ωn−1 × Θn
= Ωn−2 × Θn−1 × Θn
= ···= Ω0 × Θ1 × · · · × Θn
= Θ0 × Θ1 × · · · × Θn .
A sequence (θ0 , θ1 , . . .) is called a restriction hierarchy if θn ∈ Θn for any n ≥ 0.
Let Ω∞ be the set of all restriction hierarchies. Intuitively, an open source licenses
can be represented by a restriction hierarchy (θ0 , θ1 , θ2 , . . .) with
• θ0 specifying whether the next developer—say, developer t—is allowed togo proprietary (where θ0 = 1 means “yes” and θ0 = 0 means “no”),• θ1 specifying what restrictions developer t is allowed to impose on developert + 1 regarding the option of going proprietary,42• θ2 specifying what restrictions developer t is allowed to impose on developert + 1 regarding both (i) the option of going proprietary and (ii) what restrictions
developer t + 1 can impose on developer t + 2 regarding the option of goingproprietary,• . . . , etc.
To illustrate how an open source license can be represented by a restriction
hierarchy, let’s construct the restriction hierarchy (θG, θG, . . .) that represents the0
1
GPL license G.
To determine θG, we ask whether GPL allows the next developer—say, devel0
oper t—to go proprietary. No, it does not. Therefore, θG= 0.
0
To determine θG, we ask what options developer t has regarding whether
1

to allow developer t + 1 to go proprietary. GPL gives developer t only a single
option—meaning that θGmust be a singleton. Moreover, that single option is1

to use GPL as well, whose first restriction has already been encoded in θG
.22
0
n o
Therefore, θG
must be the singleton θG= {0}.
0
1, we ask what options developer t has regarding (i) whether to
To determine θG2allow developer t + 1 to go proprietary, and (ii) whether to allow developer t + 1
to allow developer t + 2 to go proprietary. GPL gives developer t only a single
option—meaning that θGmust be a singleton. Moreover, that single option is to2
use GPL as well, whose first two restrictions have already been encoded in θG
and
0
n
o
, θG
= {(0, {0})}.
θG.23 Therefore, θG
must be the singleton θG
2
0
1
1More generally, for any n ≥ 1, θGn must be a singleton, and must be the singleton
n
o
G
G
G
θ0 , θ1 , . . . , θn−1 .
G, . . . ,The GPL license can hence be represented by the restriction hierarchy θG,θ01
22 The GPL license carries infinitely many restrictions. Here, we are concerned about only its first

restriction, namely whether it allows the next developer to go proprietary.
23 GPL carries infinitely many restrictions. Here, we are concerned about only its first two
restrictions, namely (i) whether it allows the next developer to go proprietary, and (ii) whether itallows the next developer to allow the next-next developer to go proprietary.

43where:θG
0 = 0,
θG
1 = {0},θG
2 = {(0, {0})},θG
3 = {(0, {0}, {(0, {0})})},(3)θG
4 = {(0, {0}, {(0, {0})}, {(0, {0}, {(0, {0})})})},
..
..


R , . . . that represents
Likewise we can construct the restriction hierarchy θR,θ01
the recursive-BSD license R. The recursive-BSD license allows the next developer
to go proprietary, and hence θR= 1. If the next developer chooses to go open0source, the recursive-BSD license gives him only a single option—meaning thatfor any n ≥ 1, θRn must be a singleton. Moreover, that single option is to use therecursive-BSD license as well, whose first n restrictions have already been encodednoR , . . . , and θR . Therefore, θR must be the singleton θR , θR , . . . , θR
in θR
,
θ
.
n
0
0
1
n−1
1
n−1
The recursive-BSD license can hence be represented by the restriction hierarchyR , . . . , where:
θR
,
θ
0
1
θR
0 = 1,
θR
1 = {1},θR
2 = {(1, {1})},θR
3 = {(1, {1}, {(1, {1})})},(4)θR
4 = {(1, {1}, {(1, {1})}, {(1, {1}, {(1, {1})})})},
..
..


As our final example, let’s also construct the restriction hierarchy θ10 , θ11 , . . .
that represents the 1-chance-only license 1. The 1-chance-only license allows the44

next developer to go proprietary, and hence θ10 = 1. If the next developer chooses
to go open source, the 1-chance-only license gives him only a single option—
meaning that for any n ≥ 1, θ1n must be a singleton. Moreover, that single option is
to use GPL, whose first n restrictions have already been encoded in θG, θG, . . . , and
0
1
n
o
θG
. Therefore, θ1n must be the singleton θG, θG, . . . , θG
. The 1-chance-only
0
n−1
1
n−1 

license can hence be represented by the restriction hierarchy θ10 , θ11 , . . . , where:θ10 = 1,
θ11 = {0},
θ12 = {(0, {0})},θ13 = {(0, {0}, {(0, {0})})},(5)

θ14 = {(0, {0}, {(0, {0})}, {(0, {0}, {(0, {0})})})},..
..
For any restriction hierarchy (θ0 , θ1 , . . .), to the extent that it represents an open
source license (not yet, as we shall see shortly), we should be able to extract from
θ0 whether it allows the next developer to go proprietary, and from (θ1 , θ2 , . . .)what open source licenses it allows the next developer to use. The first task is easy
(θ0 = 1 means “yes”, and θ0 = 0 means “no”), and the second task can be done bydefining a correspondence Γ : Ω∞ ⇒ Ω∞ as follows: for any (θ0 , θ1 , . . .) ∈ Ω∞ and(θ00 , θ01 , . . .) ∈ Ω∞ , (θ00 , θ01 , . . .) ∈ Γ(θ0 , θ1 , . . .) iff ∀n ≥ 0,24
θ00 , . . . , θ0n ∈ θn+1 ∈ Θn+1 = P(Ωn ) = P (Θ0 × Θ1 × · · · × Θn ) .

(6)

As an illustration, if we apply the correspondence Γ to restriction hierarchies
24 We abuse notation by writing Γ((θ , θ , . . .)) as Γ(θ , θ , . . .), although Γ has only one argument,
0 1
0 1
namely the vector (θ0 , θ1 , . . .).

45





 
G , . . . , θR , θR , . . . , and θ1 , θ1 , . . . , we will obtain
,
θ
θG
0 1
0
0
1
1

 n
o
G
G G
Γ θG
,
θ
,
.
.
.
=
θ
,
θ
,
.
.
.
,
0
0
1
1

 n
o
R
R R
Γ θR
0 , θ1 , . . . = θ0 , θ1 , . . . ,

 n
o
G
Γ θ10 , θ11 , . . . = θG
,
θ
,
.
.
.
,
0
1

and

confirming the fact that a developer who is subject to open source license G(respectively, R and 1), if going open source, is only allowed to do so using open
source license G (respectively, R and G).
While an open source license can be represented by a restriction hierarchy,
however, not every restriction hierarchy can be the representation of an open
source license. In order for a restriction hierarchy (θ0 , θ1 , θ2 , . . .) to represent an
open source license, it needs to satisfy a consistency requirement. To motivate
this consistency requirement, note that both θ1 and θ2 contain information onwhat restrictions developer t is allowed to impose on developer t + 1 regarding
the option of going proprietary, and these two pieces of information must agreewith each other. More generally, for any n ≥ 1, θn and θn+1 must be consistent in
the sense that ProjΩn−1 θn+1 = θn .25
Definition 3 A restriction hierarchy (θ0 , θ1 , . . .) is consistent if ProjΩn−1 θn+1 = θn forany n ≥ 1.
 
G , . . . , θR , θR , . . . ,The reader can readily check that the restriction hierarchies θG
,
θ
0
0
1
1


and θ10 , θ11 , . . . are all consistent, because for any n ≥ 1,
n
o n
o
G
G
G
G
G
=
Proj
θ
,
.
.
.
,
θ
=
θ
,
.
.
.
,
θ
ProjΩn−1 θGnΘ0 ×···×Θn−1
0
0
n+1
n−1 = θn ,
n
o n
o
R
R
R
R
R
ProjΩn−1 θR
=
Proj
θ
,
.
.
.
,
θ
=
θ
,
.
.
.
,
θ
n
Θ0 ×···×Θn−1
0
0
n+1
n−1 = θn ,
n
o n
o
G
G
G
1
ProjΩn−1 θ1n+1 = ProjΘ0 ×···×Θn−1 θG
,
.
.
.
,
θ
=
θ
,
.
.
.
,
θ
n
0
0
n−1 = θn .

and

25 ProjΩn−1 θn+1 denotes the projection of θn+1 ∈ Θn+1 = P(Ωn ) = P (Ωn−1 × Θn ) into Ωn−1 , resulting in a subset of Ωn−1 . Consistency requires that this subset is the same as θn ∈ P(Ωn−1 ).

46

Let O1 be the set of all consistent restriction hierarchies.
Lemma 1 For any consistent restriction hierarchy (θ0 , θ1 , . . .) ∈ O1 , the subset Γ(θ0 , θ1 , . . .) ⊂Ω∞ is nonempty.
Proof:

We first show that there exists θ00 ∈ θ1 . This follows from θ1 ∈ Θ1 =P(Ω0 ) = P(Θ0 ) and P(Θ0 ) does not contain the empty set.
For any n ≥ 1, assume that there exists θ00 , . . . , θ0n−1 ∈ θn . Since (θ0 , θ1 , . . .)is consistent, we have ProjΩn−1 θn+1 = θn , and hence θ00 , . . . , θ0n−1 ∈ ProjΩn−1 θn+1


as well. Therefore, there exists θ0n such that θ00 , . . . , θ0n−1 , θ0n ∈ θn+1 . By induction, there hence exists a restriction hierarchy (θ00 , θ01 , . . .) ∈ Ω∞ such that, ∀n ≥ 0,
(θ00 , . . . , θ0n ) ∈ θn+1 , implying that Γ(θ0 , θ1 , . . .) is nonempty.

That the restriction hierarchy (θ0 , θ1 , . . .) is consistent, however, does not guarantee that those restriction hierarchies in Γ(θ0 , θ1 , . . .) are also consistent. Therefore,
we shall define
O2 = {(θ0 , θ1 , . . .) ∈ O1 : Γ(θ0 , θ1 , . . .) ⊂ O1 } ,and retain only restriction hierarchies in O2 .
That every restriction hierarchy (θ00 , θ01 , . . .) in Γ(θ0 , θ1 , . . .) is consistent, however, does not guarantee that those restriction hierarchies in Γ(θ00 , θ01 , . . .) are also
consistent. Therefore, we shall not stop here, and shall continue and recursively
define, for any k ≥ 2,
Ok = {(θ0 , θ1 , . . .) ∈ Ok−1 : Γ(θ0 , θ1 , . . .) ⊂ Ok−1 } .
We shall now define
U

O =

∞
\

Ok ,

k=1

which will be the set of every restriction hierarchy that represents an open source
47

license.26

 



G , . . . , θR , θR , . . . , and θ1 , θ1 , . . .
The reader can readily check that each of θG
,
θ
0 1
0
0
1
1
belongs to OU . Indeed, we have already seen that they are all consistent and hence
belong to O1 . For any k ≥ 1, assume that they have already been shown to belong
to Ok . Then we have

 n
o
G
G G
Γ θG
,
θ
,
.
.
.
=
θ
,
θ
,
.
.
.
⊂ Ok
0
0
1
1


G , . . . belongs to O
by the inductive assumption, and hence θG,θ
k+1 as well; and



 0 1
similarly for θR, θR, . . . and θ10 , θ11 , . . . . Therefore, by induction, all of them0
1
belong to Ok for any k ≥ 1, and hence belong to OU . This also shows that OU isnonempty.
Define gU : OU → P {P} ∪ OU such that, for any consistent restriction hierarchy (θ0 , θ1 , . . .) ∈ OU ,
if θ0 = 0Γ(θ0 , θ1 , . . .)Ug (θ0 , θ1 , . . .) = .
Γ(θ0 , θ1 , . . .) ∪ {P} if θ0 = 1(7)

We shall call the pair SU = (OU , gU ) the universal space of open source licenses.
The following two theorems justify why this terminology is appropriate. The first
theorem states that SU is in itself a space of open source licenses. The second
theorem states that any finite irreducible space of open source licenses is a subspace of SU . These two theorems (except for the “1-to-1” part of Theorem 4) can
also be proved as corollaries of Mariotti, Meier, and Piccione’s (2005) Proposition
3, by recognizing that any finite space of open source licenses can be made into
a compact continuous possibility structure.27 Below we provide an elementary
proof without topology for each of these two theorems.
26 Readers familiar with the classical construction of the universal type space will recognize that

this step is akin to the imposition of common knowledge of coherency.
27 We thank Yi-Chun Chen for pointing this out to us.

48

Theorem 3 The universal space of open source licenses SU is in itself a space of open
source licenses.
Proof: We have already seen that OU is nonempty, as it contains, for example,




 
G , . . . , θR , θR , . . . , and θ1 , θ1 , . . . . For any o ∈ OU ⊆ O , by Lemma 1,
θG
,
θ
1
0 1
0
0
1
1
Γ(o) is a nonempty subset of Ω∞ . Moreover, for any k ≥ 1, Γ(o) ⊆ Ok becauseo ∈ OU ⊆ Ok+1 , and hence Γ(o) is also a nonempty subset of ∩k Ok = OU . Therefore,gU (o) ∩ OU = Γ(o) , ∅, and hence S = OU , gU is in itself a space of open source
licenses.



Theorem 4 Any finite irreducible space of open source licenses S = (O, g) is a sub-spaceof the universal space of open source licenses in the sense that there exists a 1-to-1 mappingf : O → OU , called the canonical representation, such that for any o ∈ O,
P ∈ g(o) ⇐⇒ P ∈ gU ( f (o))
ando0 ∈ g(o) ⇐⇒ f (o0 ) ∈ gU ( f (o)).

(8)

We prove Theorem 4 in three steps. We first explicitly construct a mapping
f from O into the set of all restriction hierarchies Ω∞ . We call this mapping the
canonical representation of open source licenses. We then prove that the range off actually lies inside OU (Lemma 2). Finally, we prove that, if S = (O, g) is finite
irreducible, this will be a 1-to-1 mapping that satisfies (8) (Lemma 3).
We construct the canonical representation f by recursively defining a sequence
of mappings f0 , f1 , . . . , with each fn a mapping from O into Θn . We first define f0
such that, for any o ∈ O,




0
f0 (o) = 
1

if P < g(o)if P ∈ g(o).

Suppose we have already defined mappings ( f0 , . . . , fn ), we then define fn+1

49

such that, for any o ∈ O,
fn+1 (o) =f0 (o0 ), . . . , fn (o0 ) : o0 ∈ g(o) ∩ O .

We can now define the canonical representation f : O → Ω∞ such that, for anyo ∈ O,
f (o) = ( f0 (o), f1 (o), . . .).
Lemma 2 The range of the canonical representation f lies inside OU .
Proof:

We first prove that, for any o ∈ O, f (o) is a consistent restriction hierarchy.

Let f (o) = (θ0 , θ1 , . . .). For any n ≥ 1,
ProjΩn−1 θn+1 = ProjΩn−1 fn+1 (o)= ProjΩn−1 f0 (o0 ), . . . , fn (o0 ) : o0 ∈ g(o) ∩ O= f0 (o0 ), . . . , fn−1 (o0 ) : o0 ∈ g(o) ∩ O(9)= fn (o) = θn ,and hence f (o) is a consistent restriction hierarchy.
noGiven any o ∈ O. Consider a sequence θk0 , θk1 , . . .

k≥1of restriction hierarchies

such that∀k > 1,θ10 , θ11 , . . . ∈ Γ( f (o)), and




k−1
θk0 , θk1 , . . . ∈ Γ θk−1
,
θ
,
.
.
.
.
0
1

(10)

o
n
We claim that, ∀k ≥ 1, there exists ok0 , ok1 , . . . ⊂ O such that,∀n ≥ 0,    
θk0 , . . . , θkn = f0 okn , . . . , fn okn .

(11)

We prove this claim by induction. Consider k = 1. Since (θ10 , θ11 , . . .) ∈ Γ( f (o)),

50we have, ∀n ≥ 0,
θ10 , . . . , θ1n ∈ fn+1 (o) = f0 (o0 ), . . . , fn (o0 ) : o0 ∈ g(o) ∩ O ,
  
 
and hence there exists o1n ∈ g(o) ∩ O such that (θ10 , . . . , θ1n ) = f0 o1n , . . . , fn o1n .
onAssume we have already proved that, for some k ≥ 1, there exists ok0 , ok1 , . . . ⊂ Ok+1 , . . . ∈ Γ θk , θk , . . . , we have, ∀n ≥ 0,that satisfies (11). Since θk+1
,
θ
0
0 1
1
o



 n


k
k
0
0 
0
k
θ0k+1 , . . . , θk+1
∈
θ
=
f
o
=
f
(o
),
.
.
.
,
f
(o
)
:
o
∈
g
o
∩
O
,
n
0
n+1 n+1
n
n+1
n+1


 



k
k+1 , . . . , θk+1 ) = f ok+1 , . . . , f ok+1 .
o
∩
O
such
that
(θ
and hence there exists ok+1
∈
g
n
0
n
n
n
n
0
n+1
By induction, the claim is hence true for all k ≥ 1.
Given any θk0 , θk1 , . . . , for any n ≥ 0,ProjΩn−1 θkn+1 = ProjΩn−1 fn+1 okn+1= fn okn+1 = θkn ,where the second equality follows from (9), and the last equality follows from(θk0 , . . . , θkn , θkn+1 ) = f0 (okn+1 ), . . . , fn (okn+1 ), fn+1 (okn+1 ) . Therefore, θk0 , θk1 , . . . is aconsistent restriction hierarchy.
n


o
Since this is true for any θk0 , θk1 , . . . in any sequence θk0 , θk1 , . . .
fies (10), we have f (o) ∈ Ok

that satis-k≥1
for every k ≥ 1, and hence f (o) ∈ OU . Since this is true

for any o ∈ O, we have proved that the range of f lies inside OU .



Lemma 3 If S = (O, g) is finite irreducible, the canonical representation f is a 1-to-1
mapping that satisfies (8).
Proof:Let S = (O, g) be a finite irreducible space of open source licenses.

Define an equivalence relation ∼ on O such that ∀o1 , o2 ∈ O, o1 ∼ o2 iff f (o1 ) = f (o2 ).
Suppose, by way of contradiction, f : O → OU is not 1-to-1, then ∼ will be a51

nontrivial equivalence relation. To arrive at a contradiction, it suffices to provethat ∼ and g are compatible; i.e., it suffices to prove that, whenever o1 ∼ o2 ,(µ ◦ g)(o1 ) = {[x] : x ∈ g(o1 )} =: A1 = A2 := {[x] : x ∈ g(o2 )} = (µ ◦ g)(o2 ).
Since o1 and o2 play symmetric roles, it suffices to prove that, [x] ∈ A1 =⇒ [x] ∈A2 .
Suppose [P] ∈ A1 , then f0 (o1 ) = 1. But then f0 (o2 ) = 1 as well because f (o1 ) =f (o2 ), and hence [P] ∈ A2 as claimed.
Suppose [o0 ] ∈ A1 \ A2 , then there exists o01 ∈ g(o1 ) such that f (o01 ) = f (o0 ), but
for any o02 ∈ g(o2 ), f (o02 ) , f (o0 ). By finiteness of g(o2 ), there exists n ≥ 0 such that
o
 
 
 n  
f0 (o0 ) , . . . , fn (o0 ) < f0 o02 , f1 o02 , . . . , fn o02 : o02 ∈ g (o2 ) ∩ O .
 
  
Since o01 ∈ g(o1 ), we have f0 o01 , . . . , fn o01 ∈ fn+1 (o1 ) by the construction of
the canonical representation f . But then we have    f0 (o0 ) , . . . , fn (o0 ) = f0 o01 , . . . , fn o01∈ fn+1 (o1 )= fn+1 (o2 )on  
  = f0 o02 , f1 o02 , . . . , fn o02 : o02 ∈ g (o2 ) ∩ O ,a contradiction.
It remains to prove that f : O → OU satisfies (8). By the construction of f andgU , we haveP ∈ g(o)⇐⇒f0 (o) = 1⇐⇒

P ∈ gU f (o) = Γ f (o) ∪ {P}.

Suppose o0 ∈ g(o). Then, by the construction of f , ∀n ≥ 0, we have f0 (o0 ) , . . . , fn (o0 ) ∈
fn+1 (o). By the construction of Γ, we have f0 (o0 ) , f1 (o0 ) , . . . ∈ Γ f0 (o), f1 (o), . . . .

52


Therefore, by the construction of gU , we have f (o0 ) ∈ gU f (o) .
Suppose f (o0 ) ∈ gU f (o) . Then, by the construction of gU , we have f (o0 ) ∈Γ f (o) . By the construction of Γ, ∀n ≥ 0, we have f0 (o0 ) , . . . , fn (o0 ) ∈ fn+1 (o). By
finiteness of g(o), there exists o00 ∈ g(o) such that f (o00 ) = f (o0 ). By the fact that f is
a 1-to-1 mapping, we have o0 = o00 ∈ g(o). This completes the proof that f satisfies
(8).



53

Appendix C: Categorizing Imposture-Proof Open Source
LicensesIn this appendix, we shall categorize different imposture-proof open source
licenses. This categorization is independent of our result in Section 6, which deals
with the question of why GPL and BSD stood out from other licenses as the twomost popular choices of open source developers. The categorization, however,may be useful for future research, especially in light of our results in Section 7,
which demonstrate how open source licenses other than GPL and BSD can be
useful if we go beyond our current model setup.
Given any space of open source licenses S = (O, g) that is imposture-proof, andgiven any open source license o ∈ O, let’s recursively define the following:
G0 (o) = g(o)[G1 (o) =..
.
Gn (o) =g(o0 )o0 ∈G0 (o)∩O[g(o0 ).

o0 ∈Gn−1 (o)∩O

Since the space S = (O, g) is imposture-proof, we must haveG0 (o) ⊇ G1 (o) ⊇ G2 (o) ⊇ · · · .
Therefore, there exists a first time (possibly infinity), denoted by L(o), such thatthe option P is no longer available; i.e., P ∈ Gn iff n < L(o). We say that L(o) is the(upper) level of open source license o. Among the open source licenses studied in

54Section 3, we have
L(G) = 0,
L(R) = ∞,andL(1) = 1.
Lemma 4 Let S = (O, g) be an irreducible space of open source licenses that is impostureproof. Any open source license o ∈ O with L(o) = 1 is identical to the 1-chance-only license
1 in the sense that ∃G ∈ O with g(G) = {G} such that g(o) = {P, G}.
Proof:

By definition, L(o) = 1 implies that P ∈ G0 (o) = g(o) but P < G1 (o) =∪o0 ∈g(o)∩O g(o0 ). Therefore, ∀o0 ∈ g(o) ∩ O, P < g (o0 ), and hence by Theorem 1 is
identical to the GPL license in the sense that g(o0 ) = {o0 }. Irreducibility then implies that there is only one such o0 , denoted by G, and that g(o) = {P, G}.

For any L ≥ 1, let’s recursively define the L-chances-only license L as follows.
L: going open source with the L-chances-only license
Developer t goes open source. If developer t + 1 chooses to develop softwaret + 1, he can either go proprietary (i.e., choosing P), or go open source witheither G, 1, 2, . . . , L-2, or L-1.
Theorem 5 Let S = (O, g) be an irreducible space of open source licenses that is
imposture-proof. Any open source license o ∈ O with L(o) = L ≥ 1 is identical to
the L-chances-only license L in the sense that ∃ G, 1, 2 . . . , L − 1 ∈ O, with g(G) = {G},g(1) = {P, G}, g(2) = {P, G, 1}, . . . , and g(L − 1) = {P, G, 1, 2, . . . , L − 2}, such thatg(o) = {P, G, 1, 2, . . . , L − 1}.
Proof:

By Lemma 4, the statement is true for L = 1. Assume we have alreadyproved that the statement is true for L = 1, . . . , m, for some m ≥ 1. Consider anopen source license o ∈ O with L(o) = m + 1. By definition, L(o) = m + 1 implies55

that P ∈ G0 (o), . . . , Gm (o) but P < Gm+1 (o). Therefore, ∀o0 ∈ g(o) ∩ O, L(o0 ) ≤ m, and∃o0 ∈ g(o) such that L(o0 ) = m. Therefore, by the inductive assumption there exist(and, by irreducibility, unique) G, 1, 2 . . . , m ∈ O, with g(G) = {G}, g(1) = {P, G},. . . , and g(m) = {P, G, 1, . . . , m − 1}, such that
G0 (o) ⊆ {P G, 1, . . . , m} = g(m) ∪ {m} ⊆ G1 (o) ∪ {m} ⊆ G0 (o),and hence all inclusions are equality. By induction, the statement is true for any
L ≥ 1.



By imposture-proofness, if L(o) = ∞, then ∃o0 ∈ g(o) ∩ O such that L(o0 ) = ∞,and hence max{L(o0 ) : o0 ∈ g(o) ∩ O} = ∞. Let’s definel(o) = min{L(o0 ) : o0 ∈ g(o) ∩ O}.
We shall call l(o) the lower level of open source license o. Among the open source
licenses studied in Section 3, we havel(G) = 0,l(R) = ∞,andl(1) = 0.
Lemma 5 Let S = (O, g) be an irreducible space of open source licenses that is impostureproof. For any open source license o ∈ O, l(o) is either 0 or ∞.
Proof:

Note that, for any open source license o ∈ O, ∀o0 ∈ g(o), L(o0 ) ≥ l(o),and ∃ o0 ∈ g(o) such that L(o0 ) = l(o). Suppose l(o) = L < ∞. Then, by Theorem 5, ∃ G, 1, 2 . . . , L ∈ O, with g(G) = {G}, g(1) = {P, G}, g(2) = {P, G, 1}, . . . ,and g(L) = {P, G, 1, 2, . . . , L − 1}, such that L ∈ g(o). By imposture-proofness,G ∈ g(L) ⊂ g(o), and hence l(o) ≤ L(G) = 0.

56

Theorem 6 Let S = (O, g) be an irreducible space of open source licenses that is
imposture-proof. Any open source license o ∈ O with L(o) = l(o) = ∞ is identical to
the recursive-BSD license R in the sense that g(o) = {P, o}.
Proof:

Since L(o) = ∞, we have P ∈ g(o). If o0 < g(o) for any o0 , o, thenby the nonemptyness of g(o) ∩ O we must have g(o) = {P, o}, and we are done.
Therefore, let’s suppose there exists o0 , o such that o0 ∈ g(o) ∩ O. Let’s definean equivalence relation ∼ such that [o] = g(o) ∩ O ∪ {o}, and [o00 ] = {o00 } for anyo00 < g(o) ∩ O ∪ {o}. This is a nontrivial equivalence relation because o0 , o andyet o0 ∼ o. We shall prove that g and ∼ are compatible, and hence S = (O, g) is
reducible. To prove compatibility, it suffices to prove that (µ ◦ g) (o0 ) = (µ ◦ g)(o)for any o0 ∈ g(o) ∩ O. Since l(o) = ∞, we have L (o0 ) = ∞, and hence [P] is containedin (µ ◦ g)(o) as well as in (µ ◦ g) (o0 ). By imposture-proofness, we haveg (o0 ) ∩ O ⊆ g(o) ∩ O ⊆ g(o) ∩ O ∪ {o} = [o],and hence (µ ◦ g) (o0 ) = {[P], [o]} = (µ ◦ g)(o) as claimed.



We have, up to this point, characterized licenses G, 1, . . . , L, and R. By Lemma
5, all the remaining imposture-proof open source licenses have the properties ofL(o) = ∞ and l(o) = 0. These include the two BSD licenses studied in Sections 2
and 3, respectively, and many more.28 Common across these licenses are:
1. All allows the next developer to go proprietary; i.e., P ∈ g(o).
2. All allows the next developer to go open source with a license o0 ∈ O that is
restrictive in the sense that L(o0 ) < ∞.
28 Note that the two BSD licenses studied in Sections 2 and 3, respectively, are not exactly thesame—while both have the flavor of “everything goes”, the meaning of “everything” differs acrossthe two spaces of open source licenses studied in those two respective sections—and hence should
more appropriately be regarded as different variants of BSD.

57

3. All allows the next developer to go open source with a license o0 ∈ O that ispermissive in the sense that L(o0 ) = ∞.
Further categorization of these licenses will be left for future research.

58