Choosing an Open Source License

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.