Even when we start programming on a totally new piece of software, we might quickly get in contact with 3rd party licenses, which are often open source licenses. We might face this issue already during development, but latest when we prepare the distribution of our software.
Because then we need to decide how we can prepare a package, containing all the dependencies to libraries or even programming language interpreters (e.g. Python), which the user might need to use our software.
Even if licenses are very often standardized, you are recommended to read through the terms of every project that you will redistribute before doing so. The following shows the requirements of the most popular open source licenses:
The following instructions should provide you some ideas about how you can solve the typical problems which you will face. But be aware, that the legal aspects have to be assessed by yourself in every single case.
By default the originator of a software is initially the license owner of the software. He can grant licenses to others and even allow others to redistribute or sublicense the software. To grant the right to others in a structured way, many license owners are putting the software under a standard license, like the ones listed above.
In this article, we will focus on a special type of those standard licenses, which are typically called "open source licenses".
It is important that we make ourself clear about our role. When we use open source software in our own programs, it makes a huge difference if we use this software just for ourself, or if we distribute it to others.
As soon as we use the software in some device that we give or sell to others, or when we provide the software for download, we become a distributor.
On the other hand, if we just installed the software on a server, and provide web services to others, we will not distribute but just use it.
So, in one case, we are a user, in the other case we are a distributer. In both cases we will become a license holder. But in case we are distributing, we need the special right to issue licenses to others.
Here is an example text, from the apache license, which is granting us the right for sub-licensing and distribution:
2. Grant of Copyright License.
Subject to the terms and conditions of this License, each
Contributor hereby grants to You a perpetual, worldwide,
non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works
of, publicly display, publicly perform, sublicense, and
distribute the Work and such Derivative Works in Source
or Object form.
As soon as you start to become a distributor, the below requirements will start to apply to you.
As a developer, it is important to know what a 3rd part licensed product allows me to do with it, before I integrates it into my project. There are several ways how the systems can interface with each other. But if we want to retain our freedom to choose our own license, we can't use every of them with every license.
| ... | binary interface | dynamic linking | static linking |
|---|---|---|---|
| GPL. | allowed | not allowed | not allowed |
| LGPL. | allowed | allowed | not allowed |
| BSD. | allowed | allowed. | allowed |
| Apache | allowed | allowed | allowed |
| MIT | allowed | allowed. | allowed |
Note, that you can even use combinations, which are marked as "not allowed", but you loose some rights on your software in that case.
The actions that needs to be taken, actually depend on the kind of license.
As the number of licenses are huge, we can't list all of them. Here are the actions for the popular licenses, listed above:
| ... | include license text | include NOTICE file | publish source code |
|---|---|---|---|
| MIT | yes | no | no |
| Apache | yes | yes | no |
| BSD | yes | no | no |
| LGPL | yes | no | no |
| GPL | yes | no | yes |
The license texts and the NOTICES can be provided either:
The american "Cyber Supply Chain Management and Transparency Act of 2014" forced all american software suppliers to provide a bill of material for their software. This typically included also a list of all licenses, which are involved.
Even if this act is pending now, it is still a good idea to keep such a list for every released software package. Even if you include already the license information in your installer, documentation, ... . Because this will make life of redistributers much easier.
So ideally you provide:
The source code typically needs to be provided only on request, and in a form that it can be rebuild. But it is recommended to provide them to every user.
This way we make it easier for users of our software to redistribute it. As they can include our BOM, and our sources into their BOM and their sources.
If you use open source software, and you want to safely redistribute it, the following is a good practice:
This approach tries to be as compliant as possible, and will use the most strict license as a reference for all others. This way you don't need to deal with exceptions.
There are some licenses which have more requirements (like advertising clauses, etc.). Make sure that you assess and respect them in your distributions.