On Friday 04 February 2022 15:53:42 PM (+07:00), Mans Zigher wrote:

Hi,

A client of mine wants to have docker on it's product and they are
having secure boot enabled which prevents us from having any GPLv3
licensed code on the target.

Okay, wait, why does enabling secure-boot prevent including GPLv3 packages??
Ive never heard this before.

On Fri, Feb 4, 2022 at 3:53 AM Mans Zigher <mans.zigher@...> wrote:

Hi,

A client of mine wants to have docker on it's product and they are
having secure boot enabled which prevents us from having any GPLv3
licensed code on the target. We have successfully managed to add
docker to the target but we noticed that several packages have also
been added that is GPLv3

bash, gmp, gzip, libidn, libunistring, nettle, rsync, tar, wget

Those shouldn't be coming directly from the docker dependencies, but of
course packages that it depends on, may pull other dependencies, etc.

What branch are you using ?

If you look at docker.inc in the layer, it has our known dependencies:

DEPENDS = " \
go-cli \
go-pty \
go-context \
go-mux \
go-patricia \
go-logrus \
go-fsnotify \
go-dbus \
go-capability \
go-systemd \
btrfs-tools \
sqlite3 \
go-distribution \
compose-file \
go-connections \
notary \
grpc-go \
libtool-native \
libtool \
"

DEPENDS:append:class-target = " lvm2"
RDEPENDS:${PN} = "util-linux util-linux-unshare iptables \
${@bb.utils.contains('DISTRO_FEATURES', 'aufs',
'aufs-util', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'systemd',
'', 'cgroup-lite', d)} \
bridge-utils \
ca-certificates \
"
RDEPENDS:${PN} += "virtual-containerd virtual-runc"

1. Does docker have a strict dependency to GPLv3 code?

There may be ways to avoid some GPLv3 dependencies, but it isn't
something that we've actively explored or tested. So it would be
an effort that needs experimentation.

2. For some reason that I don't understand, docker seems to pull in
LXC which in turn will pull in many of the packages. Is Docker using
LXC? I thought docker was replacing LXC doing the same thing as LXC.
3. Do you have any suggestions on how to have container support and
not pull in GPLv3 code? Is Docker moby an alternative?

It depends on how you are installing docker to your image. In the latest
branches, it doesn't have a dependency on lxc. There are some package
groups and kernel configurations that are shared, but you don't have to
install using those packagegroups if they are pulling in elements that
you don't want or need.

Bruce

BR
Måns Zigher

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Hi,

On Fri, Feb 04, 2022 at 04:03:52PM +0100, Joakim Roubert wrote:

On 2022-02-04 15:30, Mans Zigher wrote:

with our current understanding our customer cannot comply with GPLv3
so we have to avoid it at all cost.

I think this is a situation where

https://layers.openembedded.org/layerindex/branch/master/layer/meta-gplv2/

might come in handy, together with something like

PREFERRED_VERSION_bash ?= "3.2.%"

in the local.conf (or similar suitable configuration place).

While this would work, I can't recommend using meta-gplv2 as it contains unmaintained
SW versions.

Just configure the build to avoid GPLv3 via distro config, e.g.

INCOMPATIBLE_LICENSE_append += " GPLv3 GPLv3+ LGPLv3 LGPLv3+"

and configure SW components to build without GPLv3 dependencies.
lxc for examples compiles just fine without rsync and bash.

Additionally a lot of GPLv3 recipes can be enabled to build but be forbidden
images images, e.g. in distro config:

WHITELIST_GPL-3.0 += "bash"
PACKAGE_EXCLUDE += "bash-ptest bash-dbg bash-staticdev bash-dev bash-doc bash-locale bashbug bash"

Some refactoring of SW architecture may be needed to remove any dependencies to GPLv3
licensed SW. For development and testing GPLv3 components can often be used.

Cheers,

-Mikko