4

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?

9
  • "So in that regard we're in the clear selling our software without any GPL restrictions." I would disagree with this (as would the FSF). Your code is a derivative work of the GPL library so must be GPL; at this point, the rest of your question becomes irrelevant. Oct 20, 2023 at 11:16
  • 4
    You call the library a 'dependency' and describe the interface between your proprietary software and the GPL-licensed library as "using the library (run from shell)". This is a bit confusing. Please describe this in more detail, as it makes the difference between a single combined work and aggregation. Oct 21, 2023 at 7:58
  • What I mean is, the Java code sends a command to the OS with the file, OS invokes the program that runs in shell with the file and returns the changed version. Why I believe our software is not derivative work is because with some adjustments we could replace the library and the work/processes we created in our software remain the same. Our clients would not be able to get any value from the library alone even if they integrated with it, it wouldn't be even remotely close to what they want to achieve. Oct 21, 2023 at 15:31
  • 1
    You still cannot "run a library" from the shell. Somebody must have built something round that library, but if you have true arms-length communication between the wrapper and your program (note that going via a file does not guarantee this) it may be you only need to supply the source of that thin wrapper round the library. Oct 21, 2023 at 20:41
  • The question for whether your software should fall under GPL is rather answered by "does your programme depend on the existence of the 'library'?" Not also, as Martin said: you cannot run a library on its own - that's the difference between library and programme. So your question is unclear (and Bart's answer is true nonetheless) Oct 22, 2023 at 17:09

2 Answers 2

4

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.

2
  • I don't know if it changes anything in your answer, but I just wanna copy what I further explained in the comments to my question - "library" is how the creator calls it, but it is a fully functional program. 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. Oct 23, 2023 at 12:07
  • 1
    @MaciejTarnawski, it doesn't change my answer, but it makes it easier to prove that your software is not a derived work of the GPL application. Oct 23, 2023 at 16:07
1

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.

2
  • "The GPLv2 FAQ entry (below) states that calling a GPLv2 program by command line is normally considered mere aggregation" - fixed that for you. Oct 23, 2023 at 19:46
  • @PhilipKendall Thank you.
    – ruben2020
    Oct 24, 2023 at 4:02

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.