Understanding modifying or copying framework code

Hi there. I’m sorry if this is covered multiple other places, but I have searched and not really found the answer to what I’m looking for in a format that really spells it out.

My current case is that I am building a plugin based on JUCE. I’m currently experimenting with it and not distributing anything at all with the free version. I do intend to distribute, and before I start doing that, I will be paying the Pro perpetual price.

The main question I have is that I don’t fully understand the licensing in how it relates to modifying or copying existing framework code, assuming that I have paid for the full pro licensing. The problem being that as one example: many of the existing DSP classes are great starting points, but they tend to have important variables to expanding functionality set to be private and so forth.

What are others viably doing to (legally) leverage this code commercially?

You’re allowed to modify the framework code, provided you abide by the license terms. Keep in mind that making changes to JUCE might make it more difficult for you to incorporate new features and bug fixes from the official repository in the future.

If you’re using one of the commercial license options (including the Pro license), you can make whatever changes you like. You do not need to publish these changes.

If you’re using the GPL license, then your modifications must also be GPL. If you distribute a program using JUCE under the GPL, you must be prepared to share the entire source of the program (including any modifications to JUCE) on request.

1 Like

Thank you for the clarification on that. I am aware of the problems with merging upstream changes, and I plan to only modify classes at a level that aren’t used by other JUCE classes, which makes things a bit simpler in that regard. Still, my preference might be to copy the classes I want to modify into my own namespace, to maintain them separately anyhow.