How should I deal with GPL-licensed alpine os packages when using ASP .NET Core?

Question

I am using ASP .NET Core environment on alpine docker container (https://hub.docker.com/_/microsoft-dotnet-aspnet) and worried about license violations, as there are some GPL-licensed alpine OS packages in the same container.

/usr/share $ apk list | grep GPL
WARNING: Ignoring APKINDEX.2c4ac24e.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.40a3604f.tar.gz: No such file or directory
libfdisk-2.35.2-r0 x86_64 {util-linux} (GPL-2.0 GPL-2.0-or-later LGPL-2.0-or-later BSD Public-Domain) [installed]
less-551-r0 x86_64 {less} (GPL) [installed]
pango-1.44.7-r2 x86_64 {pango} (LGPL-2.1-or-later) [installed]
glib-dev-2.64.6-r0 x86_64 {glib} (LGPL-2.1-or-later) [installed]
blkid-2.35.2-r0 x86_64 {util-linux} (GPL-2.0 GPL-2.0-or-later LGPL-2.0-or-later BSD Public-Domain) [installed]
libcom_err-1.45.6-r0 x86_64 {e2fsprogs} (GPL-2.0-or-later AND LGPL-2.0-or-later AND BSD-3-Clause AND MIT) [installed]
mcookie-2.35.2-r0 x86_64 {util-linux} (GPL-2.0 GPL-2.0-or-later LGPL-2.0-or-later BSD Public-Domain) [installed]
libcap-ng-0.7.10-r1 x86_64 {libcap-ng} (GPL-2.0-or-later LGPL-2.1-or-later) [installed]
hexdump-2.35.2-r0 x86_64 {util-linux} (GPL-2.0 GPL-2.0-or-later LGPL-2.0-or-later BSD Public-Domain) [installed]

The official description shows dependent alpine OS packages which .NET requires (https://docs.microsoft.com/en-us/dotnet/core/install/linux-alpine#dependencies), and those libraries seems not to be copyleft (Non-GPL or GPL with GCC exception).

However, there are no descriptions that how .NET Core uses/links other alpine OS packages (except for the packages described in the official page) which may be distributed under GPL license.

As a lot of people using .NET Core, it should be safe, but I will be happy if I can find some evidences that show my original sources (on .NET Core) will not be affected by GPL-licensed OS packages.

Are not there any links between .NET Core and GPL-licensed alpine OS packages? Or are they regarded just as system-call?

Edited: I am planning to distribute the container to customers as my product.

Answer 1

All of the packages your mentioned are available under the LGPL, not just the GPL. The LGPL says that dynamic linking is fine. Since you're not compiling these binaries into your .NET app, there doesn't seem to be an issue with the licenses.

But when you distribute a container image, you're distributing all the software contained in that image. The GPL and LGPL say you're allowed to do that (c.f. “mere aggregation”), but you have to include a copy of the license, and have to make the source code of these GPL/LGPL-covered components available. How to make the source code available depends on the exact license.

Personally, I find thinking about container image licenses mindbogglingly complicated and, as a consequence, avoid distributing container images other than through purely internal private registries. Since you have customers who shall receive the image, you don't have this luxury. The Microsoft image you've mentioned is one of the few that takes their responsibilities here seriously. The README on Docker Hub links to this generic notice (permalink) which links to these instructions (permalink) that explain how to find the licenses for software in the image and how to get the source code. I recommend you essentially copy that approach, though it may be good to actually go through that process and keep a copy of the source code of all included software on file. If you have heightened compliance requirements, it may be a better idea to build your image completely from scratch, thus ensuring that you can precisely control what software is in the image.