5

These questions can easily devolve into philosophizing, so let me be concrete:

  1. There is open source software X licensed under the GNU General Public License (v2 or later).
  2. X runs as a stand-alone Java socket server process, i.e. java -cp x-gpl.jar edu.x.SocketServer -port 8000 … . No modifications needed nor done, this is how X works out of the box.
  3. I'm calling this socket server from my own program Y.
  4. Both the socket server X and my program Y processes run inside Docker (Ubuntu Linux), launched from that Docker's supervisord.conf on container startup.
  5. I want to distribute this Docker image to 3rd parties, as a commercial proprietary application.

Now, the question is, is this particular combination of X, Y and Docker in line with GPL v2 or later? Does it constitute derivate work, or aggregate work, in the GPL Section 5 sense? Does my program Y or the entire distributed Docker image need to be licensed as GPL?

Happy to provide additional details if relevant, but please avoid irrelevant tangents. Thanks!

Other related (but overly generic) questions:

The term “aggregate” in GPL3

Are all docker images free (i.e. GPL)?

Is it legal to use GPL code in a proprietary, closed-source program by putting it in a separate, standalone program?

Is a program that forks a GPL-licensed program via a system or vice versa call derivative work?

Improve this question
3
  • "I want to distribute this Docker image ... as a commercial proprietary application." - What do you mean by commercial proprietary? For example the GPL requires that you also distribute the source code to any GPL programs that are included in that distribution. Would that still fit your definition of "commercial proprietary"?
    – Brandin
    Jun 3, 2019 at 8:33
  • @Brandin sure, the Docker image can include all the GPL sources. Why should that be an issue? I don't follow.
    – resu12345
    Jun 3, 2019 at 16:10
  • Yes, as long as you do that, then you will be meeting the requirements of the GPL for each GPL program you included in the image. This is why "commercial proprietary" is ambiguous. When I read that I thought you meant you wanted to distribute the Docker image but not include any sources.
    – Brandin
    Jun 4, 2019 at 6:48

1 Answer 1

Reset to default
6

X and Y clearly are separate programs. Your program Y is not subject to the GPL.

The container image is an aggregate of various software. When distributing the image, you have to comply with the licenses of all software in this image. Some parts of the image (including software X and parts of Ubuntu) are subject to the GPL. So you have to comply with the GPL with respect to these parts. Debian/Ubuntu has built-in mechanisms to include the licenses and get the corresponding source, so your compliance requirements are mainly confined to including a license and the source for software X.

As part of complying with the GPL, you must not restrict end user's exercise of their rights under the GPL. For example, users must be free to make copies of the GPL-covered components. That means you cannot place the image as a whole under a proprietary license. But you can license your software Y under whatever terms you like.

Personally, I find container image licensing so tricky that I would never want to do it. Instead, consider only distributing your software + a Dockerfile, so that users can build their own images.

Improve this answer
6
  • 1
    The problem is that X and the Docker image are clearly not seperate programs. And Y and the Docker image are also clearly not seperate programs.
    – Taemyr
    Jun 1, 2019 at 21:56
  • 2
    @Taemyr I view container images not as a linked executable, but as a file system image that can contain separate programs – very much like a thumbdrive or CD-ROM with an autoplay.exe. If all the software in an image were to form a single work, nearly all images would fall under the GPL because they contain some GPL components (like Busybox, Bash, …). I think that interpretation is totally flawed.
    – amon
    Jun 1, 2019 at 22:13
  • +1 from me. +2, if I could, for the recommendation against distributing container images: it leaves you with a large and long-lived set of GPL obligations. It's also a horrible way to distribute software.
    – MadHatter ♦
    Jun 2, 2019 at 15:31
  • 2
    @Taemyr A docker image is a container for other software, just as an .iso file is, or a .tar.gz file, or a .zip file, or an .msi installer, or a sharutils archive, and so on. The only question you need to ask is whether X and Y inside that container are a mere aggregation (separate programs) or not.
    – Brandin
    Jun 3, 2019 at 8:36
  • @MadHatter somewhat OT, but why do you consider container images a "horrible way to distribute software"? IMO hard to imagine an easier distribution mode: just push an image to a private Docker repo, then let (select) people pull it. Forget CDs and complex UNREPRODUCIBLE setup instructions.
    – resu12345
    Jun 3, 2019 at 16:17

Your Answer

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

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