4

I created a program with two dependencies DepA and DepB.

  • DepA is published under GNU GENERAL PUBLIC LICENSE Version 2, June 1991 and is called as an external program
  • DepB is published under MIT License and is used via an API

While I understand that GPLv2 and MIT are incompatible, I am not sure what that implies for my situation. After all, e.g., package managers for linux distributions also include packages with incompatible licenses and, so, publishing cannot really be a problem. I am also not modifying their code in any capacity. Using one of them (depA) just as a program I execute from my program and the other (depB) by using a binding provided by them.

I now want to dockerize my program where the dockerimage would contain DepA, DepB, and a binary of my program.

  1. Am I allowed to publish my binary and the dockerfile? (I suppose so)
  2. Am I allowed to publish the resulting docker image? (I guess not)
  3. If one of the two is insufficient, can I provide something in addition to make this work (like the source/binary/license files of the dependencies)? (I guess that providing the archives of the two packages used for building the docker image is sufficient)
  4. Do I have to publish my source code when publishing the docker image? (I guess no)
  5. Am I limited to a license for my source code/the docker image when publishing the docker image? (I guess no)

I found this article suggesting to let the users build the docker image themselves and only providing the docker file for that. Well, I am really not experienced with licensing and this appears to be a tricky situation to me.

1
  • 1
    GPLv2 and MIT license (aka Expat license) are compatible.
    – ruben2020
    Mar 25, 2023 at 16:12

1 Answer 1

4

As you can see here, the MIT license is compatible with GPLv2. But as described in the following paragraph, this is irrelevant for your question.

The way you combine these 'dependencies' with your own code (for DepA "called as an external program", for DepB "used via an API") qualifies even under the strict interpretation of FSF as 'mere aggregation'. So the licenses of these 'dependencies' do not have any influence on your choice of license for your own code. You could even use a closed-source license if you wish.

As described in the FAQ for GPLv3, the fact that you plan to put all parts into a docker container does not have any impact.

Am I allowed to publish my binary and the dockerfile?

Yes. You need to include the license and attribution information (and the source code of the GPL licensed files) for the 'dependencies' if/when you distribute the code

Am I allowed to publish the resulting docker image?

Yes. You need to include the license and attribution information (and the source code of the GPL licensed files) for the 'dependencies' if/when you distribute the code

If one of the two is insufficient, can I provide something in addition to make this work (like the source/binary/license files of the dependencies)? (I guess that providing the archives of the two packages used for building the docker image is sufficient)

See above.

Do I have to publish my source code when publishing the docker image?

No, based on the requirements of your dependencies' licenses you do not need to do that.

Am I limited to a license for my source code/the docker image when publishing the docker image?

No. See the link above (mere aggregation).

1
  • 1
    depB is used via a binding provided by the authors of depB, so the situation is slightly more complicated than you describe. But as depB uses a permissive license, that doesn't really affect your analysis. Mar 27, 2023 at 8:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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