Generate the license report

First we need to change into the root directory of the BSP, in our case ~/DistroKit. We can check if we are in the correct directory by checking if the symlinks selected_platformconfig and selected_ptxconfig can be found. If the symlinks don't exist, is PTXdist also able to look for them in the /configs-directory. Only if no information to platform and no PTXconfig can be found there either, the make license-report` command will fail. Assuming everything is fine, we then execute the ptxdist make license-report command.

~/DistroKit $ ptxdist make license-report

In my case I had to first install the packages graphviz, dot2tex and texlive-xetex. If all necessities are given, PTXdist will then collect all the licensing information found in the packages used in the BSP. These information are the variables <PKG>_LICENSE and <PKG>_LICENSE_FILES which can be found in each package definition, that is either used locally in the BSP or in the PTXdist installation directory rules/<pkg>.make. Finally it will respond with

) [375] (./license-report-tools.aux) )
(see the transcript file for additional information)
Output written on license-report-tools.pdf (375 pages).
Transcript written on license-report-tools.log.
finished target license-report-tools.pdf

The generated license report is stored in the sub-directory of the used platform in the directory report, so we change into that directory.

~/DistroKit $ cd platform-v7a/report/

We are only interested in the license-report.pdf for now (the report for the tools is not interesting for the ready-built BSP, in which the tools are not used anymore as they are only needed for building), so we look into it:

~/DistroKit/platform-v7a/report $ evince license-report.pdf

Please always pay attention to the disclaimer found on the first page:

!Attention!
This list of licenses is automatically generated and asserts no claims to
completeness or correctness. It is not legally binding, and comes without
warranty of any kind. We advise a manual counter-check before publication or
legal use.

Using the License Report

Let's take a peek at the package BusyBox:

The license report reports, that BusyBox is licensed under GPLv2-only. This means, that for being allowed to use BusyBox, the conditions of the GPLv2 must be met. Because of the -only appendix, it is not allowed to fulfill the conditions of a later version of the GPL instead. If one constantly meets the conditions of the GPLv2, the work for this package is already done.

Now we take a look at the package systemd:

License: GPL-2.0-or-later AND LGPL-2.1-only

The license report found components of systemd, which are licensed under GPLv2+, but also components, which are licensed under LGPLv2-only. If the desired usage of systemd is compliant with both licenses anyway, then our work is done already as well. This would be the desired state.

In the other case you have to check, if you can leave out the components licensed under the license that you don't want to or cannot comply with.

Analysing the respective component by hand

For example, have a look at the components of systemd used in your BSP:

~/DistroKit $ cd platform-v7a/build-target/systemd-243-51-gfab6f010ac6c

Use the tabulator key to complete the command after typing the first characters each.

In each component of systemd found in the systemd-directory of the relevant platform is a license header included, which describes, what license applies to the corresponding component. For example you could use your BSP without the systemd file .mkosi/mkosi.debian. Let's just assume, for the sake of explaining, that would be something you want to do. If you then leave out this file while creating the BSP, you do not need to meet the conditions of its license. Of course this would not change much regarding the license management, as the other .mkosi-files are licensed under LGPLv2 as well. To avoid the LGPL you would have to leave out all of the .mkosi components. And of course there is even more LGPL in systemd to find and - if desired - avoid. You may want to have a look:

~/DistroKit/platform-v7a/build-target/systemd-243-51-gfab6f010ac6c $ grep LGPL -R

This greps for LGPL recursively. Careful, grep is case sensitive. Because the letters LGPL are generally only used for the license identifier, you get a good overview over what components are licensed under some version of the LGPL. Or grep for a special version of the LGPL if you are only interested in that, e.g. try LGPL-v2. Be aware though, that not all programmers use the same syntax, e.g. LGPL v2.1 (without the hyphen connecting L with v) is mentioned in systemd's src/udev/ata_id/ata:id.c. For the plain LGPL this is, as expected, a lot. Only the last few findings:

test/create-sys-script.py:# SPDX-License-Identifier: LGPL-2.1+
sysctl.d/meson.build:# SPDX-License-Identifier: LGPL-2.1+
network/80-container-host0.network:#  SPDX-License-Identifier: LGPL-2.1+
network/meson.build:# SPDX-License-Identifier: LGPL-2.1+
network/99-default.link:#  SPDX-License-Identifier: LGPL-2.1+
network/80-container-ve.network:#  SPDX-License-Identifier: LGPL-2.1+
network/80-container-vz.network:#  SPDX-License-Identifier: LGPL-2.1+
sysusers.d/meson.build:# SPDX-License-Identifier: LGPL-2.1+
tmpfiles.d/meson.build:# SPDX-License-Identifier: LGPL-2.1+
tmpfiles.d/portables.conf:# SPDX-License-Identifier: LGPL-2.1+

Maybe you want to know the exact amount of findings, e.g. to calculate how many workhours you will need:

~/DistroKit/platform-v7a/build-target/systemd-243-51-gfab6f010ac6c $ grep LGPL -R | wc -l

In my case a whopping:

2162

Or you grep for the letters GPL, which also includes LGPL. If you want to grep only for the GPL, you have to to some RegExp magic:

grep '^GPL\|[^L]GPL' -R

Or grep for the license identifiers:

~/DistroKit/platform-v7a/build-target/systemd-243-51-gfab6f010ac6c $ grep License-Identifier -R

A wordcount gives out a total of 2224 (registered) license identifiers for the version of systemd used in my BSP, though some files might not include the letters License Identifier.

This work is done by the command ptxdist make license-report to give you a good overview of the licenses of the used components, including the license text of any known open source license. It is quite comfortable to have a nicely readable pdf-file, which tells you what program used in the BSP involves what licenses. It allows you to concentrate on problematic parts then. The license report relies on correct information though and cannot replace the individual license compliance done by a human.

If for an existing BSP you have to or want to avoid a certain license, you can use the license report as a starting point.