Saturday, March 11, 2017

Deconstructing Open Source Software Licenses

When drafting and negotiating software license agreements, I frequently come across open source licenses.  This blog post is to clarify some of the myths that exist around the definition and use of open source software.

First, I want to distinguish open source software from software that is in public domain.  Public domain software is absolutely without any copyright or other intellectual property restrictions.  Anyone can modify it, distribute it, and use as they see fit.  Open source software, on the other hand, is licensed.  It may, but doesn't have to be free. Typically, licensors of open source software charge for providing support, consulting, and other professional services in connection with their open source software.  They cannot charge royalty for the source code itself or the right to modify and redistribute it.

Next, let's investigate the reasons for licensing software under one of the open source licenses.  The main reason for opting to license software under an open source license is the opportunity to get the software noticed, used, improved, and revised by developers anywhere on a continuous basis.  The result is software of high quality that is free of bugs, frequently used, and is current.  Of course, it comes at a price. Since developers can download, modify and redistribute open source software, licensor of such software is unlikely to get rich of the software license fees.  It needs to be able to provide support, consulting, maintenance and other related services to compensate for the loss in license royalties.

And now let's zero in on the terms of the open source software licenses.  They generally fall under two categories: copyleft (restrictive) and permissive.  The existence of copyleft open source licenses is probably the main reason why software developers are suspicious of open source software in general and may be reluctant to use it in their own software.  A copyleft license requires all software recipients to redistribute it under an open source license.  So, if a developer incorporates a part of copyleft open source software into its own larger software program or creates a derivative work based on it, then the entire program or derivative work would have to be distributed under an open source license (i.e., a copyleft open source license "infects" the entire work).  This is the reason why, when negotiating software license agreements on behalf of a licensee that has the right to create derivate works and redistribute the software, it is important to understand whether the licensor has used any open source software and if yes, then under which license.  It is then a good idea to ask for a warranty from the licensor that it has not used any copyleft open source software and for indemnification.  On the other hand, if licensee does not intend to redistribute the software but only intends to use it, then having a copyleft open source software should not be a big concern.

The best-known copyleft license is the GNU General Public License (the "GPL"), provided by the Free Software Foundation.  The current version 3 is available here.  The key terms are in Sections 2, 4-6, and 10.  Version 2 is still widely used (actually more so than the recent version 3).  The key provision in Version 2 is Section 2(b) that says:
"2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work… provided that you also meet all of these conditions:....
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this license."
Other copyleft licenses include GNU Lesser General Public License (LGPL) versions 2.1 and 3.0, GNU Affero General Public License, Artistic License (Pearl), Mozilla Public License (MPL) 1.1 (requires modified versions of the software to be distributed using open source model but doesn't apply to all derivative works, just to the modifications of original code), and Eclipse Public License (EPL).

Overall, according to an open source software provider Black Duck, the use of copyleft or restrictive licenses is declining.  In 2010, about two-thirds of open source software was under copyleft licenses.  In 2017, no more than 37% of open source software use was under copyleft licenses, with GPL version 2 use declining from 48.5% in 2010 to only 18% in 2017.    

Permissive open source licenses let the licensee include open source software into their larger program and then distribute the program under any license it wants.  Most frequently used permissive open source licenses are Apache License 2.0, and Open Source Initiative's MIT License and BSD 2.0.  Sections 2 and 4 of the Apache license allow licensee to reproduce, prepare derivative works of, publicly display, perform, sublicense, and distribute the open source software so long as a copy of the Apache license and certain notices are included.  The licensee may provide additional or different license terms governing the use, reproduction or distribution of any derivative works, provided it continues to comply with the Apache license.  Apache license is the preferred open source license for Android.  The MIT and BSD licenses are probably the least restrictive of all open source licenses because they do not have any IP-specific restriction on redistribution of software.  

According to Black Duck Software, the use of Apache license rose from 4% in 2010 to 14% in 2017.  The use of the MIT license rose from 4% to 32% in 2017, while the use of the BSD license remained at approximately 6% during the same period of time. Currently, MIT license is ranked as #1 open source software license in use.

In conclusion, it is important for software developers and their attorneys to understand the different open source licenses.  Using open source software is beneficial to all, but the license for it needs to correspond to the intended use of the software in the hands of the licensee.

This article is not a legal advice, and was written for general informational purposes only.  If you have questions or comments about the article or are interested in learning more about this topic, feel free to contact its author, Arina Shulga.  Ms. Shulga is the founder of Shulga Law Firm, P.C., a New York-based boutique law firm specializing in advising individual and corporate clients on aspects of corporate, securities, and intellectual property law.


No comments:

Post a Comment