Bypassing the GPL

Question

Ok, here's the scenario. I want to develop an application that will be done in C#. The application core will be released under CC0 with some closed-source plugins ehancing non-essential functionality. Anyway, I plan to use a GPL library as back-end to one of the plugins, it will be released under CC0 like the core. In the end what I will end up with is esseentially a closed-source application that has functionality being provided indirectly by a GPL library.

My assumptions(IANAL) cannot be in violation of the GPL, because:

1. I do not link against the library - it's a purely runtime thing
2. The functionality is provided by a plugin under a compatible license
3. The plugin does not expose the library's interface - it implements a generic interface that will also be provided by other similar plugins.
4. As mentioned, the application does not depend directly on the library, it depends on plugins implementing an interface, one of these plugiins just happens to use this library.

With the above points, it's clear to be and my understanding that this is legal however controversial it may be even if I also distribute said library(unmodified) with my application for the simple fact that my application is obviously not a derivative of the library.

I want to know, are my assumptions correct? I'm in doubt because I don't really want to believe that there is such a gaping hole in the GPL right up there with communicating via IPC and RPC (other grey areas).

Answer 1

I think your assumptions are correct, but nobody here will pay for your liabilities if the answer is wrong.

If you are in doubt I suggest you to do two things (in order):

• Email the copyright owner of the GPL library you are talking about and explain what you intent to do.

If you do not get an answer, or you are not satisfied with the answer:

• Ask a lawyer.

IP licensing is important and you can get in serious trouble if you do something wrong.

Answer 2

http://jacobian.org/writing/gpl-questions/ "Twenty questions about the GPL"

Read this, although it's python related it's very interesting.

Answer 3

I plan to use a GPL library as back-end to one of the plugins, it will be released under CC0 like the core

If it's linked against a GPL library then your plugin itself will have to be GPL. The GPL FAQ says this isn't in general allowed:

Can I release a non-free program that's designed to load a GPL-covered plug-in?

It depends on how the program invokes its plug-ins. For instance, if the program uses only simple fork and exec to invoke and communicate with plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program.

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. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.

There's also an explicit no to using GPL for an Eclipse plugin, which resembles your scenario.

---

there is no linking(compile-time, basically, there's no linking at all the binding if will is provided at runtime by mono

IANAL, but I suppose it boils down to whether the interface is GPL or not.

If you write .net code that invokes GPL licensed classes/methods, your plugin is clearly a 'derivative work' since it depends on the library in question. This is why the Java API is released under a GPL license with an exception.

However, if your code merely asks Mono to please parse this XML document and Mono in turn happens to use a GPL licensed parser to do that work, your plugin isn't really linking against said parser and so is not affected. Same thing goes for the if the program uses only simple fork and exec example in FSF's text above. In this case the interface is a simple command line and not specific to the GPL executable in question.

Answer 4

Strangely enough, I agree with both Pierre 303 and Martin.

• My reading of the GPL/LGPL combined with my knowledge as a software engineer (IANAL!) is that the GPL does not automatically project across dynamic linking.

• The people who are most likely to sue you for GPL violations publicly believe that the GPL/LGPL to project across dynamic linking.

If you end up in court talking to a judge you have effectively already lost. It's like the story of the military combat instructor "ok, we've both got our knives and we're ready to fight, what mistake are we both already making? WE'RE IN A KNIFE FIGHT!".

My logic for the first bullet above:

• The GPL/LGPL cover combined and/or derived works.
• The GPL/LGPL is a DISTRIBUTION license.
• A dynamically linked combined work exists only temporarily during execution time, and is never distributed.
• Thus shipping a dynamically linked program is not shipping a combined work.

An additional argument is that GPL advocates never claim that running a GPL program on a non-GPL operating system and dynamically linking it with the local C runtime library brings that C library under the GPL. I don't see the difference in what is happening in this case.

Keep in mind that I'm not anti-GPL. I just think that things are more complicated than they've managed to write the legal language to cover.