Releasing an open source JUCE plugin under LGPL v3 license – allowed or not?

I know, you are all no lawyers, but I hope you can still help me here… I’m about to release an open source JUCE plugin and I originally planed to release it under a GPL v3 license. Now, to be compatible with a third party lib dependency, this plugins needs dynamic runtime linkage on Windows. According to dynamically linking to Windows runtime libraries is allowed in general… But: They say

You may not distribute these libraries in compiled DLL form with the program

Now to make the installation process convenient for the user, I integrated the VC redistributable executable in my Windows installer. Works great, but I came to the conclusion that in order to do that I need to switch my license to LGPL v3. First of all: Is that right?

And in case that’s right, am I allowed to release a JUCE-based open source plugin under a LGPL v3 license or does that violate the JUCE license agreement? I really want to do everything as correct as possible here and I won’t earn any money with my project, this is purely to support the open source & musician community… so if you have any advice on how to do all this legally safe, please let me know :slight_smile:


(IANAL, and this is based on my understanding of the GPLv3. Feel free to challenge my assumptions.)

No, your Windows installer doesn’t have to be GPLv3 (, so you are free to put whatever you want inside it without changing the license requirements of your plugin.

The latter.

Thanks for clarifying this!

So to make my installer non-GPL, would I have to e.g. put it into an external repository to make the separation clear, or could I just license my installers sub-folder which is currently part of the GPLv3 licensed project with a matching license separately but let it live in the directory structure of the original project?

i am also very interested by this topic, i am like you, looking for the exact way of releasing a binary of a free vst plugin… looking forward… :slight_smile:

Having everything in the same repository is fine as long as it is clear which license applies to which files and bits of code. That’s why it is best practice to have licensing information at the beginning of each source file.

One thing to keep in mind is that your own code can be under any license that is compatible with GPLv3. Only the programs that combine your code and GPLv3 code have to be licensed under GPLv3 as well. So you could have your repository licensed under a permissive license (such as Apache 2.0), because you want anybody (including people who have a commercial JUCE license) to be able to reuse your code, while having your plugin (which is the combined work of your code and JUCE’s and many other third-parties) licensed under GPLv3.

Sorry if my reply gives you more questions than answers, but I think it is important to understand all the possibilities.

No I don’t think it gives me more questions than answers :wink: Thank you for clarifying this.

I went that direction you pointed out anyway, e.g. I put some more general functionality into a separate git submodule licensed under an MIT License, use GPL-compatibly licensed third party libraries and only licensed the very plugin specific sources under a GPL v3 license. Therefore, for some reasons I assumed that as the plugin as a combined work is GPL licensed, it needs a GPL licensed installer :wink: Anyway, I added a License file and a readme to the installer subdirectory that explicitly states that the installer is LGPL licensed now. But I’ll also go through all the source files and add a license header where one is missing, just to make this super clear :slight_smile:

I’ll share the project here with you in a few days, once I found some time for tidying up the git repo a bit…

1 Like