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

Question

As we all know, the GNU General Public License (GPL) is a "copyleft" source license: which means it is designed not merely to make the code to which it is initially applied free and preserve its freedom, but moreover to "catalyze" the creation of new free code by requiring that any original works that use any copyrightable portion - no matter how small - of the GPL code in them, to also be released as free/open code under the GPL, in their entirety, and not merely the parts specifically depedent upon it.

It seems this only applies to the case where you directly mix code, i.e. where you actually take a piece of code from the GPL program and put it physically into the source code files of your original program, and perhaps also to linking to it as a library (which is why the LGPL exists, to exempt this particular use case).

What happens if you try to make an even "looser" coupling? In particular, if you were to compile all the GPL code and any modifications thereto as a totally separate executable program that can run on its own, independently of the original program, but yet which the original program communicates with as a spawn process, while still not containing any actual GPL code, whether directly in its source code or indirectly included by linking, merely the process calls alone, and as a separate program could in theory be used just same by any other program without modification. And moreover, when you distribute the proprietary package, this stand-alone program comes with its complete source code available under GPL terms. Would this be legal or not? If not, what exactly in the GPL and/or copyright laws forbid it?

Answer 1

IANAL/IANYL. That said, the FSF, who are generally thought of as arguing for a fairly wide interpretation of what the GPL covers, are reasonably clear that the proprietary program and the GPL wrapper program in your example are not derivative works of each other, and their appearance together is mere aggregation:

By contrast, [...] 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.

Note that they go on to add:

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.

So: as long as it's honest-to-God communication via userspace, where the calling proprietary code forks-and-execs the called GPL wrapper program, the GPL obligations of the called program do not extend to the calling program. If you start playing silly buggers, for example passing not just a few simple run-time command line arguments, but e.g. instead passing the name of an on-disc file which itself embodies complex program-specific structure, this separation of obligations may not apply.

Answer 2

The answer is, it depends. If you are introducing the wrapper just to try to avoid the obligations of the GPL, there's a good chance it's not legal.

Whether two works are derivative works of each other depends not on the technical aspects of how they communicate, but the creative elements of how they are used.

The FSF has this to say in the GNU FAQ, emphasis mine:

A system incorporating a GPL-covered program is an extended version of that program. The GPL says that any extended version of the program must be released under the GPL if it is released at all. This is for two reasons: to make sure that users who get the software get the freedom they should have, and to encourage people to give back improvements that they make.

However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.

The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing.

If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly. The issue is simply one of form: how you describe what you are doing. Why do we care about this? Because we want to make sure the users clearly understand the free status of the GPL-covered software in the collection.

If people were to distribute GPL-covered software calling it “part of” a system that users know is partly proprietary, users might be uncertain of their rights regarding the GPL-covered software. But if they know that what they have received is a free program plus another program, side by side, their rights will be clear.

So, if you are creating the wrapper solely as a means to introduce some sort of artificial separation between the two portions, you are almost surely not creating two separate programs.

Communicating at arms length means you are communicating at a high-level, barely specific to the GPL program in question. If you are using a GPL program, but you could easily use a different one as a drop-in replacement, you're communicating at arms length. If using a different, but similar program, means you have to re-architect your application, it's not at arms length.

Some guidelines to determine if the program and wrapper are at arms length?

• Is the 'wrapper' a useful program just by itself?
• Is your program useful and able to function without the 'wrapper'
• Are there other wrapper programs in the wild that you could use instead of yours?
• Was the wrapper created to serve a purpose other than your proprietary program?

If the answers to any of those are no, then clearly the wrapper and your proprietary program are a single work, and the GPL and any other license of the software you want to use in your wrapper would apply in your proprietary app.

Answer 3

It is my understanding that yes, that is legal. I have built systems that work just so, proprietary user space applications spawning GPL applications.

which means it is designed not merely to make the code to which it is initially applied free and preserve its freedom, but moreover to "catalyze" the creation of new free code by requiring that any original works that use any copyrightable portion - no matter how small - of the GPL code in them, to also be released as free/open code under the GPL, in their entirety, and not merely the parts specifically depedent [sic] upon it.

An "original work" that uses code from another source is in fact a derivative work of both the original work and the other source, and it is the derivative work that is required to be licensed under the GPL. The original work remains under whatever licence it had before. Now, the entirety of the original work has been copied into a work that is GPL licenced and thus the source code is public, so the original work's code is now public, true. But it is public because it was included in a derivative work.

It's a subtle but important difference.

Answer 4

IANAL

There is a very good answer by @whatsisname. I would say though that "using" will most definitely be legal. "Distributing" though might be an issue. Whatever you want to do, in case you avoid the distribution of GPL code together with your program the requirement to open your source shouldn't apply.

This is seen in some programs in other contexts as well. They have the user download the program with incompatible license (even assisted by the program), then they are not distributing anything thus don't have to comply with said license.