This is based on this post and it seems that we should create a new topic.
I know you are not lawyers. So feel free to share your opinions. As some repos are licensed under MIT, I think this might be helpful to them. The problem is as follows:
Is it allowed to release the plugin code as a MIT/Apache-licensed github repo which keeps JUCE 8 official repo as a git submodule?
Of course, the plugin is a normal JUCE plugin which uses JUCE 8 as a library (e.g., via CMake approach). And once I release the binaries, I can choose AGPLv3 or JUCE commercial license. If you want a real example, here is a repo I use for testing JUCE 8 GitHub - ZL-Audio/ZLTest
Not a lawyer, but I published the source code of some of my JUCE plug-ins as MIT licensed. JUCE itself is not included in these repos, not even as a submodule. I do not provide binaries for these plug-ins.
The reason for using MIT is that it allows people to use the same code with frameworks other than JUCE (which obviously requires rewriting some of the code).
Of course, if someone wants to build the plug-in from this repo and distribute it, they’ll need to publish the combined work under the GPL or use a commercial JUCE license.
As far as I can tell this satisfies both the letter and spirit of the JUCE license. As long as you’re only sharing code, it just needs to be under a GPL-compatible license. (Sharing code under an incompatible license would also work, it just prevents someone from making a GPL licensed version and wouldn’t be open source.)
If you’re including JUCE as a submodule then I would suggest informing the users of your repository of JUCE’s licence too. This should help avoid any surprises later on.
While I understand the intent here, for full projects it probably makes more sense to dual license MIT/BSD and GPL.
This way it’s more clear how the repo can be used. In the case of MIT/BSD it really only makes sense if you have a proprietary JUCE license and for FOSS binaries one would use GPL.
