About sharing Juce under GPL

Hello, everyone

I am using Juce under GPL license for my open source project. In my build instructions, I just wrote “Download and install Juce” as the first step. However, any user unfamiliar with Juce who would just download and install, would soon enough find the polemic splash screen / usage analytics issues, since Projucer is not built with GPL license by default.

Therefore, in order to save time and headaches for potential users of my open source project, I would like to add the source code of Projucer in my repository, already modified to be built with GPL, as well as pre-built binary for Windows and just the necessary Juce modules (not to burden the repository). My question is: is this legal under the GPL license usage of Juce? I know that my project is forced to be GPL too, this is not an issue. Stating the GPL license details of Juce is not an issue either, and I would still link to the Juce website for anyone interested in downloading and installing the whole package.

I am sorry if the question is trivial, I am not familiar with GPL license details. Any information will be greatly appreciated.

I think it is a valid process. As long as you distribute everything under the GPL, in whatever manner, it is OK (AFAIK).


Yes this is the correct process. The source code can be modified and re-used within a GPL project, you will simply need to keep the licensing information in place so that credits to JUCE are clearly indicated. I’d recommend linking to the JUCE 5 license agreement and JUCE 5 privacy policy in the README file as well.


If you use git, there is also the option to add juce as submodule inside your project. This way it is automatically included for the user, but you don’t re-host it.
Another advantage is, that you have control which juce version is used, because the submodule will refer to an actual commit in the juce history. (N.B. many consider this a drawback, I think it is a plus).

git submodule add --depth 1 -- https://github.com/WeAreRoli/JUCE.git JUCE
git config -f .gitmodules submodule.JUCE.shallow true

And set the modules path to ./JUCE/modules/

For you to bugfix you may turn off the shallow flag, if you want to / have to test against different juce versions.

And this together with the hints in the README as jb pointed out, seems to be the smoothest way.

1 Like

Thank you guys for the answers!

@jb1 I will definitely keep the Juce license info and forwarding to the website in place.

@daniel The submodule in github does not want in my case because I would want to do some modifications in the Projucer, but thank you for the suggestion.

I see, but you can still use your fork as submodule then…
That’s even better than linking people to the original JUCE and instruct them how to patch.

That’s how github collaboration works…

Ah, I see, you meant a fork. As I mentioned, I want to add in the repository just the necessary modules for my project, as well as the only extra which is the Projucer. Therefore, I find it more straightforward in this case to add these few bits directly in my repository, rather than create a fork and strip it to the bare bones :S

Ok, sure, that’s up to your taste…

If I were to use it, I would prefer to get it linked against the originals, because I can update anytime I think is appropriate, and I can also identify, which changes came from you and which come from the JUCE team…

1 Like

I see, thanks for your opinion. I will take it into consideration :slight_smile:

@daniel I wanted to let you know that in the end you convinced me to do it by adding a submodule to a Juce fork :). Since the original topic is solved, would you mind if I asked you a couple questions about the submodule thing via private message?

I would not mind if you continued the conversation here in the forum. This is interesting stuff. Thanks!

@soundbytes1 Understood. Let us at least move the conversation to a more appropriate thread, since the GPL related question has already been answered in this one.

1 Like