Can I use openshift/origin docker images (openshift/origin, openshift/jenkins-slave-nodejs-centos7, centos/s2i-base-centos7), that are released under GPLv2, to build docker images in my software, if I want to release it under Apache License 2.0?
1 Answer
We have to make a distinction between the licenses of the images, and the licenses of the software in the images. This is based on the assumption that a container image is a collection of various softwares, like a CD-ROM or a ZIP archive.
If your software is not derived from GPL-licensed software, then you can of course license your software under Apache 2 or any other license, including no license or licenses that are not open source.
If the container image contains GPL-licensed software (as most images will), this does not put any restrictions on you, except that you must satisfy the GPL for the GPL-licensed software. If your base images are built properly no action on your part is needed, though you must not deprive downstream users from their rights under the GPL to the GPL-licensed parts. But this is the same as with any Linux distribution which may contain GPL- and not-GPL-licensed parts.
But what if the image itself has another license? If the base image was licensed to you under the GPL then your image would be a derivative work of the base image. You must then distribute your image under the same license. This doesn't mean that your software in the image has to be GPL, though the source code of the image must be made available and must be compatible with the GPL.
At this point I'm not quite sure what the requirements are, in particular whether the corresponding source of a container image would be the build scripts to create the image, or also all source for the included software. Here there might be a conflict, because the Apache 2 is not compatible with the GPLv2.
However, I have my doubts whether a typical Linux userland in a container image could be validly licensed under the GPLv2.
In most cases Docker images are published under a permissive license (such as the Docker Hub default license). Therefore, my last point will likely not apply and image licensing is probably irrelevant. Instead, consider the licenses of the software within the image.