I am not seeking or in need of legal advice, but an interesting though experiment came to my mind.

Imagine the following situtation (I cannot really think about a concrete example and I am unsure if a real manifestation even exists): there is a free (libre) api A licensed under some permissive license or even LGPL. Non-free application B implements this api in order host plugins, but there are other free software doing the same thing. Moreover, there is plugin C acting as a plugin under api A. It links to library D, that is under GPL, so C is also under GPL. Plugins using A are loaded into hosts via a dlopen-like mechanism and use complex data structure for host-plugin communication. Neither B nor C distribute any files that may be required for A to function properly (like headers containing the structure definitions of A or dynamic libraries containing helper functions for A written by the authors of A), but such things may exist.

Now some user installs application B and plugin C on his machine, along with anything that may be required for api A to function properly. Then he proceeds and loads C into B and creates some intellectual property with B which is not a piece of software.

Did a GPL violation happend at some point, and if so, who violated GPL and why?

  • The authors of C violate D's license by making C possible to be used in non-free host B? This is a possibility because they can't give and exception of GPL (like one described in http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF or http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface) due to D's license terms.
  • The authors of B violate C's and D's license by making C possible to be loaded in B? This is a possibility because http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins disallows the mechanisms A uses for communitation between the free and non-free modules.
  • The authors of A, because the api may be used (and in this case, was used) for communication between GPL'd and non-free software. This would be extremely absurd.
  • The user, because at the moment of loading B into C, he made a derived work of C. I think this is impossible, because he does not distribute it. But would the situation change is he decided to release a configuration file of B which makes B load C as a plugin?
  • Nobody, because A counts as a 'system library', and both B and C directly interact only with A, not eachother. In a sane world, this would happen...

A concrete example of A could be some kind of audio (think LADSPA) or image processing api. However, I could find no such interface (that is free software, generic and is also implemented by commercial tools). A real-world example could also be quite enlightening.

  • I believe that the second point is also absurd (the FAQ entry is clear, but absurd). GPL was nowhere near A and B, and third-party decides to create an implementation covered by GPL - how can that possibly have any implications to B (or even A)? No one is responsible for someone else's actions. Commented Apr 6, 2012 at 8:25
  • Of course it is absurd, I added it more for completeness's sake than for anything else. However, if C had been around for some time when B got written, some extremists could say B supports A solely to take advantage of C and D without following GPL. Commented Apr 6, 2012 at 15:46
  • Even if they are crazy enough to take the case to court, they don't stand a chance. Idiots gonna idiot. Commented Apr 6, 2012 at 15:58

4 Answers 4


Given your description, I think A and B is irrelevant to the question, what matters is C and D, and the question comes down to whether or not GPL allows dynamic linking. If anyone may violate the GPL, it is C if it is not under GPL.

The situation

After some digging around, I found that the Wikipedia GPL article has a good summary of the issue. The answer is: it is disputed. The three existing standpoints, according to this article:

  • Both dynamic and static linking violates1 the GPL. This is the standpoint of the makers of the GPL (the Free Software Foundation), and they created the LGPL for this reason (to allow dynamic linking without violation).

  • Static linking violates, but the GPL is not clear about dynamic linking: It is hard to tell since the GPL does not provide clear instruction about what is considered derivative work.

  • Linking is irrelevant: GPL should only apply to source code-level. In my opinion this is the most sane option, since linking to a software to access its functionality is akin to pushing a button on a GUI to do the same thing.

Since the FSF says its intention with the GPL is to disallow both, I think it is wiser to either

  • respect that intention and use GPL on your own work if you link to GPL, even if the wording is not clear

  • or stay away from GPL software

Ironically, the GPL is not as free/libre as one would think. I know there is a reason for that, but my point is: don't put GPL on your software without thinking. If you are looking for a free and permissive license, the MIT or BSD licenses might represent your intentions better.

1: when I say "violates" I mean it violates iff the "consumer" of the linking is not under GPL.

  • I only added D to the situation so that C has a GPL (or equivalent) license with absolutely no exception. However, the way B loads C is also dynamic linking... Commented Apr 6, 2012 at 15:36
  • Yes, but see my comment on the post. It is totally absurd to hold B's creators responsible for something that C decides to do (namely, use a GPL-compatible license). I've read the FSF FAQ that you cited, and yes it says that, but I'm pretty sure that's impossible. C is the third party, and nor A, nor B is reponsible for his choices. Commented Apr 6, 2012 at 15:41
  • +1 for last paragraph. BSD/MIT are so simple that any legal departement can say yes in less than a day. Commented Apr 8, 2012 at 7:05
  • It is not B's or C's creators who are held responsible. In fact, note that creators are never responsible, only distributors. In any case, the only case of violation would be if someone distributes something that requires both B (not just the API A, but really the program B) and C. Commented Jun 28, 2013 at 8:16

The GPL was not violated by anyone. A GPL violation only occurs when code is "distributed", i.e., transferred from one party to another. The only code that changed hands in this example was B, C, and D. The creator of C honored D's requirement that C be distrbuted under GPL. The creator of B did not distribute C or D, and is not responsible for the fact that the user combined it with C and D, creating a hybrid system. So long as the user does not distribute that hybrid system to anyone else, the user is not violating C's or D's GPL terms.


Real world examples:

  • Motif API and it's various implementations Motif (proprietary), OpenMotif (Open Group Public License), LessTif (LGPL). Libraries are drop-in replacements, you can dynamically compile your code with OpenMotif and run it with LessTif or vice-versa.

  • Proprietary Linux drivers — in most cases to avoid licensing issue there is thin (L)GPL wrapper which loads proprietary code. Wrapper unique purpose may be separation, like example Nvidia's binary driver, or separation might be just a side effect, like for example in case of NDISwrapper.

  • I think it is the reciprocal (GPL code loading proprietary code) of what I describe, but nevertheless quite intresting. Commented Apr 6, 2012 at 15:39

I believe this is a loophole that allows non-gpl code to use gpl code. The one example I know of the the vlc active x component. VLC is gpl. VLC activex component is GPL as well. Any windows app that can load activex components can load the vlc activex component without sharing any headers or code. I think it's your last bullet point that applies.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.