Let’s examine a hypothetical scenario:
Company X writes a proprietary program (A) that dynamically links with a proprietary library (B). Company Y wants to use a replacement library (C) licensed under the GPL, and so writes a wrapper library (D) that dynamically links to both A and C and translates the API calls used by A to the API calls used by C.
As D is intended to be used with C, and uses C’s API calls, it is a derivative work of C and must therefore be distributed under the terms of the GPL*. As a result, the combined work of A and D must also be distributed under the terms of the GPL, which is impossible given that Company Y does not possess the source code for A. That said, so long as Company Y distributes D by itself, there is no problem. However, regardless of Company Y’s actions, Company X does not violate the GPL by distributing A, even without B. The mere existence of D does not mean that A is suddenly a derivative work of C (through D) that must be licensed under the GPL as well.
Now this is the loophole: there is nothing that stops Company X from writing its own version of D, distributing it separately from A, and telling end-users to use D instead of B when running A. It seems that a company is capable of designing a proprietary program to use a GPL library without violating the GPL, so long as a wrapper module is used to insulate the proprietary program from the GPL library and that module is distributed separately.
Am I correct in my reasoning? Is this a real loophole in the GPL?
*D is also a derivative work of A, but for the purposes of this scenario, Company X has explicitly authorized the creation of D and allowed it to be licensed under the GPL.
Best Answer
IANAL, but here is my opinion of what is allowed within the limits of GPL:
distribute the combined work "A - B" in public: fine, can be done under any proprietary license
create a wrapper lib D for C by Y: fine, this does not imply that A has to be put under GPL
use the combined product "A - D - C" internally by Y: also fine, GPL does not require to open source A as long as the combination is not distributed to the public
distribute the combined work "A - D - C" in public: this will require A to be open-sourced and to be put under GPL (and it does not matter if X or Y distributed this combination; additionally , if Y wants to do this that, they would require a distribution license for A from X, of course)
The interesting question now is: can D & C be distributed separately as open source under GPL, A&B (or just A without B) be distributed under a proprietary license, and the end-user replaces B by D&C by himself ?
Here the final modification to "A-B" which makes A dependent on libs D & C is done by the end user - after distribution. So one could argue that the final modification is only done internally by the end user. And it seems that this indeed is possible without violating the GPL - and what you get is a working combination of "A-C&D" where A is under proprietary license and C&D under GPL.
Of course, a lawyer or a judge may have a different opinion on that. To get a final answer, I think you must wait until someone tries it out and a second one sues him.
I guess for most systems, it will be hard to create such a constellation without designing "A" from the beginning in a way so it will work seamlessly with either B or C. And in this case, one could come to the suspicion that A was somehow derived from C.
EDIT: thinking a while about this, a similar situation came into my mind: writing and distributing GPL licensed plugins for closed-source applications. Lets take for example, Photoshop. I don't think someone would seriously try to enforce Adobe to open-source Photoshop just because there exist some GPL plugins from third-party vendors. Here, not even a "wrapper lib" is needed since there exists a well-defined interface. However, would it change the situation if Photoshop would incorporate some of its central functions from a GPLed third party plug-in? I think for such a case it may become really hard to decide where to draw the line, at which point the closed-source product is a work "based on" the GPL lib.
EDIT2: There are dual-license libs available, with a GPL license for non-commercial use and a proprietary license for commercial use like this one, for example. So your "loophole" would mean to develop a product based on such a lib (using the commercial version, so GPL does not apply to your product), deliver your product as closed-source without the lib to the public and let the end-user get and install the GPLed version by himself. For such a case, I guess the vendor of the lib will have a good chance of sucessfully sue you for license violation (if you don't pay for his lib, of course). Is it worth the hassle? Probably not. Especially in the example I linked to, you would have to buy the lib either, since the pricing is not dependend on how often you sell your product, but only how many devs are using the lib during development.
Finally, because of those legal risks, if I intend to use open-source libs within a closed-source product, I would avoid GPL libs if possible, and not try to make use of this "loophole". LGPL or GPL with linking exception is much safer, or any kind of non-viral OS license.