Hi people of JUCE!
I’m wondering if it’s possible to release an open-source plugin in AAX format under the GPL3 license. Is it just necessary to download the AAX SDK?
Would be nice if JUCE would ‘allow’ non-GPL complaint open-sourced AAX.
But… with current license, my open-source plug-in should be compiled with:
AU, VST3 - GPLv3
AUv3, AAX, VST2 - Personal plan as all those will end up with non-GPL complaint code.
While I don’t mind having the JUCE banner. it’s currently very intrusive and not customisable.
But I guess that’s another feature request. 
At least the tracking (from JUCE5) was removed.
So do you mean that there are open source licenses other than GPLv3 that are compliant with the AAX license terms but GPLv3 is not? Never read through the legal part of AAX as I’ve only looked at AAX from the viewpoint of a developer working in a company that releases AAX versions of closed source plugin, but I’d like to add an AAX version for my private open source GPLv3 plugin at some timepoint, so I’d be really interested into what is possible here from a legal point of view 
1 Like
Yeah, I desire to know more about this too
I am not sure I understand the problem. You can publish the source code with no problem under GPLv3.
JUCE is compatible with GPLv3 IIUC.
Surely you cannot distribute the AAX SDK. But anybody in the Avid developer program would have no problem building and signing it themselves.
Anybody else would have no chance to use the plugin anyway.
But: IANAL
I’ll clearify.
AAX isn’t compliant with GPL.
But if juce had a more permissive “closed source” license for building AAX/VST2/etc as long as standalone is GPL compliant and the product is non-profit it would’ve been great.
As I’ve wrote above. Workaround now is use personal license that enforces showing the JUCE splash without modifying/stylizing it.
Still I wonder what exactly I have to do to actually violate the AAX license.
Currently, my CMake build script is set up in a way that if I passed the AAX SDK to it as an argument at configuration stage, it would be able to build an AAX version. This code is released open source under GPLv3, but currently I’m not using that option.
Does this already violate the AAX license? If so, I wonder how the AAX specific parts in the JUCE codebase could be compliant.
So, if I built VST3 and AU with public build scripts on GitHub action and built an AAX version with the option described above locally on my machine and released that binary as a download on my website along with the VST3 and AU built “in public” I would be allowed to state that the VST3 and AU versions are under a GPLv3 license but would not be allowed to say that the AAX version is under a GPLv3 license due to the AAX license terms? So to satisfy the AAX terms I had to release the AAX (even if built from the very same sources) as a pseudo closed source plugin under the JUCE personal license and add the splash screen to not violate the JUCE license terms for the personal license, right?
Now, would it still be okay if the AAX build would run in public on GitHub Actions and not expose any AAX code by pulling the precompiled AAX SDK from a private Git repository during the build?
→ What’s the legal problem? The act of building something from GPLv3 sources or the act of distributing binaries under the GPLv3 license?
1 Like
From what I understand, with GPL, if you build AAX, you need to provide the source code for AAX.
Anything that complies and links with GPL needs to be exposed upon request.
(LGPL though is a bit more permissive).
Just a reminder, open source doesn’t mean GPL.
so for example, I can have opened source plug-in using iPlug2 with AAX and even use GitHub actions keeping aax as a secret without violating anything.
4 Likes
Thanks for the clarification. So it’s basically the problem of distributing a compiled AAX plugin as GPLv3 as this would mean that I need to supply the AAX sources on request.
@reuk So is there any simple mechanism in the JUCE CMake functionality to enable the splash screen only for the AAX-Target to create an automated build that satisfies those requirements? I just know of the JUCE_DISPLAY_SPLASH_SCREEN define which is reflected during compilation of the shared code target and therefore is not suitable to enable the splash screen for AAX only if I get it right?
1 Like
No, there’s no built-in function which will simplify applying different preprocessor flags to different plugin targets. Also, in the case of the JUCE_DISPLAY_SPLASH_SCREEN flag, the flag affects the implementation of the shared-code target, which means that its effect will be visible in all targets which link the shared-code target.
The simplest way to enable the splash screen for AAX only would be to call juce_add_plugin twice, once for the AAX target and once for everything else. Then, enable the splash screen on the AAX shared-code target.
2 Likes
So, just to understand better, could I share the open source code of my plugin on Github (just the source code without the AAX SDK) and distribute the AAX compiled for free by using the Personal Juce license?
I’m newbie with AAX. How can I obtain the AAX SDK and Pro Tools Dev for non-profit projects?
I think Avid doesn’t care if you make a profit of it. They want to know that your program is a worthwhile contribution to the platform. Remember they sponsor their developers with NFR licenses and such, so they have a reasonable interest.
Just answered the same in this thread including a link to their dev program:
1 Like
Wow! I was watching that thread now!
Ok, nice. So I need to email AVID and ‘Apply for Commercial Licenses’.
I will try!
Will they accept a person that just experiments with virtual analog algorithms? 
The main interest is that it will be publicly available and that their users have a benefit from using that.
If you can bring that across you have a fair chance.
Having already one or a few plugins done that are available, as well as a professional looking website helps a lot.
1 Like
I think @Daniel is totally right here, although I want to report that you can even get into contact with them before having a website etc. – I always got fast and friendly replies from them and sending them a screenshot of e.g. a VST version of your plugin with a few words on your concept seemed trustfully enough for a first successful contact.
But if you are just starting on your project and are in a prototyping phase, there is little benefit in applying for an AAX License at that point. JUCE makes it super easy to port a up & running plugin project to AAX and while I personally like Pro Tools for mixing, I prefer mostly every other DAW for plugin debugging purposes, as the NFR version of Pro Tools which you’ll need to test unsigned plugins has a few restrictions, so my advice would be to better stick to developing a great plugin first and once you are nearly done with the development part, get in contact with AVID.
1 Like
Thank you very much @daniel and @PluginPenguin !
I’m wondering if the steps that I did up to now are correct and if I’m on the right path to ask for the AAX SDK and the NFR version of ProTools, starting from this: