3

I'm working on a piece of open source software that's distributed as a binary in a Docker container. Thus, most of the users of the software not only do not interact with the source, they do not even interact with the binary. They simply run the container as a process and interact with it via HTTP calls. It's a text-protocol web service that the user runs on-premises.

My codebase, which is licensed under Apache 2, pulls in the source code of many libraries at build time. Those libraries each pull in the source code of many other libraries such that at build time there are literally more than 100 copyright notices on the disk of the person building the software (me).

My questions are the following:

  • Do I need to distribute those copyright notices with the built software?

If I do, the only convinient interface for a user to view them would be to include in the HTTP text-protocol a command GET /licenses or similar that would return the contents of 100+ licenses and copyright notices (which would incur a performance hit to the software if it were invoked).

  • For the purposes of distributing the licenses can I draw a distinction between libraries that I depend on directly and libraries that I depend on indirectly?
2

Direct vs. indirect dependency is irrelevant: you must comply with the licenses of all software that you distribute. Since Docker containers can include a surprising amount of software, this means distributing pre-built Docker images in proper compliance with all licenses can be rather difficult.

Docker images have the additional oddity that they can be viewed as half-archive (the file system image is not fundamentally different from a ZIP archive), half-executable (you can just run the container, without having to unpack its contents).

So where an archive file would usually put license information within the archive, this may not be sufficient for containers.

For executables, it is normal that licensing information is provided either by some built-in help system, or by external documentation. Your HTTP GET /licenses endpoint would be such a built-in system, but it would not be discoverable to users. Instead, I would suggest:

  • Provide all license notices in the container's documentation.
  • Wherever the pre-built image is offered for download, explain where the license information can be found.
  • Include the license information also in the container itself. Note in your documentation under which file path the licenses are stored.

This approach will satisfy attribution obligations both under the executable-like and archive-like aspects of the image. I do not think you would need to expose the licenses to users over a network.

Note that while the software you yourself write might be under the Apache 2 license, the image may also contain software under different licenses, such as a BusyBox userland which would be GPLv2. As you are responsible for satisfying the licenses of all the software in your image, you must also provide attribution for software in base layers of your image.

  • Ha, I almost forgot about base layers of the image. Does this mean if one utility in the "distro" that I choose for my base layer is GPLv2, that I have to "share alike" my application code? – OregonTrail Jan 29 at 19:17
  • "Provide all license notices in the container's documentation." So this means collect and aggregate all copyright notices (as required) for all software upon which the container depends? Considering deps for the base image this could be hundreds of notices. – OregonTrail Jan 29 at 19:19
  • 1
    FWIW, most practitioners consider distributing the license notices in the container image to be sufficient. They are accessible if anyone wants to retrieve them. – Josh Berkus Jan 29 at 19:25
  • 1
    @OregonTrail No, GPL software in a Docker container does not affect software you write that is installed in the same container. Here, Docker is no different from any other Linux-based system. As a general rule, no open source license will affect unrelated software (only derivative works). – amon Jan 29 at 19:29
  • 1
    (2) Some licenses like BSD refer to “materials provided with the distribution” as the location for notices, others like Apache-2 or GPLv2 require that you “give” recipients a copy of the license. That's a fairly active phrasing, which I don't think can be satisfied by making available the notices/licenses in some other place. Unlike e.g. MIT these licenses clearly intend notices to be visible by end users. – amon Jan 29 at 21:19

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.