By Nicholas Shen
Open-Source licenses allow for distribution of freely collaborated software. End user recipients can then review or modify the source code to further distribute. While these licenses can be individually tailored to each project, the most common licenses are those approved by the Open Source Initiative (OSI). All OSI licenses must conform to their Open Source Definition (OSD).
OSD – Minimum Criteria
- Free (cost) Redistribution
- Source Code included (or easily accessible) in all distributions with compiled form
- Derived works are allowed and distributable under the same terms as the original software license
- If distribution of patch files is allowed, modified source codes can be distributed
- No discrimination against persons, groups, specific program use
- License rights and restrictions attach to the program and apply to recipients of the program
- License must not be specific to a product, including particular software distribution
- License must not restrict other software – cannot mandate all other programs to be distributed on the same medium as the OSS
- License must be technology neutral – cannot be predicated on any individual technology (programming language) or style of interface
Copyleft vs. Permissive Licenses
Copyleft licenses require derivative works to be licensed under the same license. If a software recipient modifies the original source code, all distributions of that code must disclose the original and modified code. Some copyleft codes additionally require notice and explanation of all changes to the source code. However, if a recipient does not create an actual derivative, then the copyleft terms are not activated to require the new code disclosure. Whether code is a derivative of the originally available open source code is debated and discussed under ‘Derivative Work.’ GPL and MPL are examples of copyleft licenses.
Alternatively, recipients of permissive licensed code may use it as part of closed-source software or software released under a proprietary license. Most software developers prefer to use permissive licensed code over copyleft to develop proprietary software (derivatives) without possibility of copyright violation or “infection.” BSD or MIT are examples of permissive non-copyleft licenses.
Derivative Work
The Copyright Act at 17 U.S.C. section 101 defines a derivative work as “a work based upon one or more preexisting works [] consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship.” Generally, if a user takes the copyrighted source code under a license and physically modifies it by actually revising the program, then the code is a per se derivative work.
However, the Ninth Circuit Court of Appeals ruled that when a proprietary software merely accesses the copyrighted source code without modifying the code, it does not constitute derivative work. Galoob v. Nintendo, 964 F.2d 965 (9th Cir. 1992). To test whether a new program is a derivative work involves determining whether the source code of the original program was used, modified, translated or otherwise changed in any way to create the new program.
Derivative use of original source code does not include software created by dynamically linking to a code library. Unless the creators of the new program designed it with some apparent common understanding of what a derivative work based on the original source code would look like, linking to libraries does not create derivatives. By contrast, statically linking to non-library code, including accessing it through third party nodes, does constitute a link to the direct source code of the original program, which is a derivative. If the source code was licensed by a copyleft license, the creator must then relinquish all code relating to the new program.
Popular OSI Approved Licenses
2. BSD 3-Clause “New” or “Revised” license
3. BSD 2-Clause “Simplified” or “FreeBSD” license
4. GNU General Public License (GPL)
5. GNU Library or “Lesser” General Public License (LGPL)
6. MIT license
8. Common Development and Distribution License
10. Other: Special-purpose license, superseded licenses, retired licenses
11. User submitted multilateral copyright licenses – requires approval by the OSI Board through a public review process.
1. Apache License 2.0:
Recipients may modify the software so long as they include notice. The original patent claims are retained but are usable. This license is permissive.
| Recipient can: | Recipients cannot: | License must |
|
|
|
2. BSD 3-Clause (also known as “BSD New” or “BSD Simplified”)
Recipients have almost unlimited freedom with the software so long as the BSD copyright and license notice is included with the code. This license is permissive.
| Recipient can: | Recipients cannot: | License must |
|
|
|
3. BSD 2-Clause
Recipients have almost unlimited freedom with the software. No trademark restrictions. Must include license and copyright notice with code. This license is permissive.
| Recipient can: | Recipients cannot: | License must |
|
|
|
4. General Public License 3.0 (also known as “GPL Public”)
Recipients may distribute and modify the software but must track changes/dates in the source files. All modifications to any software code must be made available (object and source code) with build and install instructions. This license is copyleft.
| Recipient can: | Recipients cannot: | License must |
|
|
|
5. Library General Public License 3.0 (also known as “LGPL” and “Lesser GPL”)
This weaker copyleft license differs from GPL in that it is mainly applied to libraries. Derivative works (including modifications or anything statically linked to the library) can only be distributed via LGPL. Applications that only use the library do not need to be distributed in accordance to LGPL – see ‘Derivative Work’: dynamically linked vs. statically linked.
Recipients may distribute and modify the software but must track changes/dates in the source files. All modifications to any software code must be made available (object and source code) with build and install instructions.
| Recipient can: | Recipients cannot: | License must |
|
|
|
6. MIT License (most popular as of 2015)
This permissive OS license allows recipients almost unlimited freedom so long as the original copyright and license notice is included in any (re)distribution of the source. It can be integrated into GPL, but not the other way around.
Recipients may distribute and modify the software but must track changes/dates in the source files. All modifications to any software code must be made available (object and source code) with build and install instructions.
| Recipient can: | Recipients cannot: | License must |
|
|
|
7. Mozilla Public License 2.0 (also known as “MPL 2.0”)
This copyleft license requires all derivative source code to be disclosed however MPL software may be combined and binaries can be distributed under a proprietary license so long as it is kept in a separate file.
| Recipient can: | Recipients cannot: | License must |
|
|
|
8. Common Development and Distribution License (also known as CDDL)
This copyleft license used by Sun Microsystems includes explicit patent grants. Like MPL, binaries may be distributed under a proprietary license so long as all source and modified code is released.
| Recipient can: | Recipients cannot: | License must |
|
|
|
9. Eclipse Public License
This weaker copyleft license used by the Eclipse Foundation is similar to GPL but also allows recipients to link code under the license to proprietary applications – including licensing binaries under a proprietary license. All source and object code must be disclosed. Recipients must defend/compensate the original contributor from suits against commercial offerings.
| Recipient can: | Recipients cannot: | License must |
|
|
|
Nicholas Shen is an intellectual property attorney who focuses his practice on all aspects of intellectual property litigation in federal and state courts and arbitration tribunals.