Containers — which are, essentially, executable, standalone packages with all files (libraries, system settings, dependencies, etc) necessary for the software to run — are everywhere in modern application development. A recent Cloud Native Computing Foundation (CNCF) survey revealed that a staggering 84% of organizations use containers in production — up from only 23% a few years ago.
Like much of today’s technological landscape, the container ecosystem is largely fueled by open source components. These include:
- Registries like Docker Hub that host thousands upon thousands of open source container images
- Container orchestration platforms (such as Kubernetes)
- Recipe Files (Such as Dockerfiles)
- Container run times (like Containerd)
However, as is the case with all things OSS, using open source components in the container environment carries certain license compliance obligations. Such is the nature of open source — creators provide innovative new technologies free of charge, with the caveat that users abide by certain requirements that govern the licensed code/files.
In this blog, we’ll explore which parts of the open source container ecosystem carry compliance obligations, how to deal with components licensed under GPL v2 (or similar strong copyleft licenses), best practices for license compliance, and more.
Container Images and Compliance Considerations
As discussed, the container ecosystem is fueled by open source. But, the primary concerns for license compliance purposes are container images. This is because license compliance obligations are triggered by distribution of the code, and the container image is generally the only part of the container ecosystem that meets this criterion.
Before we dive into container images, though, a quick word on container recipe files (which are text files that essentially provide instructions on how the container image should be built). It’s probably rare that you’ll encounter a scenario where you'll actually be distributing a recipe file, which is why we won’t be discussing them much in this blog. But if you do: Keep in mind that recipe files are sometimes covered by different licenses than the images that are built from them. For example, a Dockerfile might be licensed under, say, MIT, but it may describe images licensed under Apache 2.0 and ISC.
Now, back to the main focus of our post, container images. Container images play an integral role in the container environment — they are the distributed package containing the necessary software to run. For context, a container is a running instance of a container image, of which there can be multiple at any given time.
The term container image is also used to describe individual software files that comprise a fully built container image. Oftentimes, development teams will use open source container images that are available on public registries like Docker Hub. A fully built container image might contain an open source base image (an OS like Ubuntu), another open source image (like Postgres SQL), another like Logstash, and so on.
If teams build and distribute containers with images that fall under multiple licenses, they’ll need to comply with the strongest copyleft of the bunch. (I.e. if one image layer is under the MIT License and another GPL v3, you’ll need to comply with GPL v3.)
Another important note about container images and license compliance is that in fully built and shipped container images, certain layers may be obscured. However, you’re still responsible for complying with licensing requirements for each layer — even those that aren’t visible during run-time. Given the sheer volume of different licenses and different files (pulled from different sources), this can be quite challenging. (We’ll discuss strategies to address this concern later in the blog.)
Thank you for submitting details. Your email address is added to our subscription list.
Open source licensing requirements take effect upon distribution of the software. In other words, there’s no need to worry about source code disclosure if you use a GPL-licensed component to build a for-internal-use-only development tool. In the context of containers, distribution becomes relevant when you are allowing others to download your container images. For example, any images on Docker Hub are being distributed and therefore must comply with their respective license requirements.
Distribution of a fully built container image is quite similar to distribution of any other piece of software. A built container image is distributed in binary form, and the party doing the distributing must comply with licensing requirements of all the packages and software within the container image. This can be difficult since containers often contain hundreds of packages, all of which require compliance.
Containers and Copyleft Licenses
Open source licenses come in two flavors: permissive and copyleft. Permissive licenses generally allow users of the licensed code a great deal of flexibility (as long as they provide proper attribution), while copyleft licenses carry more stringent requirements. Some copyleft licenses even require the disclosure of source code when a user modifies (and then distributes) the copyleft-licensed code.
However, meeting source code disclosure requirements is easier said than done in a container environment. This is the case for several reasons:
- Image layers can be composed at different times and source code may have changed
- Gathering source code needs to be done for all layers, which can be challenging
- The exact specifications of a built container image depend on how the image is configured.
The good news here is that a container scanning tool like FOSSA can go a long way toward helping teams get an accurate understanding of source code and involved licenses for all image layers. We’ll discuss this in more detail in the following sections.
Note: When it comes to fulfilling compliance obligations in a container environment, the required information (notice files, copyright files, changelogs, etc.) can be embedded in the container image or disclosed to the end-user through normal attribution pages that may already be set up.
How to Comply with Container Licensing Obligations
Open source license compliance — in the container environment and beyond — starts with a comprehensive understanding of the licenses involved. But as we mentioned earlier, it can be tricky to uncover licenses for each layer of a container image because these layers are obscured during run-time.
That’s why automated container scanning tools make such a difference. These tools surface all licenses for all layers of a given image.
It’s also important to pay attention to the timing of your scans. If you wait until the latter parts of the SDLC to conduct license scans (and uncover, say, a GPL-licensed component), you might be forced to undo and rebuild a large portion of your container artifact. That’s why it’s recommended to:
- Scan images as soon as possible, especially base images
- Scan first and then add later before they are added to a container
- Also, scan fully built images as part of CI/CD before they get pushed to production
Other Strategies for Container License Compliance
- For starters, consider bringing any licensing policies you’ve applied to other areas of your organization to the container environment. This may include a default-deny posture for strong copyleft licenses and perhaps a “yellow” flag for weak copyleft licenses like the Mozilla Public License 2.0.
- It may make sense to build a pre-approved, private registry of base images that are all covered by your organization's policies so you know won’t pose any compliance problems down the line.
- Using a tool like FOSSA — that offers container image license scanning and management — goes a long way toward helping organizations comply with container compliance requirements.
FOSSA works by:
- Providing an audit-grade inventory of open source license types, even in image layers that are hidden during run-time
- Surfacing detailed metadata information, including license text, copyright info, and compliance obligations
- Applying built-in, customizable OSS policies across company, product, and team. This includes the ability to flag or block policy violations natively via existing engineering workflows
Learn more about how FOSSA can help you manage license compliance in the container environment by getting in touch with one of our experts today.
Note: We on the FOSSA Editorial Team are not lawyers, so if you are seeking legal advice, we suggest you speak directly to a legal team that specializes in open source licensing.