The Scope of Open Source Licensing




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

Table 9: Regression analysis of characteristics of projects with and without highly restrictive license provisions, comparing early and late projects. The sample consists of 38,610 projects included in the SourceForge database in May 2002. The dependent variable is a dummy denoting whether all the licenses under which the project is licensed have highly restrictive provisions. The independent variables include dummy variables capturing various features of the open source projects. The first regression is restricted to those projects added to the SourceForge database before 2000; the second regression to those added in 2002. All regressions employ probit specifications.





Dependent Variable: All Licenses Highly Restrictive?




Early Projects Only

Late Projects Only




Coefficient

Standard Error

Coefficient

Standard Error

Development Stage













Pre-Alpha

-0.05

0.12

-0.12

*0.07

Alpha

-0.12

0.11

-0.09

0.07

Beta

-0.09

0.09

-0.001

0.07

Production/Stable

-0.09

0.10

-0.18

**0.07

Mature

-0.05

0.20

-0.40

0.24

Environment













X11

0.04

0.11

0.09

0.08

MS Windows

-0.20

0.13

-0.01

0.09

Other

-0.38

***0.11

-0.37

***0.07

Internet

0.08

0.11

0.002

0.07

No Input/Output

-0.28

**0.12

-0.29

***0.09

Cocoa (MacOS)

0.64

0.54

-0.12

0.16

Handhelds/PDAs







-0.14

0.21

Intended Audience













End Users/Desktop

0.44

***0.09

0.36

***0.06

Developers

-0.40

***0.09

-0.16

***0.06

System Administrators

0.05

0.10

0.14

**0.07

Natural Language













French

0.18

0.15

0.14

0.11

Spanish

0.43

*0.26

0.22

0.15

Japanese

-0.33

0.38

-0.57

**0.24

German

0.17

0.15

0.15

*0.08

Russian

0.30

0.46

0.14

0.18

Operating System













POSIX

0.11

0.12

0.22

***0.07

Microsoft

-0.33

***0.11

-0.10

0.08

OS/2







0.38

0.65

MacOS

-0.27

0.19

-0.19

0.13

BeOS

-0.32

0.28

-0.62

**0.30

OS Independent

-0.27

**0.11

-0.15

*0.07

PDA Systems







0.25

0.29

Topic













Communications

0.13

0.11

-0.03

0.07

Security

-0.17

0.21

-0.10

0.13

Software Dvlpmt.

-0.44

***0.11

-0.38

***0.07

Desktop Environ.

0.05

0.17

-0.13

0.14

Text Editors

0.34

0.25

-0.20

0.13

Database

-0.16

0.15

-0.02

0.10

Education

0.23

0.24

-0.41

***0.13

Internet

-0.09

0.11

-0.07

0.07

Scientific/Enging.

-0.13

0.14

-0.08

0.10

Multimedia

-0.15

0.11

-0.29

***0.09

Office/Business

0.36

*0.20

-0.13

0.11

System Tasks

-0.03

0.11

0.09

0.07

Printing

-0.18

0.49

-0.37

0.38

Terminals

-0.53

0.47

0.40

0.32

Games, et al.

0.20

*0.12

0.23

***0.08

Constant

0.89

***0.16

0.64

***0.10

χ2-statistic

278.36




362.18




p-Value

0.000




0.000




Log Likelihood

-770.02




-1,761.45




Number of Observations

1,478




3,238





Definitions:

* = Significant at the 10% confidence level.

** = Significant at the 5% confidence level.

*** = Significant at the 1% confidence level.


In each regression, the following variables are omitted: the dummy variables denoting projects in the planning stage, those operating in a Console (Text) environment, those geared towards other audiences, those whose natural language is English, those geared toward an other operating system, and those with an other topic. Certain additional variables were dropped from the first regression due to collinearity.

Table 10: License type of projects that are corporate spin-offs. The sample consists of 38,610 projects included in the SourceForge database in May 2002. The dependent variables are the six used in Tables 6 though 8, including dummy variables denoting whether the licenses had highly restrictive or restrictive provisions, as well as the two indexes of license type. The corresponding regression is denoted in brackets. In each case, the table reports the coefficient and standard error of a measure denoting whether the project was a corporate spinout. Controls for the development stage, environment, intended audience, natural language, operating system and topic are also employed, but not reported.


Dummy Denoting Corporate Spin-Off Projects

Regression

Coefficient

Standard Error

All Highly Restrictive [6.1]

0.07

0.29

Some Highly Restrictive [6.2]

0.38

0.31

All Restrictive [7.1]

0.32

0.34

Some Restrictive [7.2]

0.46

0.37

Five-Part Index [8.1]

0.31

0.44

Three-Part Index [8.2]

0.20

0.44




*Harvard University and NBER; University of Toulouse and MIT. We thank Larry Augustin, Jeff Bates, and Pat McGovern for access to the SourceForge database. Comments by Yochai Benkler, Keith Bostic, Peter Childers, Jacques Crémer, David Genesove, Brian Kahin, Marten Miklos, Siobhan O'Mahony, Bruce Perens, Bernie Reddy, Larry Rosen, Marcin Strojwas, and participants in the conference “Open Source Software: Economics, Law and Policy” at the University of Toulouse and in a seminar at Harvard Law School were very helpful. We thank James Hunter, Nicolas Lambert, Bernie Reddy, and Brendan Reddy for their many contributions to the research project. Harvard Business School’s Division of Research provided financial assistance. The Institut D'Economie Industrielle receives research grants from a number of corporate sponsors, including French Telecom and the Microsoft Corporation. All errors are our own.

1Gallini and Wright [1990] and Katz and Shapiro [1986] are illustrative of this literature. Also relevant are those works that explore the real consequences of the licensing decision, whether the impact of this choice on subsequent innovations by the original innovator (Gandall and Rockett [1995]), the decision of rivals to enter the market (Gallini [1984]; Rockett [1990]), or the nature of the competitive dynamics in the industry (Shepard [1987]).

2Of course, the fact that timing, royalty rates, and exclusivity are not important in this setting means that our ability to draw lessons for the commercial world may be limited.

3One decision that touched on, but did not resolve, these questions was Progress Software Corp. v. MySQL AB, 195 F.Supp.2d 328 (D. Mass 2002).

4Subsequently, software was also made available under formal contracts between developers and users. Later (in the personal computer era), software was protected through via mass market “shrink-wrap” licenses.


5In some instances, firms had solicited contributions from third parties, and then sought to enforce intellectual property rights on software that resulted. In other cases, individuals added a modest amount of new code to software that was distributed without restrictions, which they then sold as a copyrighted proprietary product.


6GNU was the name of the project to develop a new operating system that Stallman had launched. The license was later renamed the General Public License. For a detailed history, see http://www.free-soft.org/gpl_history/ (accessed September 17, 2002).


7BSD stands for Berkeley Software Distribution. The credit provision was dropped in later versions of the license.

8For detailed analyses of the Open Source Definition, see Lee [1999] and Perens [1999].



9In some cases, those who redistribute the original code must make it freely available, but modifications need not be (e.g., the Artistic License). These cases are coded as not being restrictive.


10The extent to which these licenses can be enforced remains untested in a court of law. These issues are discussed, for instance, in Dodd and Martin [2000] and McGowan [2001].


11The alteration of open source licenses by project leaders poses several interesting issues. Open source licenses differ somewhat from traditional licenses, such as the "shrink-wrap" agreements that govern the relationship between manufacturers and users of commercial software product, which require the consent of both parties to be effective.  Rather, an open source license is best seen as a conditioned permission to use one's property, akin to a landowner who allows hikers to use a path that passes through his property.  The project leaders can unilaterally change such permissions, just as the landowner could fence his property without consulting the hikers (or conversely, add to the network of trails).  Thus, the leaders of a BSD-license project would be free to switch to a GPL license, and vice versa. Two complications, however, should be noted.  First, it is unlikely that open source project leaders can force existing licensees to honor alterations to the terms of licenses.  Thus, if a program had been made available under a BSD license and a firm has incorporated into the code into a commercial product, the project leaders in all probability cannot subsequently force the firm to make the product available under the GPL.  A second complication is introduced by projects where contributors do not assign the copyright for their holdings to a central entity (as the Free Software Foundation and many other sponsors of open source projects require).  In these cases, such as the Linux kernel development project, the copyright is in the hands of literally thousands of individual contributors.  Any change to the license would probably requite the assent of each copyright holder: any holdout could block the shift, unless his software contribution could be rewritten.


12See, for instance, http://kt.zork.net/wine/wn20020308_117.html (accessed September 17, 2002).

13This belief could conceivably be rationalized through its adherents’ confidence that future versions of the software will remain communal property. For some adherents, though, this belief is simply a matter of principle.


14As we will later emphasize, the externality cannot be too large since the licensor must secure the participation of the community, but this does not imply that the preferences of the licensor and the community are perfectly aligned.

15An additional complication is introduced by the asymmetry of the licenses, especially the greater restrictions in the GPL license.  If a BSD-licensed project wanted to make substantial use of a program (or portion of a program) covered by the GPL, the project leaders would need to obtain permission from the copyright owner (for instance, the Free Software Foundation).  Were the leaders of the BSD-licensed program to incorporate the GPL code without permission, their BSD product would effectively be converted into a GPL product.   Thus, they will be reluctant to add such features.  GPL-licensed projects, on the other hand, can incorporate elements of (or work alongside) either GPL or BSD programs without subverting their license.  Thus, in settings where existing projects have restrictive licenses, founders of new projects may want to also have restrictive licenses in order to ease collaborations.  The pressures to choose a particular type of license may be less intense if existing projects have unrestrictive licenses.  More generally, the GPL can be seen as serving as an “absorbing state” in a way that the BSD license does not.


16Bezroukov [2002] puts Linux in the former category, and scripting languages (TCL, Perl, Python, PHP) in the latter.


17The member could alternatively work on other projects (commercial or open source).

18The logic behind this reasoning may be less compelling in the case where a corporation makes available proprietary software that it is already developed under an open source license. We discuss this special case below.

19In the analysis below, we will equate certain licenses (denoted in Table 1) with the restrictive licenses discussed here. This need not be the case for our analysis to hold: these licenses need only be perceived as more restrictive. The latter assumption seems abundantly justified (e.g., Bezroukov [2002], Dodd and Martin [2000], Lee [1999]).

20MySQL AB follows the latter strategy with its MySQL database. The firm simultaneously sells its software and makes it available for free under the GPL. Many large corporations prefer to purchase their product, both because of liability concerns (the GPL product is made available on an “as is” basis, while purchasers of the commercial product are fully indemnified) and worries about the GPL.


21The case of Netscape’s Mozilla project, whose initial license was greeted with protests and was replaced by a more restrictive license, is one illustration (Hammerly, et al. [1999]).


22There are, however, exceptions. These include, for instance, projects that involve encryption software that is banned under U.S. law. For a fuller discussion, see http://sourceforge.net/docman/display_doc.php?docid=756&group_id=1 (accessed September 17, 2002).


23http://savannah.gnu.org (accessed September 17, 2002).


24Other concerns that might be raised about the performance measures are not borne out. Because of the extent of the coordination costs, even projects with multiple sites tend to have all (or virtually all) the contributions focused on a single one of those sites. Switching projects from SourceForge to another site appears very rare, in large part due to the “lock-in effects” that SourceForge enjoys. See, for instance, the discussion in http://www.advogato.org/article/376.html (accessed September 17, 2002).


25These tabulations are not weighted (i.e., each project is counted equally). We do not have the count of the number of lines of code in the project, which might be a natural weighting. We do have, however, the total number of problems (“bugs”) reported to the SourceForge depository. While this measure is not as satisfactory (some projects operate code depositories that are not part of the SourceForge site, and thus appear to have little activity but are actually quite vital), it may nonetheless be a reasonable proxy. The results of the weighted analysis suggests that the GPL license is not as dominant: 63% of the weighted projects have GPL licenses, 11% have Lesser GPL licenses, and 11% BSD licenses.

1   2   3   4   5   6   7   8


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

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