I’ve been reading some of the recent Kubernetes discussions about updating containers for core K8s components to standardize on distroless as their base image of choice.
That got me curious about Prometheus’ base image. I was surprised to see that it’s based on Busybox, since I’d heard that Busybox was a GPL-licensed project, and Prometheus is Apache licensed and sees widespread commercial use. I see that it’s prometheus’ own “fork” of Busybox, and that the fork declares an Apache license, but… that seems very strange and I wouldn’t think it’s possible to re-license something so trivially as that.
Before digging too much deeper on my own, I was curious to ask here about the history of this base image and understand how this Busybox base image isn’t GPL.
My actual original intent was that I was considering opening a Github issue to discuss changing the base image to distroless, but I wasn’t expecting to see that the base image is maintained by the prometheus project itself or that it’s got apparent GPL dependencies.
Curious if there’s an interesting story there and how that might interact with whether the Prometheus project would want to talk about changing up the base docker image.
I don’t think using GPL software in Docker containers is a problem per se, not least since you need a Linux kernel to run them on, so your environment will include GPL software anyway. Are you suggesting that packaging a Docker image constitutes linking?
We discussed the base image at the Dev Summit yesterday, and we will be offering distroless container images in parallel with the busybox based ones. The main reason for that is avoiding trouble with security issues in busybox itself (which don’t really affect running Prometheus as a server, but do trip up vulnerability scanners). Last time we changed base containers, we found that there are a lot of people who do depend on the specifics of the image, so we want to be careful and not change the default just yet.
I’m definitely not a lawyer, and I don’t think I have enough experience interpreting GPL scenarios to say anything definitive. I would have expected that because the Prometheus image is using the Busybox GPL bits, that would make the container image GPL software that happens to also contain an Apache-licensed component. I would expect it to be fine for folks to run the container image in most environments regardless of whether it’s GPL or Apache since, as you say, Linux is itself GPL. I was thinking about the case where someone is trying to build commercial software OSS software that pulls in the Prometheus docker image, as that seems like it would then be distributing GPL software.
That’s awesome, thanks for sharing that. And the note about folks depending on the specifics of the base container in subtle ways certainly seems reasonable.
The container image is like a normal Linux distribution packageing. IIRC, the packaging doesn’t have anything to do with the software itself.
Similar to how Debian can package multiple pieces of software under GPL, Apache, etc.
We’re not modifying busybox in any way, we take the upstream and package it.
That’s part of the trouble we’re trying to get around. The upstream busybox has TLS handling issues that require patches and re-building. We don’t want to deal with that, so we’re moving towards distroless to avoid the complication.
Nothing for or against the issue raised; I just noticed that the Kubernetes issue linked above has been bumped from at least three Kubernetes releases now - it’s apparently not terribly high priority to them?
