Distributing GPLv2 code and ENTIRELY SEPARATE closed-source software (no interaction between them)

Question

Do I have to GPL all software in a .deb package just because it contains some GPL(v2 in this case) code, even if these things have nothing to do with each other except being distributed in the same installer at the same time?

In more detail: I want to distribute a .deb installer for a product we're smushing together. It is only intended to be installed on this product. It contains a closed-source application and also a Plymouth theme for the OS. Needless to say the two do not interact or depend on each other in any way, since, once is a piece of desktop software, and the other is just a theme for making the OS look pretty on boot/shutdown.

Existing themes seem to be GPLv2, so if I were to modify one to create a new theme that way, I understand I'd need to provide the source and license/copyright to go along with it.

But am I right in thinking, since the theme has nothing to do with the closed-source software other than being in the same .deb installer, it shouldn't affect the licensing of the closed-source software in any way?

Answer 1

Your thinking is correct. This is called "mere aggregation" and the GPL FAQ has an entry about it:

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.