Open Source Licenses: An Overview
Like intellectual property software, open source software’s development and future is dependent upon its licensing structure. Contrary to popular belief, most open source software does not give users complete freedom to do with it as they please. License terms govern the use and redistribution of open source products, and a variety of open source licenses exist. In practice, many of these licensing terms significantly restrict how the user may redistribute the source code. Some open source licenses are well-suited for the purposes of certain developers or certain projects, while others – particularly viral licenses – involve restrictions that developers, users, and governments should recognize and understand.
Summary of Prominent Open Source Licenses
GNU General Public License. The GPL permits the free use, modification and redistribution of open source software and its source code. However, it contains three key restrictions: (1) redistribution of software is permitted, but source code availability must be guaranteed; (2) the source code is licensed "as is," with no warranties regarding product performance or non-infringement of third party intellectual property (“IP”) rights; and (3) GPL-licensed software may be modified without restrictions as long as the derivative works are also governed by the GPL. Linux is distributed under the GPL.
Berkeley Software Distribution License. The BSD license places fewer restrictions on software developers than that GPL license. The BSD license was originally applied to software programs distributed by the Computer Science Research Group at the University of California, Berkeley. The BSD license allows programmers to use, modify, and redistribute the source code and binary code of the original software program, with or without modification. Moreover, the use, modification, and redistribution of BSD-licensed code are not necessarily subject to the BSD license. Thus, derivative works can be either open source or subject to IP protection. Apache, a web server package, is distributed under a variant of the BSD license.
GNU Lesser General Public License. The LGPL is a modified version of the GPL license. The LGPL recognizes that many software developers will not use GPL-licensed source code because of its requirement that all derivative works be licensed under the GPL. The LGPL allows software programs to call upon programs governed by the LGPL without running the risk of subjecting their software to the terms of the GPL (with certain exceptions). The LGPL was originally designed for the integration of libraries so that the GNU operating system libraries were not restricted to open source software only. The drafters of the original GPL recognized that permitting commercial programs to use libraries would widen their distribution and market share.
Mozilla Public License. In 1998, Netscape released the source code of its Navigator web browser under a variant of the MozPL. The MozPL allows for the free distribution of source code and permits software developers to modify the source code without first seeking permission from the software owner. The MozPL has features of both the GPL and the BSD license. Like the GPL, all redistributions and modifications of the MozPL source code are subject to the MozPL license terms. However, if MozPL source code is combined with non-MozPL source code to create a larger derivative work, the non-MozPL source code is not subject to the MozPL.
wo principle types of open source licenses exist.
Open source licenses fall into two camps: viral and non-viral. Non-viral licenses permit software developers to integrate the licensed software and its source code into new products without restriction. A prominent example of this type of license is the Berkeley Software Distribution (BSD) License. The BSD license allows programmers to use, modify and redistribute the source code and binary code of the original software program, with or without modification. Moreover, programs containing code subject to the BSD license do not themselves have to be distributed under that license. Thus, derivative works can be either open source or subject to intellectual property protection. This type of license gives users freedom to incorporate their own changes and redistribute them, without requiring them to give the new code away.
By contrast, viral open source licenses require all derivative works be licensed on the same terms as the original program. These licenses are described as viral because they “infect” derivative programs. Viral licenses vary widely in how infectious they are, depending on how they define which programs are derivative works. However, the dominant open source license – the General Public License (GPL) – is one of the most infectious. It subjects any work that includes GPL-licensed code to the GPL. Thus, if a government or business uses even a line of GPL-licensed code in a program, and then re-distributes that program to others, it must provide the program under the GPL. And, under the GPL, the recipient must be given access to the source code and the complete freedom to redistribute the program and any modifications to it.
Viral open source licenses inhibit innovation.
Viral open source licenses can reduce incentives to create new programs. Commercial software firms spend millions of dollars each year on research and development. To make this expenditure worthwhile, these firm must have the ability to recoup these costs and make a profit. Releasing innovative, new programs under the GPL deprives these firms of the economic value of their investment by making their intellectual property freely available to competitors and severely restricting their ability to charge for their products. For these reasons, the GPL can operate as a disincentive to innovation.
Indeed, the GPL itself reflects a view of the world that all software should be freely available. The creator of the GPL, Richard Stallman, has written eloquently on this “commons” concept of software. As he notes, the GPL license does ensure that everyone has access to the source code of a particular program, spreading knowledge about solutions to difficult problems. But such a view, while romantic, is not practical. In order to have incentives to innovate, both individuals and businesses need to have a means of obtaining a return on their investment.
Indeed, the impracticality of the GPL is widely recognized. Even staunch free software advocates such as Stallman have promoted the use of the Lesser GPL in certain cases, in order to obtain market share for open source libraries. And when Netscape released its browser as an open source product, it created the Mozilla Public License (MozPL), which differentiates between modifications to existing code (which must be licensed on an open source basis) and additions to the code (which are not necessarily subject to the MozPL). As Netscape recognized, individuals and companies will have an incentive to add to the browser only if they are not required to immediately provide everyone the fruits of their labours free of charge. And other companies, such as Sun Microsystems, have released source code, but kept tight control over distribution of changes, in order to prevent forking and ensure that the quality of the code is maintained.
Government-funded research should not be licensed using the GPL.
Government research, funded by taxpayer dollars, helps create and spread knowledge. Where such research involves software code, it should not be licensed using the GPL. If the code is subject to the GPL, then commercial software companies, which are significant direct and indirect contributors to the tax base, cannot take advantage of the research without placing their own IP in jeopardy. And while government-funded research should be available to everyone, there is no reason to require further innovations by individuals or companies to be publicly disclosed. The proper license for government-funded research is the BSD license. This makes the source code publicly available, and gives users the freedom to alter and redistribute the program as they wish.
* * *
Microsoft appreciates this opportunity to share our views and would welcome further opportunities to discuss these issues. Questions concerning these comments may be addressed to Julie Inman.