LWN: Comments on "Containers and license compliance"

Containers and license compliance

grob — Tue, 09 Oct 2018 23:00:11 +0000

This is a subject close to my heart having just built a GPL-untainted base image over the course of the last 10 days or so after getting "the fear" - specifically of Java's GPL/Oracle proprietary license combo.

I documented my journey over here - https://medium.com/@robbie.gibbon/why-i-built-my-own-os-d.... So far as I know, my "gpl-free-base-image" is the only thing of its kind out there. Its built on mksh, the heirloom UNIX sys V core tools code drop (nearly 20 years old!), musl libc, python, and the usual line up of libraries (ncurses, openssl [so perhaps not 100% compliant with US cryptographic export rules at the moment], libffi, the antique Minix cawf and a few others).

My reasoning is that keeping control firmly in the user's hands and empowering them to extend the system with the GPL package versions that they want and from the distribution server of their choice is making every effort to comply with the ethos of the user-oriented freedoms aspects of the GPL. But it means that on every container initialisation, the user will likely need to bootstrap a download of glibc, openjdk, bash, GNU coretools etc. Of course depending on the needs of the application - for example a Node.JS application with node linking against Musl could probably run without any of that stuff needing to be downloaded. Anyway whilst really, really far from perfect, it does ensure that the end user retains governance, lineage and control over key components that are running in the container, and makes license compliance somewhat simpler for me as the distributor.

The best answer would be to reengineer the system to enable the user to substitute arbitrary interstitial slices of a container image, perhaps even only providing a metadata 'spec' of what services those slices need to provide.

I concluded that Docker Images as they stand are quite imperfect technology, there is simply no easy, automatic, idempotent and market ready way to build a both [[L][A]GPL in particular] license compliant and secure image with the technology as it stands today, and the traditional commercial Linux distributors, rather than stepping up to this challenge and solving these issues (perhaps even making some $$ in the process) - and in particular I'm thinking of Red Hat and SuSE - have stuck their collective heads in the sand (https://opensource.com/article/18/1/containers-gpl-and-co...) - whilst Canonical appears to have chosen to sidestep the issue and absolve themselves of any sin by making proprietary ISV sublicensing of Ubuntu nearly impossible (at least as I understand it).

Quite cool technology, but I just wish RH would step up and make an innovation here on the free software license compliance, lineage and security fronts; otherwise I think I may have to make one myself!! Of course there's always the Microsoft Windows Container runtime - well I guess they hit one out of the three big concerns...

Containers and license compliance

k8to — Tue, 08 May 2018 15:20:06 +0000

By "small containers" I was referring to minimal containers where there is not even a base image. Maybe a couple of executables and a few config files, or perhaps dumbinit and a single server program. There's a lot of benefit to not having a whole OS image, but this doesn't seem to be on the radar of most folks.

Containers and license compliance

justincormack — Sat, 05 May 2018 11:42:18 +0000

If you are logged in the licensing info and package info is available eg https://hub.docker.com/r/library/mysql/tags/8/

You can definitely make it difficult, but containers are also useful for building well designed build pipelines with metadata, but there is a big divergence between the dont cares.

If you have traceability issues with the official Docker images please open an issue at the relevant repo in https://github.com/docker-library - they should traceable from git commits there and package information should not be removed. The tarballs are provided by upstream and should also be identifiable.

Containers and license compliance

rahvin — Sat, 05 May 2018 00:41:34 +0000

It's pointed out in the article that a bunch of these containers pull other containers which pull other containers, etc.. In the end you have a container that's pulling a half dozen other containers and no one even knows what's installed in the container to the point that he provides an example where there are 600+ software packages installed in a single container.

The point of the article is about how hard it is to figure out if you are complying with the licenses in such a situation but the only thing I could think of is what a security nightmare that is because if your container image is pulling other container images you probably can't easily track down what's even installed even if the first container is well documented there is no guarantee all the reference containers are.

I know docker is popular but this is one the things that stops me every time I think of using a Docker container, they are way to black-box for me.

Containers and license compliance

civodul — Fri, 04 May 2018 16:06:52 +0000

With guix pack we provide a way to provision containers in a declarative and bit-reproducible fashion: for a given commit of Guix, guix pack -f docker python python-numpy (say) always produces the same Docker image, bit-for-bit. That makes it easy to create those images and provides provenance tracking—no need to walk a whole bunch of Dockerfiles and possibly volatile repos.

I think that makes the licensing situation safer; the bits in the image don't matter much once you have an automated and reproducible way to reconstruct them.

Containers and license compliance

MatyasSelmeci — Fri, 04 May 2018 14:52:48 +0000

Ah, I see the problem then.

Also, looks like you can only see build logs for "automated build" images so that's unfortunate.

Containers and license compliance

khim — Fri, 04 May 2018 01:18:10 +0000

DNS servers (well, bind specifically) were run in containers before containers existed! Yeah, it was called "chroot jail" back then, but most distributions supported that mode for DECADES!

Containers and license compliance

nishak — Fri, 04 May 2018 00:17:44 +0000

You could, but for images that are built on top of other images you would have to find the page hosting that image's build log and so on until you come to one that is build using FROM scratch. And if all that Dockerfile had was ADD rootfs.tar.gz and if the manifest for the build is not published then you're SOL.
Incidentally, I haven't found any build logs hosted on Dockerhub for official images. Where do I find those?

Containers and license compliance

jdulaney — Thu, 03 May 2018 18:41:39 +0000

I build my base image myself, and then build everything on top of that. I'm pretty sure I know what is going on with my containers.

Containers and license compliance

zdzichu — Thu, 03 May 2018 17:16:46 +0000

I would rather attribute this to awesome KubeCon+CloudNativeConf happening _right now_.

Containers and license compliance

zdzichu — Thu, 03 May 2018 17:15:07 +0000

Or using internal DNS for service discovery inside Kubernetes cluster, for that matter?

Containers and license compliance

MatyasSelmeci — Thu, 03 May 2018 15:17:28 +0000

Docker Hub keeps the build logs around for containers. Can't you inspect those to find out exactly what got installed?

Containers and license compliance

k8to — Thu, 03 May 2018 15:13:22 +0000

I think there's tension in that "small containers" have more potential benefits, but require a lot more up-front planning and work. So there's just a steady slide towards containers being entire OS images and fairly unknown behavior in how they're put together.

Containers and license compliance

flussence — Thu, 03 May 2018 13:29:06 +0000

At this point, these “Web Dev” Containers seem harder, more bloated, more of a liability, and all-around worse than simply running a distro in a traditional jail/openvz or even Xen setup.

Containers and license compliance

mageta — Thu, 03 May 2018 13:11:54 +0000

Huh? Sry, I don't get it. Whats wrong with running internet-facing services in containers for a bit of extra isolation?

Containers and license compliance

patrakov — Thu, 03 May 2018 11:29:22 +0000

I think there is some analogy here with the Java world where a similar compliance problem exists. The root is that people just don't care as long as it works.

Containers and license compliance

unixbhaskar — Thu, 03 May 2018 05:31:54 +0000

Off topic: two years back, when I was fiddling with containers for earning quick bucks ...I heard "container fanboy's", they were talking about running DNS server in containers!!!!! ...irk ...I was horrified ...it was scary ...I mean they have lost their mind completely.

Containers and license compliance

Eliot — Thu, 03 May 2018 01:15:18 +0000

Are XKCD and LWN cooperating this week? https://xkcd.com/1988