The Scope of Open Source Licensing




старонка2/8
Дата канвертавання25.04.2016
Памер415.4 Kb.
1   2   3   4   5   6   7   8

A. Some Tradeoffs


Suppose that an individual or organization, whom we will term the “licensor,” wants to start an open source project. The licensor may be a single developer, a group of developers with similar needs, or a corporation. As a first step, some initial code is written or gathered, and then released under some license. The choice of this license may be one of the key decisions of the overall design. The license—along with the quality of the released code, the licensor’s reputation, and the demand for the product—will influence whether the project will appeal to programmers.
To be certain, the choice of a license may be affected by considerations that either lie outside standard utility-maximizing paradigms, or may be distorted by a misunderstanding of the implications of the alternative licenses in the choice set. Examples of the latter are hard to document in view of the short history of the open source movement, and any guess as to the current existence of such mistaken impressions is necessarily subject to debate. An example of the former is the influence of ideological views: to cite one example, the belief that “software should be free” is sometimes invoked in favor of the GPL license.13 Our primary interest, though, lies in assessing the extent to which the initial choice of license is a rational choice.
It goes without saying that a license choice that is privately optimal from the point of view of the licensor may not be socially optimal. The choice of a license impacts:

  • The community of programmers who are asked to work on their project, as its benefits from working on the project may depend on the choice of license.14

  • The end users, who may for example care about possible incompatibilities among versions or about the number of available applications. The choice of license, by affecting the likelihood of forking or the incentives of application developers, therefore impacts their welfare.

  • The other open source projects that later will compete with or complement the project. For example, a GPL program may prove of no use for another open source project licensed under a BSD license that could otherwise have made use of the program.

  • Commercial software vendors and support providers, whose opportunities are affected by the license.

When selecting a license, the licensor assesses the various benefits that the open source project will bring her. These include:



  • The intrinsic motivation that the intellectual challenge provides.

  • The signalling benefits (which encompass ego gratification and “career concerns” incentives such as future job offers and access to venture capital).

  • The need to solve concrete problems for one's employer.

  • The possibility of material benefits.

For individuals, the latter includes the possible option of later building a commercial operation around the open source code. This material incentive is distinct from the career concerns incentives mentioned above. It depends crucially on the commercial reward being associated with an addition to the initial open source project. By way of contrast, many of the signalling benefits arise even if the subsequent work of the programmer is unrelated to the open source project. For corporations, material benefits include the increased profit on services or software that complements the open source software and the emancipation from the mark-ups and conditions imposed by a dominant software vendor with whom the open source project is meant to compete.


This mixture of motivations implies that the licensors have a wide variety of goals. For example, material benefits are paramount when licensors are corporations. Such benefits provide a smaller, but in a number of cases non-negligible, motivation in the case of individual licensors. The licensor must assess how her mixture of motivations, together with project characteristics—such as the environment, the size of the initial code base, and the intended audience—impacts the following general considerations:

1) Interaction of project with other software.


As mentioned above, the open source project under consideration may not succeed on a stand-alone basis; rather, it may need complementary products in the open source and/or commercial worlds. The choice of license affects the ease with which the different pieces of software can be combined: a point frequently mentioned by advocates of the BSD license, who argue that the GPL and related licenses discourage potential commercial users.
A case in point is the choice of license by programmers trying to get software established as a standard. Although they involve risks of hijacking (see below), unrestrictive licenses make more sense than restrictive ones in such a context. This conjecture leads us to anticipate that projects geared toward the Internet, where standard setting has been particularly important in recent years due to the immaturity of key technologies, might be less likely to have highly restrictive licenses.
Interestingly, the licensing choices may also give rise to “dynamic strategic complementarities” or “dynamic network externalities” among open source licensors. If existing projects in a field have restrictive licenses, the licensor is more likely to choose a restrictive license in the anticipation of future user benefits from combining the end results. Conversely, a project with a restrictive license may not flourish in an environment dominated by BSD-licensed projects. The “greenfield” considerations discussed shortly thus need to be augmented by an analysis of “legacy aspects.”15

2) Hijacking.


Advocates of restrictive licenses argue that unrestrictive ones are particularly prone to “hijacking” by commercial software vendors: in other words, the commercial firm may add some proprietary code to the open source software and take the whole private. While the resulting software may (or may not) be superior, the firm disrupts the dynamics of the open source project by de facto privatizing it. (The original project will not be privatized, but there is a risk that the proprietary derivative work will confuse, and perhaps dominate, the market.) While such hijacking need not be socially detrimental—it may take the project to its next logical step or revive interest in an otherwise faltering technology—the action deprives the open source contributors of some of the benefits from the project. (For example, they may have to pay for the final software and be unable to tailor it for their own needs. One reason for this fear is that contributors to open source projects enjoy dynamic network effects—see our 2002 paper—and that these network effects may be reduced by competition from a proprietary variant.) This prospect may discourage potential contributors in the first place.
This argument for restrictive licenses could be rephrased as saying that community members make project-specific investments. Hijacking poses the possibility that the members may be “held up”: for instance, they may lose the ability to shape the project to meet their particular needs and their contributions become less visible because the open source community loses interest in the project. Several covenants in the restrictive licenses (including that about patent licensing discussed below) can be seen as a Williamsonian [1975, 1985] contractual response to address the danger of such “hold up” problem.
To be certain, restrictive licenses are not immune to a problem akin to hijacking themselves. After all, commercial software vendors can rewrite the open source code. (Copyright protection of software—unlike patent protection—only protects the expression, not the fundamental ideas.)
In the end, the risk of hijacking under alternative licenses depends on the nature of the project. Open source projects that are conservative reimplementations of pre-existing software are probably less subject to hijacking than innovative software products.16 Another potential determinant is the size of the code. Large projects are more costly to rewrite, and so costs and delay factors may make the choice of license more relevant in this case.
3) Impact of software patents.

Open source software proponents have often expressed concerns that patent infringement suits may hamper the projects. It is easy to imagine circumstances under which software patents might affect the dynamics of the process. Contributors to the software, as well as users and distributors of the code, may be deterred, especially corporations. The GPL specifies that if some contribution is found to be infringing on a patent and the ability to distribute the code (or modification of the code) is thereby restricted, then the code cannot be distributed at all. This covenant is meant to prevent “joint hijacking” by the patent owner and an open source infringer who would then receive an exclusive license from the patent owner.  Historically, these provisions have not been included in any of the non-GPL contracts. 


4) Impact on incentives to produce complementary software.

A standard argument in favor of unrestrictive licenses is that permissiveness is what it takes to attract commercial software developers to write applications that enhance the value of the open source code. In particular, it has been suggested that in mature projects, when the energy of the initial contributors may be fading, the involvement of commercial contributors may be critical to success (Bezroukov [2002]). (We will discuss license choices in cases where firms open up proprietary software below.)


5) Familiarity of open source community with the license.

There are benefits in the form of reduced transaction cost to the licensor who adopts a familiar license rather than an innovative but unfamiliar one. Licensors choosing a well-known license economize on the learning costs incurred by the community as to how the license works and what its likely implications for the development process are.


6) Forking.

Forking refers to an internal threat of competing groups moving in different directions and producing incompatible versions of the same initial open source project. It is unclear to us how license type will affect the probability of forking or the effectiveness of the original project leader’s response; this topic may reward future research.



1   2   3   4   5   6   7   8


База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка