Choosing an open source or free software license is more often the result of circumstances than the unfettered discretion of a particular programmer. While each of the licenses described in this book (which represent only a selection of the open source and free software licenses in use) presents its own advantages and disadvantages, in many situations, the decision as to which license to apply will already have been made.
A typical route to involvement in an open source or free software project comes from contributing to an already existing project. Whether by submitting a patch to Linux or a bug report to a less well-established open development project, consideration of the license applicable to the project is generally a secondary consideration at most. A user submitting a bug report does not generally care about the license of the program to which the bug report applies. So long as that user can reasonably expect some benefit from the submission of the bug report, usually in the form of an improved program, that user will make a submission.
Users frequently make even more substantial contributions to open development projects without much more consideration. Again using Linux as an example, scores of programmers have submitted and continued to submit patches or more substantial contributions to Linux without troubling themselves to any great extent about the terms of the GPL applicable to Linux.
A programmer may undertake even more substantial responsibilities for an open development project by helping to maintain it or even taking a leadership role, without choosing the license applicable to the development. In the world of open source and free software, projects are frequently handed down, and the "successor" lead programmer takes over a project from the project's initiator. In such situations, the project comes with the license under which it was originally written. While a successor project leader could in theory insist that a new license apply to the project, the administrative and legal difficulties would have to weigh against such a switch. Even if the original project leader were agreeable, the new project leader would most likely need to secure the consent of every programmer who had contributed to the project under the previous license. After all, they had made their contributions with the understanding (to the extent that they had one) that what they contributed would be licensed under the license originally applicable to the project. Depending on the number of contributors, this could be a considerable hurdle.
Even for "new" open source or free software projects, the choice of a license may substantially be determined by license choices made by others. After all, given the nature of the open development model, it is frequently unnecessary to create a new program from scratch. Whatever the program's function, it is likely that someone, somewhere, has done something similar. By scanning SourceForge.net or other similar sites, someone considering an open source project can see whether a sufficiently similar project is already underway. Such a search might turn up an already existing open source project so similar to the one being considered as to make a new project unnecessary. In any event, prior work on similar projects in many situations will provide a foundation for a new project. In such a case, the developer has to consider carefully the license applicable to the pre-existing project.
Depending on the license, the developer may or may not have the ability to choose a different license to apply to the new project. If that pre-existing project uses an MIT or BSD-type license, the developer can use virtually any license, so long as the proper notification and disclaimer provisions are included. On the other hand, if the pre-existing project were licensed under the GPL, the developer would have little choice but to license his or her own project under the GPL or to get permission from the author to use a different license. As discussed in the previous chapter, different licenses provide different levels of compatibility with other licenses. Given a potential conflict between the provisions of two different licenses, it is the better practice to avoid the conflict entirely, either by developing the project under the same license as the pre-existing project, or by obtaining explicit permission, if possible, from the creator(s) of the pre-existing project to cross-license that project under the license to be used in the new project.
Accordingly, in many situations, a developer's choice of license is constrained by choices made by his predecessors. In fact, this is the intended purpose described as having a "viral" effect on licensing decisions of one of the most popular of the open source and free software licenses, the GPL.
In those situations in which a developer is in fact starting from scratch or from code whose license is amenable to change, the decision as to license will probably be largely a matter of personal preference. The factors that might influence this decision include: how frequently used and well-known the license is; how readily comprehensible that license is; and finally, and perhaps most importantly, the license's philosophy, and, in particular, the extent to which the license allows with code developed under other licenses, including proprietary licenses.
In choosing any license to apply to a new project, developers should strongly consider relying on those licenses already well-known in the development community. This makes the project much more transparent to other developers and potential contributors who will probably have a better grasp of the principles of the BSD, MIT, Apache, MPL, and GPL Licenses, than they would of the Monongahela Copper Mining Institute Database License, v8.3. To the extent that licensing issues are important to contributors, using a license already known to them reduces barriers to entry and will likely make for a more successful project.
For much the same reason, using licenses that are written more clearly and which do not contain ambiguous or unusual terms will also help a project succeed. The BSD and MIT Licenses are models in this regard. The Apache License Version 1.1 is both clear and well-known in the development community, and Version 2.0 is becoming more familiar. The GPL and MPL Licenses, while considerably more complex, are well-written and their principles are well-understood. Developers should avoid licenses that seem ambiguous, unduly confusing, or poorly written.
The most important decision in choosing a license will be the choice between a GPL License and a less restrictive license. A full discussion of the disagreement between the two camps is beyond the scope of this book. However, to put it briefly, the GPL is premised on the belief that non-free software is to be avoided and that free software development projects should be set up to encourage open development models of software development and to discourage reliance on software not developed under an open development model, including all proprietary-licensed software. By requiring that any code developed from or based on GPL-licensed code be GPL-licensed, the GPL creates a strong incentive for programmers to license their code under a GPL License, in the form of access to all the code already GPL-licensed.
The argument in favor of less-restrictive licenses such as the MIT, BSD, Apache, and MPL Licenses is that open development model of software development is not inconsistent with the development of software under other models, including proprietary models. The fact that one line of a program, such as the Sendmail program described in Chapter 2, is developed under a proprietary license, does not undermine the open development model, in this view. The more developers and users that are involved in working on particular code, the better, even if some of that development takes place in "closed" development models under proprietary licenses.
In sum, there is no ready answer as to which license is the best for a given project. While a certain license may be better suited for a project, particularly when a substantial amount of work has already been done under that license, such decisions depend largely on circumstances and on the taste of the project developer.