Understanding Open Source Licenses and Obligations

Snapshot

Applies to: Open Source developers
USP: Learn how open source licensing works and what you should know before distributing your code
Primary Links: Migrating to Open Source http://ld2.in/43b;
Search engine keywords: open source licensing

Mahshad Koohgoli, CEO, Protecode (www.protecode.com)

While anyone can make the source code of their project available to the public under any terms they wish, the OSI (Open Source Initiative, www.opensource.org) has a formal definition of what constitutes an open source license. According to OSI, for a license to be recognized as open source, it must have these attributes:

• Allow free redistribution of the code
• Make the source code available to the public
• Allow code modifications
• May allow redistribution of the code as original plus patches
• Should not make any discrimination against specific users
• Should not make a discrimination against usage fields
• Must allow for distribution of the original license
• The license must not be limited to a product, be technology neutral and must not restrict any other software.

Under these definitions, there are 70+ licenses listed in OSI as recognized open source licenses. Broadly, we can divide these licenses into two categories:

1. Permissive licenses generally put no restrictions on the licensing of the derivative code, except generally a citation and a requirement that the license text be kept in its original form in the modified or distributed code.

2. Restrictive open source licenses, also called Protective or Copyleft licenses, generally aim to keep their code and their modified versions as open source. They do so by requiring that all derivatives (modified versions) of the program be provided under the same license as the original software that was obtained. The GNU Public License (GPL) is one of the stronger licenses, where as EPL or LGPL are weaker copyleft licenses as they allow derivative works to be licensed differently under certain circumstances.

Regardless of whether the open source code is available under a restrictive or permissive license, they are all protected under copyright laws, and the copyright owner always remains the author of the software. Almost all licenses require that you identify the copyright owner, and include the original license text or headers in your derivative project.

None of the recognized open source licenses (approved by the OSI) put any limitations on commercialization of projects that use software governed by these licenses. You can charge for your products whether or not they use these open source licenses.

As mentioned earlier, copyleft licenses such as GPL 2.1 would require you to release your code to the public under the same license. This may or may not be acceptable depending on your business model, your competitive position, or barriers to entry to your market for others.

Permissive licenses such as the Berkeley Software Distribution (BSD) license would be more suitable if you do not wish to make your code available to the whole world. There are different versions of licenses though. For example, LGPL will allow you to link your code to a GPL open source software without opening up your own code. GPLv2.1 requires you that you release your code under GPLv2.1 even you link to such open source software. With GPL, copyleft licenses will not apply if you do not distribute your software unless you use open source code governed by an extension of GPLv3 called Affero.

When using open source software with differing licenses within a project, compatibility between the open source licenses must also be taken into consideration. Compatibility issues arise when one set of requirements from one license type clash with requirements from another. Most restrictive or copyleft licenses are not compatible with permissive licenses. For example, mixing Apache V2 license and LGPL license, if the LGPL code is only linked to, may be permissible. But mixing Apache V2 with GPLv3 will not be compatible if you do not intend to release your project under GPLv3. Generally, GPL allows use of permissive licenses in projects that are released as GPL only.

Whichever license you choose, it is important to have a licensing policy as well as an open source software adoption process in place to properly manage licensing obligations. Having a process in place will ensure that only licenses which conform to your policy are used and will save time and money on correcting problems.