The widespread creation and reuse of open source software by commercial companies has introduced a whole new level of complexity to the legal challenges related to software licenses. Companies distributing open source software must draft or choose an appropriate license for their original code and they must understand and comply with the license obligations imposed on them with the use of third-party code, including open source. Deciding what open source license to distribute software is a key element in building an ecosystem of users, partners, supporters, and advocates.
It is estimated that there are over 1,900 available open source software licenses. Many of these licenses contain small changes to the most popular ones. The proliferation of open source licenses causes complexity for authors and users alike, and can make choosing a license an overwhelming task. The challenge is to choose a license that aligns with your goals, e.g., widespread adoption of your code, recognition, freedom, etc. Below are some factors to consider when choosing a license for your open source software project, and similarly, approving an open source software package for internal use.
COMMUNITY APPROVED LICENSES
One consideration is the familiarity of the license and whether it conforms to the generally accepted terms of an existing open source license. For example, third parties may be more inclined to adopt your project if it is licensed under community endorsed terms. By narrowing the selection of open source licenses to those that have been generally reviewed, understood and accepted by both developers and attorneys, the number of users that choose to adopt your project is likely to increase.
One resource is the list of over 60 licenses approved by the Open Source Initiative. OSI conducts a public review of proposed OS licenses with the goal of ensuring that open source licenses meet community expectations. This helps to institute standards and discourages unnecessary license proliferation. In practice, over 93 percent of open source projects use one of ten licenses detailed in the chart, directly below.
PERMISSIVE LICENSES
A software publisher should consider how much control it wishes to exert over future distributions and modifications of a software package. There are a number of different licenses available for different levels of control. Take, for example, an MIT or BSD license. Both licenses are well-known and respected examples of what is commonly termed “permissive licenses.”
Permissive licenses allow for future licensing terms of derivative works made by the licensee to be more restrictive than the original license provisions. MIT and BSD-type licenses typically only require that the original licensing terms be present in a future license for derivative works. Other permissive open source licenses, for example, simply require that you include the original copyright notice in your outbound terms. Use of an MIT or BSD-type license might be a good option if the software publisher would like to extend to end-users significant flexibility concerning the use of the source and object code, including using the code for future commercial distribution under more restrictive provisions. Licensees adopting open source are then free to impose restrictions on downstream end users without having to disclose source code. For this reason, many commercial organizations view permissive licenses favorably.
RESTRICTIVE (“COPYLEFT”) LICENSES
On the other end of the spectrum are restrictive licenses, frequently referred to as “copyleft” licenses. Copyleft licenses limit the choices of downstream users with respect to the license they can use for their software.
In many cases, copyleft licenses require a licensee who distributes a derivative of a work licensed under a copyleft license to do so under the original license provisions. For the GNU Public license, the most popular license used by the open source community, these terms are respectively defined within versions 2 and 3 of the license.
For a software author, if the business strategy includes tapping into an ecosystem community of developer partners who continually improve a software component, a strong copyleft license may be a good option.
The most widely used copyleft license is the GPL. Both GPL versions 2 and 3 require that licensees include a copy of the GPL with each distribution made, and furthermore, that no modifications be made to the terms of the license.
Arguably the best known open source project, Linux, is licensed under GPL version 2 and has declared an intention not to migrate to version 3. There are over 11,000 open source projects that have adopted GPL version 3 since its inception in June 2007, but as is shown in the table above, this is still a small proportion of the total number of projects.
The GPL license does not prevent companies from generating revenue from software. However, the software must remain “free and open.” If the licensee creates derivative works or modifies the work in any way, the licensee must make the source code available to users when and if they distribute the software.
Licensors often choose a copyleft license to ensure that source code and derivative works remain freely available. Often times, as in the case of the GPL or the Mozilla Public License, copyleft restrictions are applied to the software itself, but are not applied to software that merely LINKS with a program. Many publishers of software libraries adopt this strategy.
DUAL LICENSING MODELS
An increasingly popular alternative for open source projects is to distribute software under a dual or multiple licensing models. Dual or multiple licensing is when a copyright holder distributes software under multiple licensing terms.
The most common scenario involves dual licensing to promote open source while offering a separate version under more traditional commercial license terms, e.g., MySQL.
A permissive open source license coupled with a commercial license can be attractive to users that may hesitate to accept the strong provisions of a copyleft license but want to include some of the source or object code within the licensee’s own software and distribute it without source code to sub licensees.
CONCLUSION
Whether an author or business model demands restrictive or permissive licensing terms, there is likely to be an OSI-approved license that supports the goals of the individual or organization. So you may not need to create your own license or pay an attorney to create one for you. Authors need to weigh their objectives against the various types and popularity of licenses.
Users need to understand the license obligations of open source software they are considering, evaluate them for their particular use case, and be sure they can abide by them. There is an abundance of open source available.
It’s a valuable and powerful resource that many companies employ to improve the efficiency and speed of their development process.
Source:http://www.law.com/jsp/lawtechnologynews/PubArticleLTN.jsp?id=1202451489438&CherryPicking_Open_Source_Licenses
