Hello all,
the latest source code scan highlighted that the version of Nettle used on Apertis target images for the v2020 and v2021 releases is already subject to the relicensing to LGPL-3 or GPL-2 and it is no longer LGPL- 2.1 licensed as the metadata from the original Debian package sources indicated.
This means that any program using libnettle, and by extension libraries like libgnutls, glib-networking and libsoup, has to be licensed under the terms of the GPL-2 or the terms of the LGPL-3 license should be applied to libnettle.
This goes against the Apertis licensing expectations[1] therefore we are now working on a fix.
The v2022 release channel is not affected thanks to the rework of the TLS stack usage[2] done in that channel. The recent documentation work helped raising the awareness of the issue, identifying its impact and the possible ways to address it.
We currently plan to backport the changes from v2022 to v2021, and even v2020. Usage of libnettle and its reverse dependencies like libgnutls will still be subject to the LGPL-3 or GPL-2 dual-license, but libraries like glib-networking and libsoup will be moved to the OpenSSL backend to avoid the issue. Check the document about the TLS stack licensing[2] for further details.
In case of any doubt, we are available for any inquiry and clarification about the impact of the issue.
Thank you!
[1] https://www.apertis.org/policies/license-expectations/ [2] https://www.apertis.org/concepts/tls-stack/
Hi all,
On 10/12/21 19:45, Emanuele Aina wrote:
Hello all,
the latest source code scan highlighted that the version of Nettle used on Apertis target images for the v2020 and v2021 releases is already subject to the relicensing to LGPL-3 or GPL-2 and it is no longer LGPL- 2.1 licensed as the metadata from the original Debian package sources indicated.
This means that any program using libnettle, and by extension libraries like libgnutls, glib-networking and libsoup, has to be licensed under the terms of the GPL-2 or the terms of the LGPL-3 license should be applied to libnettle.
This goes against the Apertis licensing expectations[1] therefore we are now working on a fix.
The v2022 release channel is not affected thanks to the rework of the TLS stack usage[2] done in that channel. The recent documentation work helped raising the awareness of the issue, identifying its impact and the possible ways to address it.
We currently plan to backport the changes from v2022 to v2021, and even v2020. Usage of libnettle and its reverse dependencies like libgnutls will still be subject to the LGPL-3 or GPL-2 dual-license, but libraries like glib-networking and libsoup will be moved to the OpenSSL backend to avoid the issue. Check the document about the TLS stack licensing[2] for further details.
In case of any doubt, we are available for any inquiry and clarification about the impact of the issue.
Thank you!
[1]https://www.apertis.org/policies/license-expectations/ [2]https://www.apertis.org/concepts/tls-stack/
The plan announced to backport the changes for the TLS stack [1] from v2022 to v2021 and v2020 has already been executed and new versions of the affected packages are already available for testing at v2021-updates and v2020-updates.
Under the scope of these change glib-networking was updated to 2.66 to properly support OpenSSL backend.
We encourage people to test the new packages in the v2020-updates and v2021-updates repositories. They will be folded in the main v2020 and v2021 as part of publishing the next official releases, v2020.7 [2] and v2021.3 [3].
In case of any doubt, we are available for any inquiry and clarification about the impact of the issue.
Thank you!
[1] https://www.apertis.org/concepts/tls-stack/ [2] https://www.apertis.org/release/v2020.7/release_schedule/ [3] https://www.apertis.org/release/v2021.3/release_schedule/
-
Emanuele Aina -
Walter Lozano