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.

  • 1
    Short answer: no. – whatsisname May 26 '13 at 6:39
  • 2
    I am all but a lawyer, but it is my understanding that dynamically linking against a library does not make your code a derived work. Otherwise, it would be impossible to distribute anything under, say, a BSD license that dynamically links against something that may be under a GPL license. Static linking is a different story though, and of course you cannot redistribute the dynamically-linked library itself under anything but GPL. – tdammers May 26 '13 at 10:13
  • 4
    @tdammers: AFAIK linking dynamically does make code a derived work, and you are correct, it is probably not possible to distribute software under BSD license when it uses GPL libs. That's why lots of open source library authors offer their libs under LGPL instead of GPL. – Doc Brown May 26 '13 at 13:15
  • 2
    @tdammers: For the purposes of this scenario, I'm taking Stallman's approach to linking: both dynamic and static linking violates the GPL. – Michael Kourlas May 26 '13 at 16:05
  • 3
    @mouviciel There have been court decisions indicating that replicating an API for the purposes of interoperability is legal. I believe this has been found independently by high-level courts in both the US and EU, so the legal status is pretty solid (unless someone actively changes the law). – Donal Fellows May 27 '13 at 8:53

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.

  • 2
    My gut feeling tells me that lawyers will start poking harder if the company that makes A also starts advertising the A - C&D combo. – Bart van Ingen Schenau May 26 '13 at 14:25
  • 1
    @BartvanIngenSchenau: I agree. But I can imagine a different scenario: X distributes A-B, and Y only distributes (and advertises) an "add-on" C&D with an installer which replaces B in the install folder of A-B? – Doc Brown May 26 '13 at 14:42
  • I can imagine that alternative scenario as well, and it will be much harder for the lawyers to put a hole in if A and C&D come from different legal entities. – Bart van Ingen Schenau May 26 '13 at 15:52
  • 1
    @DocBrown: Does the existence of an equivalent proprietary library B even matter? Couldn't company X sell A by itself under the assumption that the end user would have to find a working library to use it, then "conveniently" provide them with D? – Michael Kourlas May 26 '13 at 16:31
  • 1
    @MichaelKourlas: the existence of lib B would make it much harder for the vendor of C to sue X, since it makes it easier for X to proof that A is not a "derived work" of C. – Doc Brown May 27 '13 at 7:17

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.

  • Whether or not the end user has to install the GPL component is irrelevant. Proprietary kernel modules that include GPL wrappers typically distribute the GPL component in source code form only, and require the user to compile them. DKMS automates this. That takes advantage of a different GPL "loophole", which is that you may do anything you want with a local copy of a GPL program, as long as you do not redistribute it in object code form. Since end-users typically do not redistribute the Linux kernel together with proprietary kernel modules and compiled GPL wrappers, they are generally safe. – Clement Cherlin Mar 18 '18 at 22:05

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.

  • Couldn't the API problem be fixed by including a wrapper module that you own the copyright to? (see windyroad.com.au/2006/04/20/… for an example of what I'm talking about) – Michael Kourlas May 26 '13 at 5:54
  • I've updated the question to add the wrapper component. – Michael Kourlas May 26 '13 at 8:20
  • @user92103 Does this FAQ address your question? gnu.org/licenses/gpl-faq.html Or this P.SE question: programmers.stackexchange.com/questions/50118/… – apsillers May 26 '13 at 14:32
  • 1
    @apsillers: The P.SE question deals with client-server communication over a network. While that is certainly a possible way to circumvent the GPL, it's what I'm talking about here (dynamic linking). I looked at the GPL FAQ, and they do have a question dealing with a wrapper module, but that question assumes the distributor bundles the GPL library with the proprietary application at the point of distribution. In this case, the end user is doing the bundling, which changes things dramatically. – Michael Kourlas May 26 '13 at 16:33

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.