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:

  • GPL
  • ‎LGPL
  • ‎BSD
  • ‎Apache
  • ‎MIT

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.

License owner / License holder

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.

Comply in development

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
    • Call another binary
    • ‎Interface via IPC
    • ‎Use an interpreter
  • Linking
    • Dynamic
    • ‎Static
... 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.

Comply in distribution

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:

  • in a "software bill of material"
  • ‎in the license text of an installer
  • ‎in an about dialog of a software
  • ‎in a user manual

Software bill of material (BOM)

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:

  • a list of all 3rd party software
  • the full license texts for each software
  • ‎everything whats necessary to rebuild the software

Source Code

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.

  • For open source software it can be published as a download
  • ‎For other software it can be provided as part of the delivery

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:

  • Setup your bill of material (BOM)
  • Read the license texts
  • ‎Prepare the BOM for every medium, in which you need to include it
  • ‎Pack the sources together
  • ‎Include the BOM and source package in every distribution

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.


Wiki: IndexMain