License Compliance of Docker Containers

[Karsten Klein]

Hi there,

I hope I am addressing the right audience here. Otherwise, forgive me and please support me in finding the appropriate contact.

We are currently investigating the options using the Prometheus Docker container within software distributions and diverse production scenarios.

We found in particular that there is no complete information available regarding all covered software contained the current docker containers that can be publicly pulled from https://hub.docker.com/r/prom/prometheus/. Specifically, the containers that we analysed do not include any license information covering operating system level packages (such as busybox; see below).

We are wondering whether there is a complete documentation (compliance documentation, bill of materials) available. The LICENSE and NOTICE file are rather incomplete in this (and other) aspects.

For example:

• The container covers busybox, which is licensed under GNU General Public License Version 2.0 (GPL-2.0).
• The GPL-2.0 license requires to include the license text in the distribution and to make source code available to the recipient of the software.
• The container / project does not make these aspects transparent and does not deal with the license obligations.
• The container / project does not include enough information to derive the covered software (unique identification, version, license details)

Perhaps we can get in touch to clarify these questions. We are happy to dig into the details with some guidance.

Regards and a good start into 2021...Stay healthy,

Karsten 

[Tobias Schmidt]

Hey Karsten,

Thank you for bringing this topic to our attention!

Your email spawned some discussions in other channels, without any conclusions yet. There is a long-standing issue about our NOTICE files which doesn't only affect Docker containers: https://github.com/prometheus/prometheus/issues/3399. As the project we'd love to drop custom NOTICE files altogether to avoid having to deal with regular updates. We're not sure yet whether that's possible and have reached out to various parties again.

If anyone can provide clear requirements, guidelines, or examples from other major projects on how to handle license and notice files in container images / packaged tarballs, that would be very helpful.

Best,

Tobias

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/b691e8e6-a7e1-493e-aa65-8a5062477faen%40googlegroups.com.

[Karsten Klein]

Hi Tobias,

 

we once nailed down the requirements for documenting software for distribution (with or without hardware):

 

https://github.com/org-metaeffekt/metaeffekt-asset-annex-requirements

 

In my eyes the document is still very valid and defines on a generic and general level how a software asset (container, tar ball, …) needs to be covered. Depending on the projects’ context you can decide on which requirements you put your priorities. From a consumer/operator perspective all listed requirements are at least relevant.

 

We further took a closer look on BusyBox (as this is the core of the Prometheus containers). Version 1.33 source code covers the following licenses (in no particular but alphabetic order):

• Beerware License
• Bison Exception 2.0
• BSD 3-Clause License
• BSD 3-Clause License (UC)
• BSD 4-Clause License
• BSD alike
• BSD Simplified (Intel)
• GNU General Public License 2.0
• GNU General Public License 2.0 (or any later version)
• GNU Lesser General Public License 2.1 (or any later version)
• MIT License
• Netcat Permission Statement
• NTP License
• Permission Terms (no warranty; no liability)
• Public Domain
• RSA MD License
• Sash Notice
• Unlicense

 

(Additional licenses in examples and tests are not listed.)

 

Please note that the information above was automatically extracted by our license scanning tool. The list may be neither accurate nor complete. Our scanner already produced several hints regarding unmatched licenses. We need to further dig into the details here to match and identify those.

 

So far, the above list contains “open source licenses”. Not all of them OSI-approved, but at least commonly used licenses without commercial fee or restrictions to commercial use (as far as we can see; no legal advice!). However, the resulting obligations should be addressed within or complementary to the container.

 

In addition to BusyBox, the container is based on a Debian distribution with additional packages installed (certificates, gcc, netbase). See https://github.com/prometheus/busybox/blob/master/glibc/Dockerfile. The licenses covered on Debian side (used core packages if any, plus the extra installed packages) need also to be considered.

 

We plan to aggregate further information from a compliance perspective in the course of our customer projects that intend to ship/operate Prometheus containers. We will check in the context of the projects how much of the results we are able to share here in the group.

 

Stay tuned…

 

Karsten

[Tim Hawkins]

There are a number of license compliance scanners around such as term, which could be added to the build pipeline for the containers. 

This tool would provide a listing of the licenses used by the components added in each layer of the container build. 

https://github.com/tern-tools/tern

--

You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/AM6PR0302MB3335FF9090B91832130CBE8AA2A60%40AM6PR0302MB3335.eurprd03.prod.outlook.com.

[Karsten Klein]

Hi Tim,

 

it is not that easy…

 

Since the Prometheus Containers – as they are currently built – contain no licensing metadata as such, you cannot immediately expect Tern to report licenses. You need appropriate data and tool integration into Tern to achieve this.

 

For the future you may want to make a different choice regarding the base images you build on. In that case Tern – like other tools in that space, (also checkout https://github.com/org-metaeffekt/metaeffekt-container-annex for a very simplistic CI integration based on Apache Maven and Docker) – is able to produce results. Whether such results conform to enterprise level compliance requirements is however a different question. For our (speaking as metaeffekt here) part, we at least know that we can push the resulting documentation towards such conformance. This is what we do as daily business based on our open source build plugins.

 

For a comparison of metadata quality checkout https://github.com/org-metaeffekt/metaeffekt-container-annex/blob/master/study/container-study.md. The data there is roughly one year old, but still very valid. I attached an openSUSE example; unfortunately, it is not quite self-explanatory. All license information in this example is taken from container image itself. It can be regarded as starting point for a detailed documentation.

 

Regards,

Karsten