Software licenses
Software licenses are a contract between the author of a specific software code and its consumer users. They establish the terms, conditions and clauses that must be fulfilled in order to use the software — that is to say, it is a set of permissions that a developer grants to a user to be able to use, distribute or modify his program under a certain license.
Goal
Today, a large number of dependencies are consumed without taking into account the type of license under which they are being used, and this can cause legal problems when a product is going to be released. When using dependencies within our projects, we have to make responsible use of them, taking into account even transitive dependencies.
In case of finding, within those dependencies, some that are not allowed in our project, there are the following options:
- Remove that library and look for a more permissive open source alternative (such as MIT or Apache2).
- Pay the license, if possible.
- Develop that part of the code, taking into account the possible maintenance and auditing problems that this may imply.
To do this, we will now detail the types of the existing licenses, and how to identify them in our projects.
Types of licenses
Software licenses are usually classified according to the rights that the authors reserves over their product, so let’s see the known classifications.
Free software licenses
This type of license allows the use, copy, modification and redistribution of the software that is being used. Nevertheless, there are many types of free software licenses that can be more or less permissive, and it is important to take them into account. The differences between all of them will be explained below, and you can also visit the free software licenses appendix to see it in more detail.
Permissive
These types of licenses allow the creation of a derivative work of the software that is being used without any type of restriction. In this category, we can find the following ones:
- Academic Free License v.1.2
- Apache Software License v.1.1
- Artistic License v.2.0
- Attribution Assurance license
- BSD License
- MIT License
- University of Illinois/NCSA Open Source License
- W3C Software Notice and License
- Zope Public License v.2.0
- Open LDAP License v.2.7
- Perl License
- Academic Free License v.3.0
- PHP License v.3.0
- VMS License
Protected with copyleft
Unlike with copyright, these types of licenses do not allow any additional restrictions to be added to the product. Som if the software has been modified, any added modifications must be free software and must be licensed under the same terms and conditions as the original license.
In this category we can find the following licenses:
- Common Public License v.1.0
- GNU General Public License
- GNU General Public License v.2.0
- GNU General Public License v.3.0
- Eclipse Public License
- eCos License v.2.0
- Sleepycat Software Product License
- Affero License v.1.0
- Affero License v.2.0
- OpenSSL License
Protected with weak copyleft, or hybrid
They include a clause that requires that the modifications made to the original software must be licensed under the same terms and conditions of the original license, but the derivative works that can be made from it, can be licensed under other, different terms and conditions.
In this category we can find the following licenses:
- GNU Lesser General Public License v.2.1
- Mozilla Public License
- Open Source License
- Apple Source License v.2.0
- CDDL
- EUPL
Proprietary software licenses
Their use, modification and redistribution is prohibited and requires permission to do so.
Commercial software licenses
Developed by a company that intends to earn money for its use, without making a difference whether it is free or proprietary software.
Some well-known examples of this type of software are: the Windows operating system, Microsoft Office, Adobe Photoshop, among others.
Public domain software
Use, copying, modification, or redistribution, either for profit or not, is permitted.
Other knowntypes of licenses
Freeware
It is used for programs that allow redistribution but not modification, and where their source code is not available.
Shareware
This software allows you to redistribute copies but a license must be paid for continued use.
Identifying the licenses in our projects
There are several ways to perform this process:
- Through proprietary software.
- Through Maven plugins.
- Through free software that can be included in our CI/CD cycle, such as Jenkins.
Commercial software
In this section we will explain the alternative that we have found most interesting, that requires Ultimate subscription with Gitlab.
Gitlab License Compliance
Within the options of Gitlab projects, we can find certain plugins to perform tasks on them. In this case, there is the option to include the Auto License Compliance tool through the Auto DevOps option.
This solution uses an open-source tool, License Finder, to discover licenses, including third-party licenses, for project dependencies. Gitlab checks the license report, compares the licenses, and displays them in the merge request, so that we will be able to see if a compliance issue has happened during its check, and prevent the merge from happening otherwise.
It also has policies where you can accept or deny licenses comfortably:
Maven plugins
There are different alternatives that consist of including a plugin in Maven, specifying in a black list the licenses that we want to avoid, so that if there is any coincidence, the Maven construction process will give an error that would stop the CI/CD cycle.
Several examples of alternatives created by GitHub users are as follows:
Although they are solutions to bear in mind, this is not a software with frequent updates or a reliable support.
Open Source Software
These types of solutions are the most common in terms of compliance control. Bear in mind that, to use them, you must introduce them within our CI/CD cycle, and this is not, in general, an easy process, or not as easy as the GitLab option could be. You have to carry out configuration, in some cases create custom Docker images or use generic ones that take up a lot of space, an option that can be problematic.
The best known are listed below:
FOSSA
It is a dependency analyzer under an MPL-2.0 license that can identify direct and third-party library licenses used in the code. This alternative is used, for example, by Docker through its image published on Docker Hub.
FOSSA can analyze multiple programming languages such as PHP, Java, Python, Ruby, among others. It is also integrable in CI/CD cycle tools such as Jenkins, Gitlab, etc.
Although it is presented as an open source option, it has limitations in its use and requires you to register on its website to obtain an API Key that will be used to manage the projects through its interface. To obtain more privileges in its use, you must subscribe.
FOSSology
It is an open source alternative under the GPL-2.0 license that, like FOSSA, is capable of identifying direct and third-party library licenses used in the code. It can be used through the command line and an interface that connects to a database to manage it through a web client.
FOSSology is used by companies like HP, Siemens, and The Linux Foundation, among others.
License Finder
It is an open source alternative under the MIT license, which is intended to compare the licenses found in the project’s dependencies against a list created by the user to generate a desirable report.
License Finder is developed in Ruby and can be downloaded as a Ruby gem. It can interpret multiple languages including Java, C++, JavaScript, Go, etcetera.
It presents an image on Docker Hub that has all the necessary packages installed to use all of its options, although it is bigger than 2 GB. To avoid having to use the complete image, with many of the packages unused and taking up memory unnecessarily, a good option for its use can be to create your own image, loading only what you want to use through Ruby, and then consume that image, properly configured, from Docker.
Among all the Open Source options mentioned above, License Finder seems the most interesting option due to its ease of use and integration. However, it requires more technical knowledge for its proper configuration than the proprietary options or direct integrations with Maven.
✍🏻 Author(s)
