44

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?

2
  • 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. Jul 9 '18 at 18:05
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – MadHatter
    Feb 8 at 8:12
39

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.

3
  • 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
  • 17
    @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
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – MadHatter
    Feb 8 at 8:12
15

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.

3
  • 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. Jul 10 '18 at 2:42
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – MadHatter
    Feb 8 at 8:14
4

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.

8
  • 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
  • @user253751 What the OP is describing with their "loose coupling" is having an API between the GPLed code and the proprietary code. APIs do not create a derivative work, and that is well-established.
    – studog
    Apr 15 at 12:58
  • @studog Every library has an API between it and the proprietary code. Therefore, by your reasoning, every GPL library can be used in proprietary code?
    – user253751
    Apr 15 at 13:21
3

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.

1
  • 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.