Docker image with proprietary software and GPL library

Question

As a company we have a proprietary software, coded in Java and distributed to our clients in .war packages that they run on their servers. To run, the software requires a program licensed under GPLv2 or later. The creator calls this program a library, but it can be executed from shell as a standalone entity.

How it works is:

• our software receives a file via API
• we convert the file into another format using the program (run from shell)
• we extract certain data from the new format, we organize it, aggregate information and perform analysis
• we return the new information in XML/JSON to the client via API

Our software is used by our clients under our own license for a fee. Before actually using it, the clients have to download and install the program on their own as a dependency. So in that regard we're in the clear selling our software without any GPL restrictions.

However we've run into an issue with interpreting the license when one of our clients asked us if we could release our software as a docker image with all dependencies already inside.

Our issue is that we would technically be distributing the program as part of a whole (our software + program in one entity) which in theory would fall under:

when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

However, 2 paragraphs down we read:

mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

We don't modify the program we use at all, we just use it in runtime. We also believe our software can't be classified as "work based on the Program" under the definition of "the Program or any derivative work under copyright law". This leads us to believe that the docker image with both our software and the program would not make the software or the docker image a GPL licensed Program.

The new client in question doesn't want to get the docker file, they require an already "compiled" docker image.

So, can we distribute docker images containing a GPL licensed program used by our proprietary software without making the software fall under GPL as well?

Answer 1

Before actually using it, the clients have to download and install the program on their own as a dependency. So in that regard we're in the clear selling our software without any GPL restrictions.

That is not correct. The determination if your software is a derived work of the GPL program does not depend in any way on the number of parts you divide it in or from how many locations your customer needs to download the various parts.

If your software can only work with this particular GPL program, then it is most likely a derived work and needs to be GPL licensed itself as well.

On the other hand, if your software can work with any package that provides the needed functionality and can be invoked in <this> way, and if that package can be created without knowing the source of the GPL program, then the two are most likely a mere aggregation and unrelated in copyright terms.

For the determination if an alternative to the GPL program can be used, only the technical possibility is needed, not the economical feasibility.

Taking all that into consideration, it makes no difference if you distribute the complete installation as a docker image, or if you let your customers download from multiple locations.

Answer 2

OP wrote in the question:

we convert the file into another format using the library (run from shell)

And OP also wrote in this comment:

Once our clients install it, they can just run it from the terminal like "program -i file.docx -o file.html". Our software does the same thing, calling the "library" in that way and receiving its output to process further.

The GPLv2 FAQ entry (below) states that calling a GPLv2 program by command line is normally considered mere aggregation, as a form of inter-process communication, and thus the GPLv2 conditions would not apply to the calling program.

However, if your software is dynamically or statically linked to the GPLv2 library, then the conditions of the GPLv2 would apply to it.

What is the difference between “mere aggregation” and “combining two modules into one program”?

Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program. Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL—if you can't, or won't, do that, you may not combine them.

What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.