Exceptions to the Apertis license expectations are listed below. Each exception must provide the following information:

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

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.

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

gcc-10

project gcc-10
component apertis:*:target
date August 11, 2021
validator wlozano
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

gcc-12

project gcc-12
component apertis:*:target
date March 4, 2024
validator wlozano
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

libdb5.3

project db5.3
component apertis:*:target
date December 28, 2022
validator wlozano
rule Sleepycat license
reason

libdb5.3 uses Sleepycat License which requires to provide complete source code for the DB software and any accompanying software that uses the DB software. Based on the interpretation of uses in this context, different restrictions apply while linking and/or storing data in libdb.

Based on these facts, libdb5.3 package can be used by Open Source components although not recommended, but Private components should be aware of possible restrictions.

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.

nftables

project nftables
component apertis:*:target
date July 14, 2022
validator wlozano
rule No GPL v3
reason

nftables includes Bison-exception as described in Bison Exception which clearly states that is possible to create a lager work that contains part or all of the Bison parser skeleton and distribute that work under terms of your choice, so long as that work isn't itself a parser generator using the skeleton or a modified version thereof as a parser skeleton.

Based on these facts, the package is considered GPL-3 free.