Docker open source software and open source licenses FOSS compliance / open source compliance

Do I only have to observe the license conditions for the Docker image?

No. If Docker images or other images of container virtualization solutions are used, the license conditions for all software components must be observed. Due to the additional "layer" provided by Docker or the other container solution, the license conditions for the software contained in the image must now be observed, as well as the license conditions for the software at the container level. At the container level, for example, the license conditions for the build scripts must be observed.

Can I rely on information on portals such as Docker Hub or Git Hub?

Portals such as Docker Hub, Git Hub and other portals often contain information on the relevant license conditions. This information is generally not binding. If incorrect information is provided there, a license violation still occurs. The information on such portals can therefore provide initial guidance, e.g. when searching for suitable images. However, the licensing information should be checked before the final use of the image.

What to do if license information for the Docker image is missing?

It can happen that license terms for software at the container solution level, such as Docker, do not contain any license information. What then applies?

Software is protected by copyright (at least in the EU). The software author is entitled to the relevant rights of use. If you are not granted rights of use via license conditions, copyright-relevant actions such as reproductions may not be carried out. If there are no license conditions, you are therefore not permitted to use the Docker image.

However, such missing license conditions are usually an oversight. It may be worth contacting the authors to resolve the situation. Build scripts for Docker images are regularly placed under the Apache License 2.0. In addition, special regulations may arise from the general terms and conditions of the platform used. In some cases, there are provisions to the effect that certain rights of use are automatically granted when content is uploaded without separate license terms being specified.

Do license terms for unused software also have to be observed?

Docker images often contain a large number of different software components. You probably do not need all of these software components. Do you also have to comply with the license conditions for these components?

Yes, because such software components are also used in a copyright-relevant manner, e.g. by duplicating the image together with the software that is not technically required.

How far-reaching are the information obligations?

There are numerous open source licenses. The vast majority of open source licenses contain - in addition to other requirements - the condition that certain information obligations relating to the respective license type must be observed. These information obligations must also be complied with in the context of Docker images and other container virtualization solutions with regard to all "layers".

However, not all information must necessarily be provided at a specific point. The various license conditions also contain different requirements in some cases. For example, in the program ultimately implemented via the Docker image or other image, the license conditions applicable at least to this program should be observed and the corresponding information provided.

Can software be used in Docker images at all?

The question of whether certain software may be used in Docker images is often overlooked in practice and remains unchecked. Ultimately, the license conditions of each individual piece of software used in the Docker image or other image must be checked to answer this question. Each software author can set separate requirements in this regard. For the most part, however, there should be hardly any problems that prevent use in practice, at least for the typical open source license conditions.

Can an infection occur with regard to the entire container?

Some open source license conditions contain the so-called copyleft effect, which leads to an "infection" of your own or other software. The General Public License (GPL) is probably the best-known license type of this kind. If a GPL software component is used in too close a dependency with other software, e.g. the additional software programmed by the user, this other software must also be licensed under the GPL, e.g. the source code must be made available to third parties free of charge.

In the case of proprietary applications, it is generally important to avoid this effect at all costs, as investments in the company's own software and company know-how can be lost in this way. The problem initially arises directly with regard to the company's own software, which may incorporate GPL software.

However, it is questionable whether the infection can also extend to the entire Docker image or other image if it contains a GPL component. This is a complex question that must be examined in detail, taking into account the software components contained in the Docker image or other image. For example, the Linux kernel is indeed under the GPL, but with a special exception for user space applications. The extent to which this exception applies to the specific Docker image must then be examined.

First of all, however, it must be examined whether the mere aggregation of software components under a copyleft license, such as the GPL, creates such a close dependency that the copyleft effect and thus an "infection" occurs. This can be denied with good reason, as the mere aggregation in a Docker image or other image could be comparable to the mere distribution of the copyleft component in a Linux distribution. However, there is still no established case law in this respect. The case law to date also tends to raise concerns regarding the above comparison. For example, the Regional Court of Berlin ruled that the firmware of a router constitutes a collective work under copyright law pursuant to Section 4 (1) UrhG and that this collective work triggers the GPL copyleft effect (Regional Court of Berlin, judgment of November 8, 2011, case no. 16 O 255/10 - "Surfsitter").

Conclusion

The use of Docker images or other container virtualization solutions is a modern technology that enables "continuous deployment" and "continuous delivery". In future, it will no longer be possible to do without this technology, especially on intensively used systems that do not allow any downtime. However, the use of this additional software layer does not lead to a simplification of licensing issues with regard to open source software, but rather adds an additional layer of complexity. By adding another "layer" through the additional use of orchestration solutions such as Kubernetes (K8s), the level of complexity is increased even further.

Ultimately, these issues will generally not be an obstacle to their use in practice. However, they must not be overlooked and must not be left without a legal and factual structure. Otherwise, there is a risk of otherwise possible claims, e.g. for injunctive relief and damages or at least negative marketing due to alleged license infringements.