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?

  • 8
    "requiring that any original works . . . to also be released as free/open code under the GPL" - This may be a distinction without a difference in your case, but that is not what the GPL requires. It does not say that projects using GPL code must be released to the public. It only requires that whoever receives the binary must have access to the source. If the binary is private, the source can be, too. – StackOverthrow Jul 9 '18 at 18:05
  • 3
    Are you planning to release the proprietary software? If you keep it all to yourself, then you can do anything you want with GPL software. The licensing issue happens when you decide to convey modified software. – jmarkmurphy Jul 10 '18 at 12:14
  • 1
    I have adviced several companies on that exact issue. The key problem was that the companies thought that GPL requires you to publish the source code. This is a common misunderstanding. When they learned that you only have to give the source code to the (paying) customers that you are giving the binary to, then they had no problem putting their own code under GPL. They never published their code for free download. Maybe this also applies to your situation? – Ole Tange Jul 10 '18 at 13:06
  • 2
    @OleTange The GPL however allows these paying customers to freely redistribute the source code and then anyone to rebuild the binaries from that source code. – jlliagre Jul 10 '18 at 22:34
  • 2
    @jlliagre True. In my cases that was never a concern: The customers were not competitors and would never go into the IT-business. Most (all?) of the customers did not care about the license. – Ole Tange Jul 11 '18 at 0:00

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.

  • 5
    That is the FSF interpretation, true. A judicial court might disagree that shipṕing "complex data tailored to the internals" is coupling enough to trigger the GPL. – vonbrand Jul 9 '18 at 14:35
  • 16
    @vonbrand indeed they might, and I think I was clear that I was only looking at the FSF's interpretation. But the OP asks whether honest-to-God userspace interaction is enough to decouple two programs, and my point was that even the FSF concedes that one. Who might find certain other questions grey, black, or white need not concern this particular question, I hope. – MadHatter Jul 9 '18 at 14:47
  • 7
    @whatsisname If you have any source to support your claims, you should post a separate answer citing them. – reirab Jul 9 '18 at 20:11
  • 3
    What should matter is not the simplicity or complexity of the communication between the two systems, but rather whether someone with a copy of the published documentation for the portion containing GPL code would be able to use it in the same fashion that the proprietary subsystem does. – supercat Jul 10 '18 at 4:34
  • 3
    @whatsisname I disagree with your very claim, "It is clear from the description of the OP that the wrapper and main program are two pieces of a single work" -- OP clearly indicated that proprietary program X calls GPL program Y (which exists independent of and is perfectly capable of functioning without X). – Doktor J Jul 10 '18 at 17:08

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.

  • 6
    None of your guidelines are mentioned in the FSF quote. It's a good quote, and I'm glad you posted it - but it doesn't support your argument. It merely notes that if caller and callee communicate intimately, they may not be independent of each other, and I think that was already agreed. – MadHatter Jul 9 '18 at 20:44
  • 2
    @MadHatter: I wrote those guidelines based on my understanding of the topic. I disagree with your answer's claim that the OP's wrapper is a 'mere aggregation'. Yes, you touched on the idea that the two parts could be one program but I didn't believe it addresses the depth the question demands. – whatsisname Jul 10 '18 at 2:42
  • 3
    With regards to copyright law, one's intent in creating the 'wrapper' program is generally irrelevant. The OP doesn't specifically mention a wrapper, however it does seem clear that any code in a wrapper program would be subject to the GPL. But, if the OP's proprietary program interacts with the wrapper as described, by spawning it as a separate process, then their proprietary program is not GPL'ed as it's not a derivative work. That the wrapper is useless on its own or that it exists purely to get around the GPL tends to be neither here nor there. GPL'ing the wrapper satisfies the GPL. – aroth Jul 10 '18 at 3:53
  • 1
    @supercat I'd agree that you'd have to make it available to them. Which I guess implies "usable", but not necessarily "useful". I'd also be inclined to consult an actual lawyer before distributing the proprietary binary and the GPL'ed wrapper in a single commercial package. It's likely safer, if not strictly necessary, to include just the proprietary binary in the commercial package and then have the GPL'ed wrapper download/install separately. – aroth Jul 10 '18 at 4:34
  • 2
    @aroth: The ability to use the portion that is required to be open-sourced should not be predicated upon secret knowledge. As to whether anyone who doesn't own the proprietary software would have any reason to want a program that does the task which is handled by the open-source software, I don't see that as particularly relevant. – supercat Jul 10 '18 at 5:45

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.

  • 1
    You're glossing over the last part of your quote: "in their entirety, and not merely the parts specifically depedent [sic] upon it". Cleverly splitting applications in two to only publicize the parts specifically dependent on it goes against that. – Flater Jul 10 '18 at 14:57
  • 2
    Paragraphs 2 (quote) and 3 are to highlight a problematic mindset when thinking about GPLed code. With a correct mindset, it's easy to see that the entire derivative work is GPLed. – studog Jul 10 '18 at 17:37
  • @Flater (As a non-lawyer programmer who had to read all these licenses fully), I reckon that there may be ways to split the application like that, but writing a wrapper is not one. – user253751 Jul 12 '18 at 0:18


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.

  • 5
    This is an important point. Also related is that people asking these kinds of question often do so regarding their own, purely internal applications, unaware that the GPL only becomes relevant when they distribute their program to a third party, and therefore will likely never be relevant for their purposes. – Jules Jul 11 '18 at 0:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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