Open source is a commons-based activity in which a community of people work on a shared artifact, in this case source code. Source code is covered by copyright law, which in the United States grants copyright to an author immediately upon completion of the piece. When copyright law in the United States was first written, the duration of protection was 14 years with perhaps an opportunity to renew it once. Now copyright extends until the death of the author plus 70 years.
Software enjoys the same protections as any other literary work. In addition, software may contain the implementations of patented methods--called software patents. Currently, the copyright holder retains the right to strict control of the work, including copying, derived works, distributions, and public performance. Originally, copyright law tried to strike a balance between providing an incentive for creators and allowing other creators to build on works already created. The expansion of copyright protection has been rapid over the last 40 years as institutional "content" creators lobbied for expanded protection.
A key to understanding open source as a business strategy is coming to terms with the idea that there is a middle ground between "all rights reserved" and the public domain. It is possible for a holder of intellectual property to carefully craft a description of rights the holder wishes to retain and freedoms the holder grants to licensees. Think in terms of "some rights reserved" or "most rights reserved." Even when source code is visible and even downloadable on the Internet, the copyright and patent holders retain ownership of the material and, by licensing arrangements, control what they wish to control. In fact, copyright and patents are in place precisely to encourage people to create, invent, and put on display their creations and explain their inventions.
A good, clear example of this is the VTK project. The project provides a simple license as part of the copyright notice--and in fact, the term copyright is used the way most open-source projects use the term license , and some open-source licenses, such as BSD (discussed later), likewise state their license terms as part of the copyright notice. The VTK directory structure isolates files and classes that contain patented algorithms (they are in special subdirectories), and the license states that any commercial use of those parts requires licenses from the patent holders--and it provides contact information for them. The commercial use could be as part of VTK or as part of other systems. However, individuals, universities, and companies can use the code without special terms as long as there is no commercial benefit derived, and the nonpatented parts can be used commercially without special licenses.
This represents an example of how the rights to intellectual property have been carved up by one group. Other groups might limit the use of patents to software developed as part of the open-source project, while uses of those patents in other, unrelated software would be restricted or prohibited.
Naturally, crafting a too restrictive set of rights granted to others can stifle the success of an open-source project, but there is no need to abandon all property rights. For open source to work, the author or copyright holder basically needs to grant rights to use, modify, and distribute. This is accomplished through licensing, which, although granting rights to others, does not transfer ownership in any way, so that the owner of the source code can change how the source is licensed in the future, can decide not to license it, or can transfer ownership.
A variety of licenses have been created to meet the different needs of open-source projects--the original Berkeley Unix was released under the Berkeley Software Distribution (BSD) license, Linux and Emacs use the GNU General Public License (GPL), and Netscape created the Mozilla Public License (MPL) for its browser. Companies such as IBM and Sun have written a variety of licenses including the Common Public License (CPL), Sun Industry Standards Source License (SISSL), and Sun Community Source License (SCSL). Over 50 different licenses have been certified as meeting the criteria for open source by the Open Source Initiative, a nonprofit corporation dedicated to managing and promoting the Open Source Definition,1 and additional types of licenses have been created for use by other open-source projects.
This large number of possible licenses creates confusion for people considering starting in an open-source project. When choosing a license for your project, it is best to use one of the existing licenses--preferably one already in widespread use--rather than trying to create a new one.
Creating a new license is a difficult legal process. It is likely that an existing license captures most, if not all, the concerns you might have, and the open-source community has little patience for people and organizations who don't believe in the already working, existing licenses. Moreover, a new license would perhaps need to be certified by the Open Source Initiative to satisfy the business objectives of its creator. Existing licenses--especially those in widespread use--are like brands in that people already are familiar with their terms and how to work with software licensed under them. By choosing a well-known, accepted license, you are also choosing a reduced learning and adoption curve for your community members.
In this chapter we discuss what goes into a typical license and describe some of the most commonly used ones, including which type of projects they are best for. Which license is best for your project depends on your reasons for choosing to do open-source development. Chapter 7 includes a section on Choosing a License that presents a list of questions to help you pick which license to use.
Many people equate open source with the various open-source licenses, but the license is only a gate that people pass through. If people are not willing to agree to the terms of the license, then they don't pass through the gate. For those people who do accept, the license doesn't specify how they will work together; it merely defines some very basic ground rules.