Different types of software licenses require you to meet certain obligations if you want to reuse the code. Here are 5 common types of software licenses.
If you write code, you also reuse code, including code snippets, libraries, functions, frameworks, and entire applications. All software code comes with certain rights and obligations if you want to add it to your codebase. Free and open source software (FOSS) is free of cost, but you aren’t free to use it as you wish. Even unlicensed code snippets copied from Stack Overflow have obligations for reuse. But formally developed code usually comes with a specific software license.
There are many different types of software licenses, and the penalties for license noncompliance can be harsh. If you reuse a component without following the obligations of its license, the licensor might sue, and you might be forced to publish your own source code. To protect your code and your organization, you need to understand these software licenses before using any code, including libraries and frameworks, you didn’t write yourself. See our list of the top open source licenses and their potential legal risks.
Here are five types of common software license models you should know about. Four are examples of open source licenses (which allow you to reuse code to some extent), and one disallows any reuse whatsoever.
Public domain. This is the most permissive type of software license. When software is in the public domain, anyone can modify and use the software without any restrictions. But you should always make sure it’s secure before adding it to your own codebase. Warning: Code that doesn’t have an explicit license is NOT automatically in the public domain. This includes code snippets you find on the internet.
Permissive. Permissive licenses are also known as “Apache style” or “BSD style.” They contain minimal requirements about how the software can be modified or redistributed. This type of software license is perhaps the most popular license used with free and open source software. Aside from the Apache License and the BSD License, another common variant is the MIT License.
LGPL. The GNU Lesser General Public License allows you to link to open source libraries in your software. If you simply compile or link an LGPL-licensed library with your own code, you can release your application under any license you want, even a proprietary license. But if you modify the library or copy parts of it into your code, you’ll have to release your application under similar terms as the LGPL.
Copyleft. Copyleft licenses are also known as reciprocal licenses or restrictive licenses. The most well-known example of a copyleft or reciprocal license is the GPL. These licenses allow you to modify the licensed code and distribute new works based on it, as long as you distribute any new works or adaptations under the same software license. For example, a component’s license might say the work is free to use and distribute for personal use only. So any derivative you create would also be limited to personal use only. (A derivative is any new software you develop that contains the component.)
The catch here is that the users of your software would also have the right to modify the code. Therefore, you’d have to make your own source code available. But of course, exposing your source code may not be in your best interests.
Proprietary. Of all types of software licenses, this is the most restrictive. The idea behind it is that all rights are reserved. It’s generally used for proprietary software where the work may not be modified or redistributed.
Before you can determine which licenses govern any reused code in your codebase, you need to create a software bill of materials, or a list of all the components in your code. And the fastest way to generate that list is with a software composition analysis tool. A good SCA tool will be able to find full components as well as code snippets, and it’ll tell you which licenses apply to each piece of code and whether you might be using licenses that have conflicts.
This post was originally published Oct. 7, 2016, and refreshed April 7, 2020.