4

This is a question regarding commercial use of customized offical docker images (like RabbitMQ, ELK etc.). Are there any restrictions or limitations, for example if I code run scripts for RabbitMQ or ELK and repackage it into a custom docker image. Does that mean I have to publish the image on DockerHub to be compliant?

As far as I can tell, the images are mostly under the Apache licence. One is LGPL, and two of them are under the MIT licence.

Not very clear and could not find anything in my searches. Any input based on your experience would be great.

| improve this question | |
  • 1
    What are the licenses of the docker images? Please give us a lot more details. – curiousdannii Feb 19 '16 at 1:51
  • Thanks for responding. It's mostly Apache license pretty open. One lgpl, two mit licenses. – sharman Feb 20 '16 at 20:55
  • 1
    Can you please edit this to put that information into the question itself, and clearly explain which parts have which licenses? – curiousdannii Feb 20 '16 at 23:18
  • 1
    Are you intending to redistribute the image anywhere or is it just for your personal use? If it's just for your personal use then the licenses are irrelevant. You don't have to publish it unless you're distributing it. – curiousdannii Feb 20 '16 at 23:18
  • 1
    That is critical information. Please add the details requested to your question. – vonbrand Feb 22 '16 at 14:37
5

As far as I can tell, the images are mostly under the Apache licence. One is LGPL, and two of them are under the MIT licence

I would not make a confusion between the license of the Dockerfile and the license of the resulting images/image layers.

While the Dockerfile can use any license, the resulting image license will be likely more complex and based on the actual code that a whole exported image archive contains: you need to consider the whole stack of layers in that image, irrespective of the license of the Dockerfile and you cannot look only at the license of the top layers of your images.

For instance, if your image is based on Debian image and that you redistribute that image, you effectively redistribute a whole Linux environment in (mostly) binary form. The licenses in play are many and each have different requirements and will likely include L/GPL 2 and 3, several variants of BSD and MIT, Apache and more.

In effect, when you redistribute a Docker image archive, you become a Linux distributor.

For most licenses, you would need to provide some credits: while this is typically well handled by Debian distros, you are still obligated to ensure this is comprehensive and correct.

For any copyleft-license that require source code redistribution, you will need to ensure that you offer and can redistribute the "corresponding source code" including and not limited to the Linux kernel, the userland, etc.

If any layer contains only code using permissive licenses (say if a layer contains an ELK stack that you verified to be all Apache-licensed) you only need to comply with the requirements of the licenses of that layer for that specific layer, but you still need to comply with the license terms for the whole image.

And if you publish that image on the Docker hub or if you redistribute this image privately to your customers, your obligations stay the same (though their visibility is higher when published on the Docker hub).

However, to conform to the licensing agreements, is it as simple as packaging a license document with the image or is there another method?

At a high level there are two things you need to do to comply with open source licenses:

  1. attribution and credits composed typically of the notices, copyrights and license texts

  2. redistribution of source code for code that use a copyleft license (such as L/GPL)

Including 1. in the image makes a lot of sense and is the simplest way. You need to be careful though as some "official" images are stripped from the original notices and license texts to make the image smaller (as for instance the CentOS images... (tst, tst) that used to be until recently missing even a basic GPL license text (See this ticket for details and the code that deleted licenses here). You could also include in the image and other docs how to get the corresponding sources (for 2.).

For 2. including the sources in the image is likely to be problematic size-wise. You could instead carefully inventory all the open source packages and code that are included in every layers of your images and then carefully collect the corresponding source code for all of these and make these available as a separate tarball, ideally at the same time a user would download my custom images. And eventually you could automate this process such that it happens on each re-build on your images. To make things simpler you could include the source code of every open source third-party code used in your images, even if some do not require source code redistribution.

| improve this answer | |
  • Thanks for a comprehensive answer. However, to conform to the licensing agreements, is it as simple as packaging a license document with the image or is there another method? – sharman Sep 14 '16 at 17:54
  • @sharman I added to the answer extra elements based on your comment. Upvoting and accepting the answer is welcomed :) – Philippe Ombredanne Sep 15 '16 at 8:34
  • 1
    And this is why it's way easier to distribute a dockerfile than an image. ++ – RubberDuck Jan 31 '17 at 2:05
  • @RubberDuck When I distribute an installer with the docker config files which build and install a docker image I do not have to comply to the gpl licenses because they are downloaded by the user ? – MADforFUNandHappy Mar 26 '18 at 17:02
  • 1
    @MADforFUNandHappy you are just pushing any compliance and security issue on your users. Now if this image was created by you, you should be the one providing corresponding sources IMHO – Philippe Ombredanne Mar 26 '18 at 19:39

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.