Key Levers of Open Source Licenses

Blogger: Larry Cannell

This is the second in a series of blog posts intended to help IT managers understand open source licensing and its implications. In this post I cover the basics of open source licensing while also highlighting aspects that can enable vendor business models and influence how an enterprise approaches using open source products.

The definition of an open source license is generally considered to be the responsibility of the Open Source Initiative (OSI), a non-profit corporation formed in 1998 to promote the development and use of open source software. The OSI definition of an open source license is called the Open Source Definition (OSD) and is made up of 10 requirements that must be met before a license can be considered open source. OSI maintains a list of approved software licenses that have gone through their license approval process. Software creators can use the OSI Certification Mark logo and notification text if their software is licensed with one of the OSI approved licenses.

OSI presently lists 72 approved open source licenses. However, only a few of them are in wide use. For example, Freshmeat (a site that tracks open source software) says that over 60% of open source projects use the GNU General Public License (GPL). To make open source licenses easier to understand it is best to break these down into two broad categories: hereditary licenses and permissive licenses.

The most controversial, and most recognizable, hereditary open source license is the GPL. The terms of the GPL most relevant to enterprises using open source products are:

• The source code must be made freely available.
• Once software is licensed as GPL its licensing terms cannot be changed (the only exception being an owner, who retains all rights to the original source code).
• Any modifications to the GPL-licensed source code, or any software incorporating GPL software, must also be licensed under the GPL and may also be required to be made freely available. This is also known as the “Copyleft” provision. However, this provision is only triggered when the software is distributed.

In the diagram below, source code licensed under the GPL is mixed with “Your Source Code,” which could be as simple as small changes to the GPL-licensed source code or as complex as software intended to be kept proprietary (either custom developed or purchased). The GPL’s “Copyleft” provision requires the resulting software to also be licensed under the GPL, if it has been distributed. Resulting software not distributed is not required to be licensed under the GPL.

 

For many businesses, which sell commercially licensed software, the GPL is viewed as “viral” and a threat to their business model. Open source products licensed under a permissive license, such as the Apache License, are generally acceptable to commercial software vendors and not seen as a threat. The diagram below illustrates why:

 

The key points from the above diagrams are:

• Enterprises need to be careful when integrating with products with open source hereditary licenses. However, I should also note that care should be taken for integrating with any licensed software.
• The act of distributing the resultant software (“Something New”) triggers the Copyleft provision of the GPL. Unless the software is distributed then the provision is not invoked. In an enterprise context, distribution of source code generally means giving copies of it to someone outside of the enterprise. However, there are other hereditary open source licenses that define “distribution” much more broadly and includes the act of using the software over a network (for example, a web application being used over the Internet) and may not involve the transfer of source code at all.

Other levers that are involved but are not obvious from the above diagrams:

• A source code owner (the original author or somebody who has obtained ownership rights) can license the software any way they like. For example, they can release one version under the GPL and another under a commercial license.
• A few open source licenses have other restrictions requiring some form of attribution. This can be simply attributing ownership in the source code or retaining the use of the owner’s name or logo in screens seen by someone using the product.

To sum it up, the key levers of open source licensing, which can support a vendor’s business model, and which enterprises should be aware of are:

1. Hereditary versus permissive licensing (and the impact of Copyleft)
2. Source code ownership rights
3. Limitations around attribution
4. What defines “distribution”

My next post will discuss the types of open source businesses these levers enable and what this means for enterprises wanting to use open source solutions.