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

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

## gcc-8

project gcc-8 apertis:*:target April 17, 2019 fredo No GPL v3 The GCC source package is granted exception to be present in target repository component because it produces binary packages covered by different licensing terms: the compiler packages are released under the GPL-3 the libgcc runtime library is covered by the GCC Runtime Library Exceptions 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 apertis:*:target August 05, 2019 ritesh No GPL v3 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 apertis:*:target September 17, 2019 andrewsh No GPL v3 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.