Distribution

There is a newer version of this page. You can find it here.

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 alrady during development, but latest when we prepare the distribution of your software.

Because there 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 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 for 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. To grant the right to others in a structured way, many license owners are putting the software under a standard license.

In this article, we will focus on a special type of those standard licenses, which are typically called "open source licenses".

Redistribution

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 licemses to others.

Here is an example text, from the apache license, which is granting us the right for sublicensing 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 im 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 here. Here are the actions for the popular licenses, listet above:

    |  include license text | include NOTICE file | punlish 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

The american "Cyber Supply Chain Management and Transparency Act of 2014" forced all ammerican originators 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 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 of this software
* ‎everything whats necessary to rebuild the software

Source Code

The source code typically needs to be provided on request, and in an 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 othe software it can be provided as part of the delivery

This is a way to make it easier for users to redistribute software.

Summary

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 complaint 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), but those need to be assessed case by case.