Can I dynamically call a LGPL/GPL software in my closed-source application?

Question

I want to use a tool (ffmpeg) that is under GNU Lesser General Public License, version 2.1 GNU General Public License (GPL) version 2 for some components.

To do so, I only call it in my software as such:

System.Diagnostics.Process p = new System.Diagnostics.Process();
p.StartInfo = new System.Diagnostics.ProcessStartInfo("lgplSoftware.exe", myParams);
p.Start();

I do not change it, I only use a built version of the software for windows.

---

Wikipedia says:

A key dispute related to the GPL is whether or not non-GPL software can be dynamically linked to GPL libraries. The GPL is clear in requiring that all derivative works of code under the GPL must themselves be under the GPL. While it is understood that static linking produces derivative works, it is not clear whether an executable that dynamically links to a GPL code should be considered a derivative work (see Weak Copyleft). The free/open-source software community is split on this issue. The FSF asserts that such an executable is indeed a derivative work if the executable and GPL code "make function calls to each other and share data structures," with certain others agreeing (e.g. Jerry Epplin), while some (e.g. Linus Torvalds) agree that dynamic linking can create derived works but disagree over the circumstances.

---

I am really confused by all this legal things. I would have made my project LGPL as well and released the source, but this is not up to me.

So the question is: can I use it like I'm doing right now or will I be executed by an army of lawyers?

Solution 1

Linking has a specific meaning in computer programming. You're not linking GPL'ed or LGPL'ed code at all, you're only spawning a GPL'ed or LGPL'ed binary, and the GPL and LGPL permit this. Your users are free to use that binary themselves for its authors' intended purposes and are free to download and compile the source themselves, so all of their freedoms are preserved, and you're not in violation of the GPL or LGPL. (This is what the GPL FAQ is talking about by "communicat[ing] at arms length.") This doesn't even violate the spirit of the LGPL and GPL; they tolerate the existence of proprietary software and assume that at some point proprietary programs will spawn free programs and vice versa. (Otherwise, we couldn't run any GPL'ed software under Windows.)

The GPL does require that proprietary and GPL'ed programs "are not combined in a way that would make them effectively a single program." If your program is completely dependent upon GPL'ed executables, such that it wouldn't be usable without them even though it is a standalone binary, then that might place you on shakier ground. (And it's probably time to consult your lawyer to find out for sure.)

Also, although you didn't specifically ask about this, keep in mind that distributing GPL'ed or LGPL'ed software with your software means that you're required to include a copy of the license with your installer and to also distribute the source code. For example, if you package up your application in an installer and include copies of GPL'ed or LGPL'ed executables in the installer, then you're distributing LGPL'ed or GPL'ed code and must make copies of the source code available (either online, by mail-in offer, or by CD, depending on how you distribute your app). Including a link to the upstream project is not sufficient (at least for version 2 of the GPL). Read the GPL and LGPL for exact details.

Solution 2

Correct me if I'm wrong, but I believe the situation you describe is like this:

1. You have a GPL or LGPL program, built as a separate executable, with no modifications made by you.
2. You are building a closed-source application that needs the functionality of the GPL or LGPL program.
3. In your program, you use your framework or OS facilities for running another, separate executable.
4. You are using the output of that executable in your program.

If that's the case, you're not actually linking to the GPL- or LGPL-licensed program. Thus, you're not bound by the license terms of that program. This is actually a fairly common, if complicated, way to avoid licensing issues with such executables.

However, it does violate the spirit of the GPL and the LGPL.

Solution 3

In general, it's one of the few things that I consider to be real nasty of the GPL. What makes it worse is how contagious it can be. Still, there is a way to get around it.

First, start by defining your own interface to send over data. This will be used between your application and a separate library that you will be creating. Don't re-use anything from the GPL code because that would fall under the GPL license. However, there's nothing wrong with using a similar structure. Since this interface is your own creation, it would fall under your own license. You're free to use it any way you like.

Next, create a wrapper library around the GPL code which will also implement your personal interface. This library would fall under the GPL license and thus it gets contaminated. However, although it would expose your interface to the outside world, your interface cannot be contaminated. It's not derived or whatever. It's 100% your own code and you could use the same interface to connect to a different library.

This wrapper library will serve as a protection buffer between your own propriety code and the GPL code. Your own code would never be GPL since it's not using any GPL code directly. The interface will also serve as a solution to change the GPL code by a different solution.

It is a trick to get around the license restriction but since the interface is yours and yours only, the GPL will be blocked by it. THE GPL code and non-GPL code would be two different programs if used this way.

Still, be aware that you might need some legal advise here. There aren't many lawyers here at SO. But it is a trick that can get around this GPL license.

Solution 4

You can do this with LGPL software, but you cannot do this with GPL licensed software.

LGPL 2.1 section 6 on combined works says how you can use the library in your closed source program. You can call a LGPL licensed program like you do, and you can even dynamically link to it.

The GPL has no such exception, when you use a GPL program/library as part of your program, so that it is perceived as an integral part of your program, then you have to license everything under a GPL compatible license. See this GPL-FAQ entry.

Solution 5

I am not a lawyer, and this can not be a legal advice. With that behind us, IMHO if the code you are linking against is LGPL, you are in the clear. If it is GPL technically it is a problem.

The difference between GPL and LGPL, is that linking against LGPL code, does not trigger the need to share.

View more solutions

Comments

[Pavel Minaev]

The answer will depend very much on your exact situation, the jurisdiction you're in, and many other things. Only a lawyer could tell with any degree of certainty. If you don't want to hire one to tell you, the only reasonable safe answer is "no, you can't do that". Following advice in any other answers that may come up for this question here without a lawyer consultation would be extemely unwise.

[Admin]

@marcgg: did you solved that problem yet? i mean its now 2012

[marcgg]

You did get my situation. How do you define "linking"? Do you have any references regarding what you said? Also I know that what I'm trying to do is against the spirit of GPL and I feel bad about it... but like I said the decision of making the software GPL is not up to me at all.

[marcgg]

Thanks for your answer. But they do say "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 non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.". Also, what do you think of mipadi's answer?

[marcgg]

Thanks a lot for the helpful answer. Could you precise if "Also keep in mind that distributing GPL'ed or LGPL'ed software means that you're required to include a copy of the license with your installer and to also distribute the source code." applies to me?

[marcgg]

But if my interface uses gpl code, then it has to be gpl, isn't it?

[Wim ten Brink]

AFAIK, you're required to add at least a link to the GPL/LGPL license plus allow people a way to download the exact version of GPL/LGPL code that you have used so they can use that code themselves. In general, it's enough to add a text file during installation that contains the GPL/LGPL text plus the download URL for the GPL code. (Including any code that's tightly linked to the GPL code.)

[Justin Standard]

Its not against the spirit of the GPL / LGPL (unless you would argue that developing closed source software at all is against the spirit of those licenses).

[Wim ten Brink]

Yes, therefor your interface should NOT use GPL code. Define your own interface and map it to the GPL interface. The mapping would be GPL but your interface would be your own. The interface would become part of the GPL code that you need to distribute, but since it's your own creation, you can grant yourself a different license for your own GPL code. It's called a dual license.

[Justin Standard]

What you are failing to realize is that the poster is not using it as "part of their program". True they are creating a dependency, but they're just calling a binary, not combining them into a single program. marcgg is right. I'm surprised there's so much confusion around this.

[Josh Kelley]

@Workshop Alex: A download URL may not be sufficient. For example, if it's GPL v2, then a download URL is only permitted if your app is also downloaded (and not distributed via CD) and only if the download URL is to the same site that your app is downloaded from (no upstream links permitted).

[Justin Standard]

In general its probably better to include a copy of the license and a zipped archive of the sourcecode for the version of ffmpeg that you ship with your software.

[marcgg]

@justin: sounds like a good advice, I'll do this if it turns out that I'm sure that I can use ffmpeg

[mipadi]

I think it's against the spirit of the GPL. The idea is that if you find GPL'ed software useful enough to use in your own program, you're supposed to make your source available, too; if you don't want to make your source available, you're always free to use another non-GPL'ed solution. I think the FSF would argue that developing closed-source software is against the spirit of its goals, and the goals of the GPL (and, to an extent, the LGPL).

[Michael Ekstrand]

Code in question is not actually linking, as indicated in other answers.

[James Caccese]

Library linking is an example of one way, but is not the only way, to create a derivative work. The FSF has stated many times that if you are taking actions like this with the intent of subverting the GPL, you are in still violating the GPL. The exchange of complicated data structures and having tight dependencies, regardless of whether they pass through a "wrapper library", linking (static or dynamic), a remote procedure call, process creation, or any other form of inter-process communication still constitutes a derivative work. See gnu.org/licenses/gpl-faq.html#GPLWrapper

[rxantos]

@mipadi: I guess you cannot then run GPL software under windows. After all windows is doing exactly the same thing, spawning a program.

[rxantos]

If that where true. Then you cannot legally run gpl software under windows. As all that windows is doing exactly the same thing, spawning a program.

[rxantos]

In what part exactly does one derive when spawning a program?

[mipadi]

@rxantos: I know you're being snarky, but that issue is actually covered in §3 of the GPLv2 and §1 of the GPLv3. :)

[reiniero]

@James: could be, but if your wrapper interface then allows for multiple backends (even just a diagnostic/logging tool), that would change things.

[0xbaadf00d]

@JoshKelley About the last statement, can you point me to where this is said in the license? I'v had the understanding that this is how it works, but I'd like to read it straight from the source.

[Josh Kelley]

@0xbaadf00d - See the GPLv2, clause 3. Item (c) allows linking to upstream but significantly restricts when that option can be used. GPLv3, clause 6d, does allow upstream download links.

[ajbeaven]

Could you please clarify that the way the OP is using the .exe here means that he is not linking to FFmpeg and is not required to follow the checklist specified here? ffmpeg.org/legal.html. That checklist specifically mentions the fact that you must dynamically link (reference dlls) in order to comply.

[user253751]

@rxantos If your code is based on the library. Now, if you had a totally generic interface (say, for logging) and plugged a GPL logger into that interface, your code isn't derived from the logger. But if you design the interface around the specific capabilities of the GPL logger then the interface (probably) is derived from the GPL logger.

[tehftw]

It's at least slightly insidious to call GPL licenses "contagious" like some virus. If someone wants to make non-free, closed source software, then it would be more "honorable"(for lack of a better word) to not use the work of pro-freefsoftware volunteers in a non-free program.