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.
|
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.
|