Open Source Primer

What Is Open Source Licensing?

The growth of Open Source software in the last decade has been exponential and now touches all developers and users alike. However, there is little understanding and much confusion surrounding Open Source licenses. It is important to understand that any Open Source license is a contract between you and the end user that grants her certain rights, such as how she may use, modify, or redistribute the software and derivative works. A basic understanding of Open Source licensing is therefore critical to avoiding legal issues in using other developers’ software as well as to releasing your own software under terms that are consistent with your goals. This primer will help you avoid the common pitfalls in using Open Source software and provide recommended Open Source and non-Open Source licenses for your own software.

In a landmark 1983 decision in Apple Computer, Inc. v. Franklin Computer Corp., the Third Circuit found that computer programs, both in code and executed form, were copyrightable subject matter. The Open Source movement was an outgrowth of this court decision and concurrent insular, closed source trends within software industry.

The Open Source movement’s objective is to keep software free, and two schools of thought emerged as to how to do this: through copyleft or permissive licenses. Copyleft licenses maintain the software’s freedom by requiring all derived works to be released under the same license terms, whereas permissive licenses give freedom to developers by allowing them to release derived works under different license terms, including proprietary ones.

The Major Open Source Licenses

The nearly 100 Open Source licenses sanctioned by the Open Source Initiative, a non-profit widely recognized within the Open Source community that approves new licenses, cover the range of options that exist between pure copyleft and permissive. The following six licenses represent over 85% of Open Source projects:

PermissiveThe MIT License (25%)
• You may deal in this software without restriction, provided you maintain the original copyright notice and provide a copy of the license in your distributions
• The most permissive, simplest, and most popular Open Source license

Apache License 2.0 (15%)
• Similar in spirit to MIT License, but with some restrictions and clarifications
• Explicit patent grant: Gives licensees a license to any patents necessary to run the software (MIT License only gives an implicit patent license)

CopyleftGNU General Public License version 2 (GPL 2.0) (15%)
• Derivative works must also be licensed under GPL 2.0, which requires that complete source code be distributed to licensees. For example, a derivative work comprising MIT License, GPL 2.0, and your own code would have to be released under GPL 2.0

GNU General Public License version 3 (GPL 3.0) (19%)
• Same spirit as GPL 2.0, but updated to include new technical and legal developments and to address ambiguities with GPL 2.0
• Allows Apache 2.0 work to be combined with GPL 3.0 and released under GPL 3.0 only
• Explicit patent grant, whereas GPL 2.0 gave implicit patent grant

Weak CopyleftGNU Lesser General Public License version 2.1 (LGPL 2.1) (6%)
• Applicable to libraries, non-LGPL works may link to LGPL libraries and be distributed under non-LGPL terms as long as the new work is not a derivative work
• Like with GPL, the source code of the LGPL library must always remain open

GPL Licenses and Derivative Works

Because of the restrictions imposed by GPL licenses, it is important to understand under what circumstances your software must be released under the GPL license, and when you can use a different license. To be bound by the GPL license, your work comprising GPL software must be considered a derivative work; it if is not, you are free to use a different license. So what is a derivative work? This is a matter that is still up for debate, both within the Open Source community and within the courts. The following are the most generally held viewpoints:

What is a Derivative Work?
• Modification of the source code of the GPL-licensed software
• Embedding your code into the GPL code such that in order to run the work, both codes must be distributed together.

What is NOT a Derivative Work?
• A work that may be distributed separately from an unmodified GPL work or library and still function

Due to the ambiguity still surrounding GPL and derivative works, if you do not wish to release your software under GPL, we recommend creating as much separation as possible between your non-GPL work and the GPL work. For example, when distributing your non-GPL software, you can inform users that they may download the unmodified GPL-licensed modules from third party locations, and your software will compile the modules when the user runs the program.

Using Non-Open Source Code

What if an Open Source license is not specified? This is actually the most common scenario. According to a 2015 survey by GitHub, the largest host of source code in the world, less than 20% of projects specified an Open Source license. For all other projects, the developer has either specified a different license or has not specified one at all. If the work is under a non-Open Source license, you must follow that license. If no license has been specified, then the work is still under copyright and you would need to reach out to the author regarding permissions.

Licensing Your Software

In order to make your code available and avoid any ambiguity around downstream usage, you must specify a license; for example, simply putting your source code online and stating that you make it available Open Source is insufficient. But with nearly 100 Open Source licenses out there, how do you choose? In our Quick Guide, we recommend three popular Open Source licenses that cover a wide range of purposes: The MIT License, Apache License 2.0, and GPL v3.

We also provide two non-Open Source options. While the definition of Open Source forbids any restrictions of use, we understand the desire of many in the academic community for a non-commercial license; thus we created The Non-Commercial Use License. As the name implies, users are allowed to use, copy, modify, or distribute your software and derivative works for non-commercial purposes only. Users seeking a commercial license from UMass must contact the TTO.

A second and even less restrictive option is what we call a grant of Simple Permission. It is a statement you include with your distribution that is revocable at any time. For example, you could simply state: “You may make a single copy of this software for your personal, non-commercial use; you may not copy or distribute without further permission from the owner.” This statement can be crafted for any intended purpose, and we are happy to help you in this process.

You may find our License Template form here. To apply the license to your work, complete the form by checking the box next to the appropriate license. Then save a copy of the form and name it "[Insert Your Software Name] License." This [Insert Your Software Name] License file should be placed in the top directory of your distribution.

IMPORTANT! Before choosing a license for your software, it is important to ensure that the license is compatible with any Open Source material you may be using in your program. As described above, this is particularly important for any GPL-licensed code you are using.

For More Information

Open Source Initiative – Community-recognized body for reviewing and approving Open Source licenses. A comprehensive FAQ on Open Source licensing may be found here.Choose a license – Resource to help select the right license for your project. A table comparing the major Open Source licenses may be found here.License Flow Chart – Flow chart that shows how source code released under different licenses may be combined.Source Code Hosting Facilities – Wiki that compares major online hosting services for your source code.