Apertis the distribution is derived from Debian, from which it takes its philosophy, tools, workflows and packages. This robust, friendly and mature distribution provides a solid base on which to build an offering to suite the needs of very demanding markets such as the automotive industry.

One big difference between Apertis and Debian is that Apertis avoids certain licenses, in order to allow its target market to avoid legal issues. Several licenses are considered unsuitable in parts of Apertis, GPL-3 being the most important one. As a consequence of this, Apertis adopts a number of strategies to ensure packages meant to be installed on target devices comply with these license restrictions.

Several documents already cover specific cases or scenarios, which present the biggest licensing challenges:

• GPL-3-free replacements of coreutils
• License-compliant TLS stack for Apertis targets
• GPL-3-free replacements of GnuPG

Besides the topics covered by the above documents, Apertis implements different strategies to avoid such problems. In the cases where package license changed from GPL-2 to GPL-3, Apertis continues shipping the last license friendly version of the package, appending the suffix -gplv2 if it is needed to differentiate from the latest version.

For releases older than v2023dev1:

• findutils-gplv2
• readline5

For releases older than v2023dev0, also:

• cpio-gplv2
• diffutils-gplv2
• grep-gplv2
• gzip-gplv2
• sed-gplv2
• tar-gplv2

In other cases, where the license issues was not in the package itself, but in one of its dependencies, Apertis tries to avoid the problem by either using a different equivalent dependency or using the last suitably licensed version of it. In those cases where the functionality provided by the dependency is not really required, Apertis opts for removing or disabling such functionality and in that way dropping the dependency.

Impact

As discussed in the introduction, depending on the situation the impact of a delta is different. Based on the type of delta we can enumerate the following scenarios:

• Delta causes outdated package to be shipped
• Delta causes alternative package dependency to be used when compared to Debian
• Delta causes functionality to be disabled

Additionally the following aspects should be taken into account:

• Possibility of delta increment across time
• Number of packages in the dependency change

Delta causes outdated package to be shipped

Since Apertis derives from Debian, generally it ships the same version, but as mentioned, in some cases it keeps shipping a specific version of a package for the target component, while keeping the latest in the development suite.

In general the impact of this kind of delta is high, since Apertis carries an old version of a package without updates and security bugfixes. For this reason deltas under this category should be examined closely, specially taking into account the aspects previously mentioned.

Below is a list of packages that are frozen at a specific version previous to the license change and the packages that depend on them in the target component.

For releases older than v2023dev1:

• findutils-gplv2 (version 4.2.31)
• readline5 (version 5.2)
  • bluez
  • connman
  • lua5.2
  • lua5.3
  • mozjs78
  • python3.9
• libidn (version 0.6.14)

Additionally for releases older than v2023dev0:

• cpio-gplv2 (version 2.8)
  • initramfs-tools-core
• diffutils-gplv2 (version 2.8.1)
• grep-gplv2 (version 2.5.1a)
• gzip-gplv2 (version 1.3.12)
• sed-gplv2 (version 4.1.2)
• tar-gplv2 (version 1.17)
  • dpkg

From the list above it clear that readline5 cpio-gplv2 and tar-gplv2 are the package with higher impact in the system as they are used by other packages.

Delta causes alternative package dependency to be used

When it is possible to find an alternative to a package without license issues which provides similar functionality and it is present in Debian, the approach used is to switch to it, causing a delta. However, since the functionality is kept, the impact of the delta is considered lower than previous cases.

Delta causes functionality to be disabled

Under some circumstances, Apertis chooses to disable functionality to avoid a license issue. This approach is only valid if the functionality is not important, which requires an evaluation. Once it has been decided that the functionality is not a strong requirement a delta is introduced to disable it and drop dependencies which use unfriendly licenses. This generally only introduces a minor delta with respect to the package in Debian and is easy to maintain and port forward with updates in Debian.

Package summary for release v2023dev0 onwards

The table below shows the packages which have a license related delta with respect to Debian Bullseye. They are split into the following categories based on the scenarios described above:

• DF0: Disable functionality
• DF1: Disable minor functionality
• OP: Outdated package
• AP0: Use alternative outdated package
• AP1: Use alternative package

Required Action

We believe that the following actions are required to reduce the impact of these deltas. We have proposed different strategies depending on the impact of the delta, focusing on those which cause outdated packages to be shipped.

Other types of delta in general lead to reduced functionality which should be addressed only if it is required by a specific use case.

For the remaining cases, the impact is only related to drop functionality, which have little value for Apertis, in consequence we believe that the best approach is to keep the delta.

The strategies relies in find the best possible alternative, taking into account

• License: The replacement should meet Apertis license expectations in order to be consider as a valid one
• Debian support: The Debian support guarantees a community support on the package and a easy adoption in Apertis
• Compatibility: The replacement should provide the functionality required by Apertis on target images. Since the focus is on embedded devices, this is usually a small subset of the functionality provided by a fully featured tool, designed to be used by a user from a command line. For example, several alternative command line tools may use different arguments to provide functionality, for which existing users can be trivially altered or lack certain options, but in many cases these options will have little or no value when used in Apertis.

Delta causes outdated package to be shipped in releases older than v2023dev1

This type of delta is the most problematic and requires immediate action as these packages are currently not receiving security updates and thus present a security risk.

Package findutils-gplv2

Source: https://www.gnu.org/software/findutils/

Package findutils-gplv2 ships version 4.2.31 of GNU findutils a set of basic directory searching utilities. Alternatives to this package are:

• busybox find/xargs: BusyBox combines tiny versions of many common UNIX utilities into a single small executable, find and xargs among them.

  • License: GPLv2
  • Debian: Present
  • Apertis: Present
  • GNU compatibility: Low, only minimum set of feature

• uutils-findutils: A rust implementation of findutils

  • License: MIT License
  • Debian: Not present
  • Apertis: Not present
  • GNU compatibility: High in mind, however it is in early stage of development

Conclusion

The package uutils-findutils is being developed by the same community which develops uutil-coreutils, which has been chosen by Apertis as a replacement for coreutils as discussed in GPL-3-free replacements of coreutils.

• High GNU compatibility
• High community support
• High community impact
• Portability in mind
• Ongoing development
• Implemented in a modern memory safe language

Initial tests showed that additional functionality was required by some core packages (such as initramfs-tools), but recent changes have fixed these issues, making it a suitable replacement for findutils-gplv2 in target images despite remaining limitations (e.g. xargs functionality is still basic).

Package readline5

Source: https://tiswww.case.edu/php/chet/readline/rltop.html

The readline5 package ships version 5.2 of GNU readline. It provides a set of functions for use by applications that allow users to edit command lines as they are typed in. This same functionality can be provided by:

• libedit: This is an autotool- and libtoolized port of the NetBSD Editline library (libedit). This Berkeley-style licensed command line editor library provides generic line editing, history, and tokenization functions, similar to those found in GNU Readline.

  • License: BSD-3-Clause
  • Debian: Present
  • Apertis: Present (target)

• replxx: A small, portable GNU readline replacement for Linux, Windows and MacOS which is capable of handling UTF-8 characters. Unlike GNU readline, which is GPL, this library uses a BSD license and can be used in any kind of program.

  • License: BSD-3-Clause
  • Debian: Not present
  • Apertis: Not present

Conclusion

Since libedit is a mature package, based on NetBSD Editline library and is already present in Apertis, it is the primary candidate as a replacement. The approach in this case is to add support for it as alternative for readline in the packages which depend on it (bluez and connman).

Delta causes outdated package to be shipped in releases older than v2023dev0

This type of delta is the most problematic and requires immediate action as these packages are currently not receiving security updates and thus present a security risk. These issues were addressed in v2023dev0 with the stragy described below but they are still present in older releases.

Package tar-gplv2

Source: https://www.gnu.org/software/tar/

Package tar-gplv2 ships version 1.17 of GNU tar which provides the ability to create and manipulate tar archives. There are the following alternatives with the same functionality:

• libarchive: Multi-format archive and compression library, which includes the libarchive library, the bsdtar and bsdcpio command-line programs, full test suite, and documentation.

  • License: BSD-2-clause
  • Debian: Present
  • Apertis: Present (target)
  • GNU compatibility: Medium, basic set of features

• busybox tar: BusyBox combines tiny versions of many common UNIX utilities into a single small executable, tar among them.

  • License: GPLv2
  • Debian: Present
  • Apertis: Present
  • GNU compatibility: Low, only minimum set of features

• tar-rs: Rust library to manage TAR archives.

  • License: Apache
  • Debian: Not present
  • Apertis: Not present

Conclusion

The package libarchive is mature and already in Apertis. It provides bsdtar which gives a good basement to build a replacement for tar. The approach in this case is to test the use case of interest for target images, to install packages with dpkg.

Initial tests replacing tar with bsdtar or busybox tar and installing a package

$ sudo apt reinstall libc6
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libcolord2 libegl1-mesa libsys-cpuaffinity-perl libxdelta2 pbzip2 pixz xdelta xdelta3
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 2,831 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 https://repositories.apertis.org/apertis v2022dev2/target amd64 libc6 amd64 2.31-9apertis2bv2022dev2b1 [2,831 kB]
Fetched 2,831 kB in 3s (887 kB/s)
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76, <> line 1.)
debconf: falling back to frontend: Readline
Preconfiguring packages ...
-x -f - --warning=no-timestamp
-x -f -
bsdtar: Option --warning=no-timestamp is not supported
Usage:
  List:    bsdtar -tf <archive-filename>
  Extract: bsdtar -xf <archive-filename>
  Create:  bsdtar -cf <archive-filename> [filenames...]
  Help:    bsdtar --help
dpkg-deb: error: tar subprocess returned error exit status 1
dpkg: error processing archive /var/cache/apt/archives/libc6_2.31-9apertis2bv2022dev2b1_amd64.deb (--unpack):
 dpkg-deb --control subprocess returned error exit status 2
Errors were encountered while processing:
 /var/cache/apt/archives/libc6_2.31-9apertis2bv2022dev2b1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

After omitting the argument the process finish without issues.

As a result, with little effort the either bsdtar or busybox tar can be used as a valid replacement of tar.

Package cpio-gplv2

Source: https://www.gnu.org/software/cpio/

Package cpio-gplv2 ships version 2.8 of GNU cpio which is used to copies files into or out of a cpio or tar archive. The archive can be another file on the disk, a magnetic tape, or a pipe. This same functionality can be provided by:

• libarchive: Multi-format archive and compression library, which includes the libarchive library, the bsdtar and bsdcpio command-line programs, full test suite, and documentation.

  • License: BSD-2-clause
  • Debian: Present
  • Aperts: Present
  • GNU compatibility: Medium, basic set of features

• busybox cpio: BusyBox combines tiny versions of many common UNIX utilities into a single small executable, cpio among them.

  • License: GPLv2
  • Debian: Present
  • Apertis: Present
  • GNU compatibility: Low, only minimum set of feature

• cpio-rs: Rust library to manage CPIO archives.

  • License: MIT License
  • Debian: Not present
  • Apertis: Not present

Conclusion

The package libarchive is mature and already packaged in Apertis. This provides bsdcpio as a good base to build a replacement for cpio. In this case we need to test if it can successfully be used to build the initramfs used in Apertis.

Initial test, replacing cpio with bsdcpio and busybox cpio and running update-initramfs, was successful with no errors.

Package diffutils-gplv2

Source: https://www.gnu.org/software/diffutils/

Package diffutils-gplv2 ships version 2.8.1 of GNU diffutils, a set of programs to find differences between files. Similar functionality can be obtained by:

• busybox diff: BusyBox combines tiny versions of many common UNIX utilities into a single small executable, diff among them.

  • License: GPLv2
  • Debian: Present
  • Apertis: Present
  • GNU compatibility: Low, only minimum set of feature

• ccdiff: Perl script to achieve same functionality than diff but improving the visual output with colors.

  • License: Artistic-2.0
  • Debian: Present
  • Apertis: Not present
  • GNU compatibility: High
  • Runtime dependencies:
    • libalgorithm-diff-xs-perl (not in Apertis - Artistic)
    • libalgorithm-diff-perl (development - Artistic)
    • libscalar-list-utils-perl (development - Artistic)

• colordiff: The Perl script colordiff is a wrapper for diff and produces the same output but with pretty ‘syntax’ highlighting. Colour schemes can be customized.

• rust-diff: A rust library to compute text diffs.

Conclusion

The most suitable replacement found is busybox diff, since it provides the basic functionality required on target images. Initial tests shows that ccdiff has same functionality, very similar arguments and similar output (adds colors) to diff. However, since it is a perl script it requires additional dependencies to be installed.

Additionally it was found that diff is used on package install by dpkg but the process runs smoothly with busybox diff and also with ccdiff. The features of cmp, diff3 and sdiff are not supported, however there is not much value in target images.

Package grep-gplv2

Source: https://www.gnu.org/software/grep/

Package grep-gplv2 ships version 2.5.1a of GNU grep, which searches one or more input files for lines containing a match to a specified pattern. By default, grep outputs the matching lines.

• busybox grep: BusyBox combines tiny versions of many common UNIX utilities into a single small executable, grep among them.

  • License: GPLv2
  • Debian: Present
  • Apertis: Present
  • GNU compatibility: Low, only minimum set of feature

• ugrep: A grep alternative aim to be faster and with additional features.

  • License: BSD-3-Clause License
  • Debian: Present
  • Apertis: Not present
  • GNU compatibility: High
  • Runtime dependencies:
    • libbz2-1.0 (target)
    • libc6 (target)
    • libgcc-s1 (target)
    • liblz4-1 (target)
    • liblzma5 (target)
    • libpcre2-8-0 (target)
    • libstdc++6 (target)
    • libzstd1 (target)
    • zlib1g (target)

Conclusion

The goal to provide the required features for target images can be accomplish by using busybox grep without adding additional packages, making it the best option. Initial tests booting an image and installing packages don’t show any issues.

It is worth mentioning that in cases where higher compatibility with GNU is required, the ugrep package is already in Debian and all its dependencies are already in target, making it a viable alternative.

Package gzip-gplv2

Source: https://www.gnu.org/software/gzip/

• busybox gzip: BusyBox combines tiny versions of many common UNIX utilities into a single small executable, gzip among them.

  • License: GPLv2
  • Debian: Present
  • Apertis: Present
  • GNU compatibility: Low, only minimum set of feature

• flate2-rs: Rust library to manage ZIP archives.

  • License: Apache
  • Debian: Not present
  • Apertis: Not present

Conclusion

In order to replace gzip the best alternative is to used busybox gzip, which even with the its limitations it is enough for the requirements in target images

Package sed-gplv2

Source: https://www.gnu.org/software/sed/

Package sed-gplv2 ships version 4.1.2 of GNU sed a non-interactive command-line text editor.

• busybox sed: BusyBox combines tiny versions of many common UNIX utilities into a single small executable, sed among them.
  • License: GPLv2
  • Debian: Present
  • Apertis: Present
  • GNU compatibility: Medium, only minimum set of feature, but there are not much difference

Conclusion

In order to provide a replacement for sed-gplv2 the use of busybox sed is recommended since no other package depends on and the basic functionality provided by busybox sed covers most common use cases.

Initial tests

Besides of the partial tests done when analyzing each package, as part of the initial test the following actions have been done

• Boot target image with tools replaced
• Reinstall all the packages in target image

These rest were passed successfully which shows that the suggested approach is viable. Despite this promising results further testing should be conducted to assure a smooth transition.

General conclusions

For most of the packages there is a valid replacement in Debian Bullseye which should require little effort. However there are two that will require a development effort

• readline5
• findutils-gplv2