License exceptions

License exceptions for Apertis are listed below. Each exception must provide the following informations:

project The project name
component The repository components apertis:*:target
date The date at which the exception was added to this document
validator The name of the person who validated the exception
rule The rules that are ignored by this exception
reason A description of why the exception is granted and makes sense

gcc-8

project gcc-8
component apertis:*:target
date April 17, 2019
validator fredo
rule No GPL v3
reason

The GCC source package is granted exception to be present in target repository component because it produces binary packages covered by different licensing terms:

Programs compiled with GCC link to the libgcc library to implement some compiler intrinsics, which means that the libgcc must live in the apertis:*:target component since it is a direct runtime dependency of packages in the same component.

For this reason, an exception is granted to the gcc source package on the ground that:

  • code that is shipped on target devices (that is, libgcc) is covered by the GCC Runtime Library Exceptions
  • the pure GPL-3 code is not meant to be shipped in target devices

libtool

project libtool
component apertis:*:target
date August 05, 2019
validator ritesh
rule No GPL v3
reason libtool is granted exception to be present in target repository component
because all the source files are licensed under the GPLv2 with the exception
of build files, which are licensed under GPLv3.
These build files are used only to build the binary package and are not
GPLv3 violations for the built binary packages.

elfutils

project elfutils
component apertis:*:target
date September 17, 2019
validator andrewsh
rule No GPL v3
reason

elfutils is software dual-licensed as LGPL-3+ or GPL-2+, which means that any combined work using it has to be shipped under terms compatible with either of those two licenses. To avoid the effects of the GPL-3 provisions as required for the target repository, any combined work depending on any of the libraries provided by elfutils must be effectively licensed under the GPL-2 terms.

The following binary packages are linking against elfutils in way that no GPL-3 restrictions need to be applied as they only ship executables that produce combined works under the GPL-2:

  • linux-perf-4.19: GPL-2, does not ship libraries, development tool not meant to be shipped on products
  • linux-kbuild-4.19: GPL-2, does not ship libraries, development tool not meant to be shipped on products
  • bluez: GPL-2, does not ship libraries
  • libglib2.0-bin: LGPL-2.1, effectively combined to GPL-2, does not ship libraries

In addition, the mesa source package produces binary packages containing drivers that need to be linked to libelf and, in turn, get linked to graphical applications. This would impose LGPL-3+ restrictions on libelf unless the application and all the other linked libraries can be combined as a GPL-2 work. This is not an acceptable restriction, so the affected drivers have been disabled, and no binary package produced from the mesa source package links to any library shipped by elfutils.

The results of the search are