NAM Juce port

I have ported Neural Amp Modeler to Juce & I thought some of you might find this useful. I’m still using the original resampler from iPlug 2 & the nam core ofcourse. Check it out here: GitHub - joeloftusdev/NeuralAmpModelerJuce: Complete port of NAM to Juce

Ooops … the repo disappeared. Interesting project though!

Link works for me?

At first it wouldn’t let me clone the repo and then the repo completely disappeared, and now its back again. I’m guessing you might’ve been changing the configuration meanwhile …

Anyway thanks for sharing, this is a fun plugin to dig into.

1 Like

Shouldn’t the project be AGPL-3.0 licensed since you are using it under the open source terms of the JUCE 8 license agreement?

(I understand that you want it to be more liberally licensed, but that’s not possible in this way afaik)

I didn’t think about that, my bad. Repo is updated with the correct license.

JUCE 8 is AGPL, not GPL.

So as I understand all projects derived from it should be AGPL as well.

The submodule is now on the last commit of Juce 7.

1 Like

Check, alright then :+1:

If that were true, there would be no MIT or BSD licensed projects based on JUCE.

There was no need to change the license. MIT was fine. It’s also how the the original NAM is licensed.

@joeloftus Thanks for sharing!

Original NAM wasn’t based on JUCE.

Can you explain how you can have a project based on a “viral” license that then doesn’t get the license?

You can absorb MIT/BSD code into GPL, but not the other way around.

If I understand correctly, the OP is not modifying and re-releasing the JUCE codebase. Rather the OP’s work consists in changes to an MIT-licensed project to make it compatible with JUCE. I think such work can be licensed in any way which is compatible with the MIT license?

All of these projects are based on JUCE and are open source, but few are AGPL-3.0 licensed:

1 Like

AFAIK, the repo itself (which does not contain JUCE code) can be licensed under any license. However, for the released binaries, you could choose

  • either JUCE open source license (e.g., GPLv3 for JUCE 7 and AGPLv3 for JUCE 8)
  • or JUCE commercial license (e.g., free starter license)

BTW I am not a lawyer :slight_smile:

Neither am I :smile:

Yes, for the released binaries that seems correct.

These are source licenses so the project itself has to be licensed as such. It doesn’t make sense to license a binary GPL :stuck_out_tongue:

@aamf JUCE8 is very new so everything before that would be GPL-3.0

Any opensource project based on JUCE (using it as a base to build the project) cannot be MIT licensed, so these open source projects are not correct in using something else.

I see a number of templating projects that do not use JUCE directly and those can be licensed anyway they like of course (so someone could use them for a proprietary product using the JUCE commercial license).

As said you can always include MIT/BSD code into a GPL project, but not the other way around.

Technically, I think if he put MIT license in his repo, he could choose to release his code under MIT license and release the whole project under JUCE starter license. As a result, the entire project is not open-source.
But I might be wrong, dual licensing is too complicated for me. Without doubt GPLv3 for JUCE 7 is the safest choice.

I know that conceptually it feels like that is how it would work (“I license my own code however I want”), but no that’s not how the GPL is constructed.

This is what people refer to as the “viral” nature of the GPL, in that it “infects” other projects with the license. This has always been intentional.

If you base a project on JUCE you can use one of two licensing options: (A)GPL (8 or <=7) or the commercial/proprietary license.

In this case NAM is the MIT licensed sub-project and this JUCE port is the “whole project” that falls under the JUCE license restrictions.

1 Like

Thank you all for the clarification I’ll stick with JUCE 7 and the GPLv3 for this. I simply made this opensource as I and many others have/continue to use NAM in closed source software which is almost always with JUCE. I thought by releasing a JUCE version that is functionally the same as the original it could help some people out & save them porting all the original code themselves.

1 Like

@joeloftus Thanks for your contribution. Sorry for being off topic as I am also curious about the license issue :joy:

1 Like

https://www.gnu.org/licenses/license-compatibility.en.html