I want to write a plugin for a software that will not be licensed with GPL.

However as this plugin needs to communicate with OPC, I wanted to use the .net standard OPC stack. This 'program' is licensed with GPL V2.

My question is whether my plugin which is a new C# Assembly can use the GPL licensed DLLs while not affecting the main program's license. (The plugin itself can be distributed with GPL V2 if needed to, but we would not prefer that)

The main application would load the DLL and use the data it gets from there (unknowing which DLLs it really uses and without access to those GPL licensed DLLs)

I already found this in the GNU FAQ, but I'm not sure if this is a clear case and I can continue to implement this way, or if I should organize a professional to check it.

EDIT: Sorry if my question was not clear but confusing to you. -The main application should be non-GPL and it will load the plugin dll which in turn loads the GPL dll. My question is if the main application is now influenced by this. It may be possible to have the plugin dll GPL also but not the main application. The main application will resolve the plugin dll with dependency injection and therefor the plugin will reference some core dll that holds interfaces for that.

  • 3
    Can you please clarify how the "main application" interfaces with plugins? Does the main application load your plugin DLL, which in turn loads the GPLv2 .net OPC stack DLLs? Or does it work in some other way?
    – airfishey
    Commented Dec 7, 2017 at 15:09
  • Is it a GPL'ed main application + Non-GPL plugin, or is it a non-GPL application + GPL plugin? If the application is not GPL, is there any restriction in that application's license that would prevent you from making a GPL-licensed plugin? Presumably you will only distribute the plugin under the GPL in that case.
    – Brandin
    Commented Dec 8, 2017 at 12:00
  • non-GPL application + GPL plugin (The plugin will load a GPL licensed dll that is referenced via nuget packages). So the licensing of the plugin can be both (So publicly it would be GPL but not for us internally, so the main application can stay non-GPL).
    – ShinuSha
    Commented Dec 11, 2017 at 8:17
  • Is the main application something that you (or your company) has control over, or does it belong to a third party? That can be a factor in how people look at the situation from a moral perspective. Commented Dec 11, 2017 at 16:18
  • There is a rule of thumb. Technical cheating tricks don't work. And courts apply that. Commented Dec 12, 2017 at 7:03

2 Answers 2


You said the main application will

load the plugin dll which in turn loads the GPL dll.

As implied by the DLL name (dynamic-link library), loading a DLL file is dynamically linking. We can determine the licensing propagation by working our way backwards from the GPLv2 DLL.

Your Plugin DLL + GPLv2 DLL Analysis

Since your plugin is dynamically linking against the GPLv2 DLL, the combined work (your plugin + GPLv2 DLL) is also subject to the terms and conditions of the GPLv2. See https://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic, which says:

Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

Main Application + (Your Plugin + GPLv2 DLL) Analysis

Now, you said the main application loads your plugin's DLL, which is also dynamic linking. Once again, this dynamic linking makes the combined work of main application + (Your Plugin + GPLv2 DLL) governed under the terms and conditions of the GPLv2.

My question is whether my plugin which is a new C# Assembly can use the GPL licensed DLLs while not affecting the main program's license.

The answer is no, you cannot do this with your current architecture.

It may or may not be possible to re-architect your plugin strategy to achieve your licensing goals, but that depends on what the plugin framework allows in terms of spawning additional processes or interacting with external processes. However, that warrants a new and separate Stack Exchange question.


I am a tad confused by your question wording, but I think you say: I want to write a non-GPL-licensed plugin for a GPL-licensed framework.

The short generic answer is that this cannot be done, unless there are exceptions in the framework GPL licensing that would allow this explicitly.

  • 2
    My reading is the other way round: a GPL licensed plugin for a non-GPL framework. Commented Dec 8, 2017 at 17:47
  • No. My main application has to be a non-GPL licensed one. The plugin will load the GPL licensed dll. The plugin might aswell be GPL licensed then but I would still prefer not to. (The plugin will mainly be a wrapper class with some additional classes the main application uses to communicate with it)
    – ShinuSha
    Commented Dec 11, 2017 at 8:16

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.