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.

A practical example are proprietary graphics drivers for Linux that the end user has to install themselves. Importantly for the creator of the proprietary driver, if the end user distributes the combined work, that creates a legal obligation for the end user (which they cannot possibly fulfil) but not the creator of the driver.

Another answer claims “since the program depends on the library it is still a derivative work” – but if the program doesn’t actually work because the library is not there, then it’s not derivative.

But in the end, if you rely on “loopholes” then you should consider that your approach may not be the right one in the first place.

Linking defines a derivative by the GPL. This specific situation is what the LGPL was designed to handle: where you want to release the library as GPL but define linking as the explicit limit of the applied license, or alternately, where you want to link against some GPL code but require that your own work be released under a non-GPL license itself.

In the case where the end-user is going to do the linking (build his own code from non-GPL sources which may link against a GPL library) the end-user has not effectively created a GPL version of whatever the final product is, as he is not permitted to change the license of the non-GPL portion of the project because he is not the owner of it. This generally precludes distribution by the end-user in any form, but would not prohibit use.

That said, if a project requires that it be built from source and is only distributed that way it is irrelevant what license the linked library is under, as this is entirely out of the non-GPL developer’s hands. That is, how can you know your source-only distribution is going to be built on gcc against glibc VS built on an IBM compiler against their libc unless you specify this under your own licensing terms? This quickly runs into fair-use and prohibitions against unenforceable legal conditions (not that fantasy hasn’t been written into law on quite a few occasions recently).

I am not a lawyer, but as far as I can tell you are not correct, since the program depends on the library – it is still a deriviative work. The same way that a sequal is a deriviative work. At a minimum it is based on the APIs defined in the library.