Meta-gpl2 layer replacement

From Yocto Project
Revision as of 12:57, 25 July 2024 by Rpurdie (talk | contribs) (Created page with "== Options for meta-gpl2 layer replacement == meta-gpl2 was created to supply recipe metadata for GPL-2.0 version of OSS components/recipes which have migrated to use GPL-3.0 family of license. Therefore the versions for these components were frozen in time ( circa 2007 ), these components were still receiving security fixes and sundry other minor fixes while they were part of long term supported ( LTS ) binary distributions e.g. ubuntu and CentOS and Debian. Therefore...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Options for meta-gpl2 layer replacement

meta-gpl2 was created to supply recipe metadata for GPL-2.0 version of OSS components/recipes which have migrated to use GPL-3.0 family of license. Therefore the versions for these components were frozen in time ( circa 2007 ), these components were still receiving security fixes and sundry other minor fixes while they were part of long term supported ( LTS ) binary distributions e.g. ubuntu and CentOS and Debian. Therefore keeping them in healthy state was still possible until these LTS releases of distributions went EOL, which meant that these components stopped receiving any updates and hence became hard to maintain over time

New compiler versions would find new bugs ( build time issues ) which are otherwise fixed in the regular version, the backports are no longer straightforward and have license issues anyway. No security fixes being applied anymore Consistently, requiring platform porting e.g. mingw

Therefore it is not recommended to use meta-gpl2 anymore as it is quite problematic. It also sends out a bad message to your own userbase as it implies you are disregarding security issues and as such can cause reputation damage. Whilst it has not been recommended for many years, it has been completely dropped by the Yocto Project after the kirkstone release so the most recent LTS (scarthgap) does not support it.

What's the way out?

  • Move to use a maintained version of the components if possible, which could be allowed per legal policies of your company, please discuss with them.
  • Find alternative implementations for similar functionality e.g. readline vs libedit, however this might need API adjustments. Some of coreutils components can be replaced with busybox applets
  • Change recipes to use PACKAGECONFIGs for such functionality which can safely avoid linking to GPL-3.0 code.
  • Selectively remove components from images which have such dependencies. E.g. see meta/lib/oeqa/selftest/cases/incompatible_lic.py
  • Switch to checking images for problematic content rather than disabling entire recipes globally. Our license markup of individual packages should be accurate.

Start with marking images with below restrictions

INCOMPATIBLE_LICENSE:pn-core-image-full-cmdline = "GPL-3.0 LGPL-3.0"

And remove dependencies if not needed or find replacements if available.

For running ptests, lot of recipes need bash, that was the reason ptests were explicitly removed by meta-gpl2, therefore it might be not easy to replace bash with another shell e.g. dash or tcsh However, it's limited to testing and production builds can still resort to avoiding bash shell from target images.

See following commit for an example: https://git.yoctoproject.org/poky/commit/?id=ebee9854d735bf6321020e791ca84389dc91834b

TLS

Lot of packages need a TLS dependency and there are multiple providers for TLS implementation, however, some packages use gnutls as default backend and hence a dependency. Some packages Do provide an option to use other implementations e.g. openssl provided TLS or NSS, therefore such packages should be made to provide this choice via PACKAGECONFIG. The packageconfigs can Then be set to no-defaults via distributions. A good example

https://git.yoctoproject.org/poky/tree/meta/recipes-extended/wget/wget.inc#n30

Code Generator Tools

Tools like gettext, bison, m4, patch are used during build mostly. Assessing how they are used in your case can pave a way forward to use their currently maintained versions. The usecases can be discussed with the policy teams of your company based upon how they are used.

Multiple providers

Packages like libiconv provide components that are already provided by glibc or musl C library, however, they maybe needed on supporting platforms like mingw and Yocto project supports Mingw for Build and SDK host therefore it will be used in host and not shipped on target software. Therefore the scope of such a package is reduced and is applicable to specific usecases alone.

Unchanged License

Certain packages e.g. shared-mime-info are still under GPL-2.0 license, the reason to house an older version in meta-gpl2 was to support other old packages.

Work so far:

Created a global policy file: 

https://git.yoctoproject.org/poky/tree/meta/conf/distro/include/no-gplv3.inc

as distro config metadata could help the community to start with a known set of packages and packageconfig and other metadata tweaks. This file can be included in global config metadata and distribution built on top of it.

Future work needed:

  • Find scalable replacement for bash so ptest can be enabled
  • readline being gpl3, editline as alternative?
  • Gdbserver is GPLv3 causing issues for debug images, lldb-server is an alternative
  • Gnupg is used by package managers e.g. dnf, using alternative package manager or using alternative GPG implementation e.g. minisign/libsodium, https://gitlab.com/sequoia-pgp/sequoia ?
  • Elfutils could be replaced by LLVM tools
  • Document best practices once identified in project manuals
  • Distro policy to govern TLS preferences?
Retrieved from "https://wiki.yoctoproject.org/wiki/index.php?title=Meta-gpl2_layer_replacement&oldid=86405"