Optionally Using GPL Library via System API in Closed-Source Application

Question

Please consider the following situation:

You write a closed-source application, let's call it A. A depends on a system API (i.e. provided by the OS), that is in turn configurable to use different backends. Each backend is identified by a simple string value and also selected via this identifier. The API itself is not bound by any GPL-like requirements.

Now, a specific backend (B) would be preferred but is GPL-licensed. The application would run without it, and there are other backends available, just with worse performance or other downsides.

Is any of the following permitted?

1. Hard-coding the identifier to B
2. Automatically selecting any available backend, but preferring B if available
3. Letting the user select a backend (and strongly suggesting B)

Would it also depend on whether I ship A and B together, or just A and suggest the user that installing B would improve the application performance?

I would generally think that all three options are o.k. since passing a specific string to a system API would hardly qualify for a derived work (IMHO), but the FAQ of B basically state that it does not matter how you call a function of B, any usage makes your program a derived work. Are they right even in the three cases outlined above?

P.S.: It is not my decision to make A closed-source, so GPL'ing it is not an option. P.S. 2: I omitted the names of the system API and B to keep the question more generic, but I can add them if it makes any difference.

edit: From another point of view: When does the user (as opposed to the programmer) create a derived work? In the third case, it should be clear that the user creates the derived work since he installed A and B and actively selected B. This would be in line with MSalters' arguments in his comment. The second case at least makes it clear that the work does not depend on B, so this could be o.k., too.

Probably it would be most in the spirit of the GPL to just contact the authors; however, I'm not sure if their FAQ entry is in line with the actual text of the GPL.

Answer 1

TL;DR: The FSF doesn't make a distinction between process and program, suggesting restrictions on your program which only apply to the resulting process.

The GPL works fundamentally via copyright. In particular, it's a distribution license (doesn't cover use) and is limited to works that are placed under the GPL.

Now one of the problems is when a work starts falling under the GPL, and what happens to it. I believe that the FSF is right, and your process falls under the GPL once it loads plugin B.

Your process. Not your program. Only the process in memory which combines the two, that is the derived work. Before the combination was made, no derived work exists in a legal sense. Therefore the GPL cannot dictate terms on your program. It simply has no legal basis.

Of course, you may use the derived work created by combining your program and plugin B in a single process. The GPL explicitly allows use. Now, if you ran this process in a VM, and cloned the VM, you wold be banned from distributing this VM image. Those rare things are covered. But usually, processes aren't copied so their legal protection under copyright is rather pointless.

Answer 2

If library B is using the plain GPL license (not the LGPL or a variant, like GPL with classpath or linking exception), then the FAQ for B is correct in so far that the Free Software Foundation (the ones who drafted the GPL licenses) consider a program a derived work from a piece of GPL code if that GPL code gets executed in the same process as the rest of the program.

To clarify the stance of the FSF, see these answers from their FAQ:

If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license? (#IfLibraryIsGPL)

Yes, because the software as it is actually run includes the library.

Does the GPL have different requirements for statically vs dynamically linked modules with a covered work? (#GPLStaticVsDynamic)

No. Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination. See also What legal issues come up if I use GPL-incompatible libraries with GPL software?

Can I apply the GPL when writing a plug-in for a non-free program? (#GPLPluginsInNF)

If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. So you can use the GPL for a plug-in, and there are no special requirements.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means that combination of the GPL-covered plug-in with the non-free main program would violate the GPL. However, you can resolve that legal problem by adding an exception to your plug-in's license, giving permission to link it with the non-free main program.

See also the question I am writing free software that uses a non-free library.

The fact that library B implements a non-GPL API might make a difference, but (seeing the last FAQ quoted above) doesn't seem to be considered different by the FSF.

---

You can make use of library B in your closed source program, but you are not permitted to distribute the combination of the two. If your program is written to work with a generic (non-GPL) API and works fine without library B, then you can distribute your program without the library just fine and users are also allowed to download library B separately and use it in combination with your application.

The big question is if you can actively refer to library B in your source code or documentation without it being considered a derived work of library B. This is a legal question that we don't have the expertise to answer. You will have to consult a lawyer for that.
Without mentioning library B, you would at least have the possible defense that you weren't aware of GPL-licensed implementations of the API, but only a lawyer can tell you how far that would get you in court.