There was a discussion regarding the legal and technical challenges surrounding open-source license compliance when distributing container images. The discussion highlighted the growing importance of understanding the layered structure of containers and the responsibilities associated with their distribution.
The Anatomy of a Container Image
Container images are essentially stacked layers. A typical image starts with a base layer containing fundamental system requirements like a C library, package manager, and shell. Subsequent layers add applications and libraries, and the top layer often involves customizations, including removing or modifying components. While a container’s runtime view might show a consolidated result, all underlying components remain present within it.
The Compliance Conundrum in Containers
The core challenge from a legal compliance standpoint is that it’s often unclear what software is actually distributed within a container. Most containers heavily rely on Free and Open Source Software (FOSS), and with FOSS, come license obligations. These obligations include providing license texts, legal notices, and sometimes even the source code and build instructions. Public container repositories frequently lack this crucial compliance information, yet the responsibility for fulfilling these obligations ultimately rests with the distributor, not necessarily the repository owner.
Who is the Distributor?
A key point emphasized was the legal interpretation of “distributor.” When a recipient executes a Containerfile (a script to assemble a container image), software is downloaded directly. The entity that “controls the distribution” is considered the distributor. This means that merely distributing a Containerfile can be legally equivalent to distributing software, triggering all associated license compliance duties.
OSADL’s Approach to Compliant Base Images
To address these complexities, the presentation introduced the concept of an OSADL Base Image. This is a minimal image built upon a Linux distribution, providing essential GNU tools, shell, C-lib, package manager, and networking functionalities. Crucially, it’s designed with license compliance in mind, including:
- Source code of all packages
- License texts and copyright notices
- Legal notices
OSSelot and FOSSology: Tools for Streamlined Compliance
The presentation highlighted the roles of OSSelot and FOSSology in achieving compliance:
- OSSelot is a publicly available, trusted database providing curated compliance information for frequently used FOSS components. It significantly reduces the time needed to “clear” a software package by allowing the reuse of pre-vetted licensing and copyright data.
- FOSSology is used in conjunction with OSSelot. The process involves:
- Using the OSSelot REST API to identify available OSSelot data for a container’s source packages.
- Uploading the OSSelot versions of packages into FOSSology, which then automatically clears the entire package.
- Uploading container source packages into FOSSology, running scanners, and reusing relevant OSSelot uploads to clear remaining files and copyrights.
Immediate vs. Delayed Source Code Disclosure
The OSADL Base Image offers two main approaches for source code disclosure:
- Immediate disclosure: All source code and legal information are included directly within the image. This approach simplifies access but can significantly increase the image size.
- Delayed disclosure: Only extracted compliance material, legal notices, and a written offer are included in the image. The full source packages with rebuild instructions are provided separately for later delivery. This method results in smaller container images but requires a separate mechanism for source code provision.
Both approaches ensure that instructions on how the base image is created and how it can be used are consistently provided.
As recommendation it was also mentioned that best practice would be FOSS compliance to be made layer by layer, meaning once you take for example OSADL Base Image then in order to make your own app you need to add few layers so its better to handle FOSS compliance after each layer instead of keep adding them until you reach the final product and handling this huge container with several layers in total in regards to FOSS compliance which would be harder and more time consuming.
