3

There is an MIT-licensed project, FooSoftware, which I have done some work to make work in a Docker container [1]. I would like to publish that work so that others can use FooSoftware in Docker without doing the work to adapt it themselves.

This would involve publishing a project including a Dockerfile and some simple associated scripts, for example through GitHub. It may also involve making the built image available, for example via Docker Hub. The Docker project does not itself provide the source code to FooSoftware, though it fetches it from the upstream repository when building, ie when a command such as docker build is issued.

However, I am slightly unclear as to what precisely to include in the LICENSE file. The original project lists contributors, eg:

(C)opyright 2018-2019 Joe Bloggs <jbloggs at example dot org>
(C)opyright 2015-2016 Tracey Beaker <tbeaker at example dot org>
(C)opyright 2005-2012 A Dent <arthurd at example dot org>

I am unsure whether to include these in the LICENSE file I create. On the one hand, I want to properly credit the upstream authors and do not want to make it seem as if I am claiming credit for the whole project. On the other hand, I do not want to make upstream responsible for downstream Docker adaptations.

Given that the MIT license includes the clause:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

I believe including the copyright notices is required, even though the Docker project does not directly include the upstream project's code. Should I add my name to the top, and include previous names below?

I would like to clear on this before making a FOSS faux pas!


1: In the real case this is indeed dealing with the MIT license, but if the answers would be applicable to the broader case of all FOSS licenses which permit redistribution of derivative works I can change the question to the more general case

4

Docker container licensing is an utter mess. If you have a choice, the best move is not to play.

Dockerfiles are simple: they are just an installation script. If you write the Dockerfile by yourself you are the sole copyright holder and can license it however you like, regardless of the licenses of the software referenced by the Dockerfile.

Container images are really tricky though because they contain copies of all the software in the image. Thus, you need to comply with all the licenses of all the software in the image. Additionally, the image as a whole may inherit licensing restrictions from the Dockerfile or from base images (I've illustrated these relationships in another answer).

Let's assume that your base images have already sorted out license compliance, e.g. because they use a Debian base and only install official packages (Debian is really good at managing license compliance, and you can find license info under /usr/share/doc/*/copyright). Then, you can focus on the software you add in your topmost image layer.

The MIT license requires that the copyright/license notice “shall be included in all copies or substantial portions of the Software”. This means:

  1. Include a copy of the license in the image itself, including any copyright notices that are in the original license.
  2. If your image has associated documentation such as a README file, add the license there as well, or at least tell people where they can find the full license.

Other licenses might have other requirements, for example if you copy GPL-covered software into the image you would also have to provide a copy of the source code for that software (but not for the entire image with all base images).

You should not modify the software's license to add your own copyright notice because you did not modify the software – you only copied the software into the image.

However, you may decide to offer your Dockerfile and the image as a whole under a license of your choice. But you should be aware that the license of the image as a whole seems to ahve little to do with the licensing of the software in the image. E.g. it is common that an MIT-licensed image includes lots of GPL software. I assume that if a base image is GPL-licensed, then your image would have to be GPL-licensed as well (even if your Dockerfile has a more permissive license).

All in all, this could mean that a document describing the licensing status of the image could include:

  • the license of the image as a whole, taking into account licenses of Dockerfiles and base images
  • the licenses of the base images
  • the licenses of the Dockerfiles
  • the licenses of all the software in the image incl base images
  • in particular, the licenses of the software you added to the image
  • where applicable, information about the corresponding source code of images or software in the image

Personally, this means that I do not publish Docker images because this seems awfully complicated. Other people (incl many official Docker images) seem content to only provide the following:

  • the license of the image, which is taken to be the same as the license of the Dockerfile
  • the licenses of major software components added to the image
  • a vague nod towards base images

Is this compliant? I doubt it, but so far no one is complaining.

| improve this answer | |
  • 1
    Thank you for taking the time to write up this quite involved answer. I didn't realise it would be so complicated, particularly with respect to the images. By happenstance, I did some of what you suggested: explained the copyright of the original project in the README for the Docker project. I'll update it to point to the base image copyright too (Alpine; this is one of those rare cases where project itself is so straightforward that it has no dependencies). Thanks again! – bertieb Jun 12 at 12:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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