BACKGROUND IMAGE: stock.adobe.com
Reuse is not a matter for debate with proprietary software. When developers produce software in-house, they create a piece of intellectual property that is guarded through the restrictions of a commercial license. But as the industry evolves and adopts open source software, including as small components within a larger development product, open source software licenses take on great importance.
Enterprises and individuals have released a burgeoning volume of open source code subject to far less restrictive licensing, which often grants users rights to examine, alter, use, redistribute and even resell the code to anyone for any purpose. Open source software has had a remarkable effect on software development, as it enables contributions from a global developer community, sometimes accelerating the creation of powerful new products without a prohibitive cost or time burden.
But licenses sometimes pose challenges with open source software. There are myriad open source software licenses, and each one imposes some level of binding terms and conditions. Thus, the challenge with open source software is not only how to access or modify such code, but rather how to do so while observing the terms of these licenses, and how licenses interact with each other.
It's easy to forget that there is a difference between open source and free or public domain software. Licenses govern open source software. There are dozens of established open source software licenses, each with its own unique, sometimes dramatically different, terms and conditions. It's crucial that developers understand some of the most vital terms that accompany various open source licenses to avoid potential legal ramifications.
Here's what developers need to know about five common open source software licenses.
Apache License 2.0
The Apache License 2.0 provides a broad set of guidelines that apply to both copyrights and patents. It's unusual for open source licenses to cover both.
Apache License 2.0 conveys a perpetual, worldwide, non-exclusive, no-charge, royalty-free and irrevocable license. Users can reproduce the licensed work, prepare derivative works, publicly display or perform work, sub-license and distribute the work or changes as either source code or object code.
When open source software is released under the Apache License 2.0, developers can use the licensed software forever, anywhere, without purchase costs or royalties; and they can redistribute variations on the code under different licenses. These rights cannot be withdrawn, though there are exceptions in patent infringement cases -- see section three of the license. Also, there are some requirements when redistributing the code under Apache with or without modifications, but those requirements generally relate to how the license information is displayed and how credit is provided.
There are two permutations of the BSD license, which typically applies to software with virtually no restrictions on distribution and use. BSD licenses, named after the Berkeley Software Distribution OS, are fairly prevalent, particularly for free software.
The 3-Clause BSD License, also known as the New BSD License or Modified BSD License, follows a straightforward copyright arrangement. Developers can use and redistribute software under this open source license in either source or binary forms, with or without modifications. There are only three points, or clauses, to which developers must adhere:
- users must include the copyright notice, along with the list of conditions and a standard disclaimer;
- redistributions in binary form must reproduce the copyright notice, conditions and standard disclaimer; and
- neither the copyright holder nor contributors may be used to endorse or promote products created from the code without separate consent. Therefore, a developer cannot fork the code then claim the code creator sanctioned this new version.
The 2-Clause BSD License, also called the Simplified BSD License or the FreeBSD License, simply removes the third clause regarding author/contributor promotion.
There are two versions of the GNU General Public License (GPL). The terms of the latest iteration, GPL version 3, are clear and readable overall; it allows open copy, redistribution and modification. Developers who use open source code covered by GPL version 3 can choose to charge a fee for their open source software.
However, the GPL imposes several important restrictions on developers and users. The GPL emphasizes copyleft behaviors for activities such as including linking, distribution, modification and re- or sub-licensing. Generally, copyleft clauses require that uses of the work observe the same terms and conditions to which the original code adheres. Thus, open source software obtained under GPL version 3 retains those rights indefinitely. In addition, developers must include a copy of the GNU GPL with the software as it's redistributed and within the software itself. Other restrictions exist for source and binary software distributions under the GPL.
The GNU Lesser General Public License (LGPL) provides a slightly more permissive option than version 3. The agreement, for instance, allows linking the LGPL code with code under non-GPL licenses -- a practice prohibited under GPL version 3. Consequently, developers often use LGPL when they want to allow for the use of non-GPL open source libraries, but preserve other copyleft restrictions.
The MIT license is one of the most brief and straightforward of any open source software license. This license grants broad permission for anyone to use the software without restriction; the developer can use, copy, modify, distribute, re-license and even sell the software.
The only restriction with the MIT License is that the copyright notice, permission notice and disclaimer must accompany all copies or partial copies of the software.
Mozilla Public License 2.0
The Mozilla Public License (MPL), version 2.0, is generally deemed a weak copyleft license. This open source license is somewhat more permissive than GPL in terms of linking MPL code with code under other licenses, yet it still enforces some key copyleft terms. For example, developers must release any source code that results from the project under MPL, but they can combine MPL and proprietary code, as long as the former is kept distinct. The development team can release binary files under a different license, but source code must adhere to MPL. MPL is generally regarded as compatible with GNU LPGL and GPL.
Developers can use, modify and distribute the software and protect it with a warranty, and they can even use the software in a patent. However, they must include a copyright notice, license copy and source disclosure -- where the source code came from.