Choosing an Open Source License
Ian
Lance
Taylor
http://www.airs.com/ian/
ian@airs.com
2005
Ian Lance Taylor
This document is licensed under a Creative
Commons License.
$Date: 2005/08/23 06:55:26 $
Microsoft
You are not buying the program itself, and you do not actually
own it. Instead, you buy a software license.
Last changed on $Date: 2005/08/23 06:55:26 $.
People who are new to the idea of open source software
Closely related to the idea of open source software is the idea of
free software. The distinction is whether the emphasis is commercial
use (open source software) or the rights of end users (free software).
Since this essay is aimed at software authors new to the open
source/free software world, I've decided to use the term open source
throughout the essay.
, but who want to try it out, are often uncertain what license they
should use for their software. This essay is intended to describe the
issues and to guide you in making your choice. The essay is presented
as a series of questions; answering those questions should help you
understand which license is right for you.
Do You Want an Open Source License At All?
Open source software is software which is distributed under a license
which follows the Open Source
Definition. There are various rules which open source
licenses must follow, but the basic rule is this: anybody who receives
the software is permitted to modify it, and to redistribute the
modified version to whomever they please.
Open source software is thus the opposite of proprietary software.
When you release software under an open source license, you no longer
have any control over who get to use it or how it is used. For one
obvious example, this means that it is difficult to make money by
directly selling copies of open source software, because any of your
customers is free to give their copy to anybody in the world. Because
recipients are permitted to change the software, it is impossible to
impose any controls over how the software is used.
A particularly interesting freedom which recipients of open source
software have is the right to fork. A fork is an new line of
development, independent of your own efforts. Forks are not
especially common, but they do happen, and for the original author
they are a complete loss of control over the software.
If your goals include maintaining any sort of control over who uses
the software, or gathering any sort of fees for sale or license of the
software, or even simply keeping track of who has the software, then
an open source license is not for you.
What Licenses Are You Using Now?
Many software program have components from various other
organizations. When considering what license you should use for your
own program, don't forget to consider the licenses used by any
components. These existing licenses may well constrain your licensing
choices. If your software is going to be linked with other software,
and the resulting program is going to be distributed, then you must
choose a license which is compatible with the existing software.
It's difficult to say anything more specific here. Remember that in
some cases it may be possible to release a limited version of your
software without some of the components whose licenses prohibit
redistribution.
Do You Want Outside Contributors?
One common reason for releasing software under an open source license
is to obtain outside contributors—people from outside your
organization who help improve the software. Unfortunately, this often
does not happen to any significant degree. There are many open source
packages out there, and there is far more work to do than there is
people to do the work. Simply getting people to know that your
software exists is not a simple task.
In general, in order to get outside contributors, your software must
work well enough out of the box to do something interesting. Most
contributions will be in the form of tweaks or minor additional
functionality. You will have to manage any contributions you receive,
and encourage contributors to keep working with the software.
You will also have to provide a license that is readily understood.
Most potential contributors faced by an unfamiliar license will simply
move on to another project. Therefore, if you want to encourage
contributors, you should pick a well-known license from the following
list (these licenses will be discussed further below):
GNU
General Public License (GPL)
BSD
License
Mozilla
Public License (MPL)
There are also two more recent open source licenses which are becoming
more popular and are worth mentioning here:
Academic
Free License (AFL)
Open
Software License (OSL)
If you are not interested in outside contributions, then the choice of
license is less important. The Open Source Initiative maintains a
list of open
source licenses. If the popular licenses listed above are not
suitable for some reason, you can consider picking a different license
from their list. In general, though, you should stick to a popular
license if at all possible.
Do You Want to Permit Proprietary Forks?
There are two main differences among open source licenses. Some
permit proprietary forks, and some prohibit them. A proprietary fork
is a development fork in which the newly developed code is kept
proprietary by the new developer. That is, the new developer
distributes the code under a non-open-source license. Licenses which
prohibit proprietary forks are sometimes called copyleft licenses.
For example, let's say you distribute Widget Sorter 1.0 under an open
source license which permits proprietary forks. Then somebody else
can take the program, enhance it to permit painting widgets, and start
selling Widget Sorter/Painter 2.0 under a very restrictive license.
They don't have to release their changes to anybody, including you.
On the other hand, if you release Widget Sorter 1.0 under an open
source license which prohibits proprietary forks, that becomes
impossible. People who receive your program can do whatever they want
with it except modify it and sell the result
under a proprietary license.
There are good reasons to make either choice, and there is a great
deal of open source software released under both sorts of licenses.
If your primary goal is to have the software be very widely used, then
you should permit proprietary forks. If your primary goal is to make
sure that your end users will always be able to modify the software to
suit their needs, then you should prohibit proprietary forks.
Of the popular licenses listed above, proprietary forks are permitted
by the BSD and AFL licenses. Proprietary forks are prohibited by the
GPL, MPL, and OSL licenses.
Comments on Licenses
At this point you should have narrowed your choice down to a couple of
licenses. You should read those closely, and see which ones suits
your needs best. In this section I will make a few comments on each
of the popular licenses I listed above.
The GPL is one of the two most widely used open source licenses. It
is fairly readable, and is generally well understood by open source
programmers. It prohibits proprietary forks. Linking together GPL
code with code under other licenses generally forces any distribution
of the combined program to be covered by the GPL. While open source
licenses by definition are not very restrictive, the GPL is among the
most restrictive of open source licenses. The GPL is used for, among
other things, the Linux kernel
and most software released by the GNU
project.
The BSD license is the other of the two most widely used open source
licenses. It permits proprietary forks, and indeed imposes almost no
restrictions on how the code is used. The license is very easy for
anybody to read and to understand. The BSD license is used for, among
other things, the BSD family of operating systems such as NetBSD.
The MPL is in some ways a less restrictive version of the GPL. Like
the GPL, the MPL prohibits proprietary forks. Unlike the GPL, if code
under the MPL is linked together with other code, the MPL applies only
to that portion of the combined program which was originally under the
MPL. The MPL is used for Mozilla and related products. Using
the MPL for your own software may require modifying it slightly, as
the MPL includes specific references to Netscape Communications
Corporation. If the MPL seems right for you, you should also take a
look at the Common Development and
Distribution License (CDDL).
The AFL is a new license which is intended to be similar to the BSD
license. It is intended to be legally stronger (this is not a topic
which I am qualified to judge). The main difference from the BSD
license is a clause terminating the license for somebody who files a
patent lawsuit.
The OSL is intended to be similar to the GPL, but legally stronger.
The main difference is that while the GPL only restricts
redistribution of the software—any redistribution must include
the source code—the OSL also restricts use of the software
outside your organization—e.g., making the software available
for use over the Internet requires making the source code available.
Conclusion
An open source license is appropriate for a wide range of software
projects. Many people instinctively try to keep too much control over
their software, and thus limit its use. It's often better to release
control over the software, permitting it to be used much more widely.
This is true even if you hope to make money from the software—
releasing the software as open source will generally give you a
somewhat smaller percentage of a much larger pool, and thus generally
more money over all.
In this essay I've tried to describe the most important topics to
consider when choosing which open source license to use. I hope that
it helps.