Site navigation

Should the community consider a JUCE fork?

General JUCE discussion
#1

many folks are finding the licensing terms for JUCE-5 to be quite dis-tasteful - but the purpose of this post is not to discuss them but only to point out that the new imposed anti-features only serve to make it increasingly difficult to maintain a freedom and privacy respecting JUCE program

to be clear - although the new terms do not actually state this - what is most likely the case is that all of those new rules apply only to developers who want to release closed-source and not at all to GPL programs developed with JUCE

PLEASE CORRECT ME IF I AM WRONG - and i will stop using JUCE immediately for any purpose and port every JUCE program i have to another toolkit

all it actually says to this effect is: “if you exceed some revenue limit” then “you MUST release YOUR program as the GPL” - what it does not say is: “you may simply choose to take JUCE under the GPL and ignore the rest of these odious terms entirely”

but i do suspect that is still true - unfortunately nowhere in the agreement does it actually say that and o/c none of us developers are lawyers - so the end result is that it is quite disturbing for most of us to read

again i do not care to debate these new terms - i only wish to propose a fork to remove them and the accompanying anti-features for the sake of FOSS developers

JUCE-3 and 4 were already quite a PITA to use properly for GPL programs and for years i have been maintaining a fork that makes JUCE more GPL-friendly - this would be just 2 more anti-features to remove and maintain - but how many more are coming? will JUCE-6 force advertisements on end-users? what will i need to remove next year and the year after that?

the more cruft that must be removed makes for a larger maintenance hassle across upgrades - at some point it will no longer be worth the trouble - so perhaps if some others want to help me maintain a freedom and privacy respecting fork i will continue - but if i must do it alone i will probably just stop using JUCE soon

JUCE 5 Licensing - What We Know [Community Edition]
We may track the IP addresses associated with their use of the Applications using JUCE
#2

As has been said in other threads, at the current moment these anti-features can be disabled with extremely simple #define statements. I definitely don’t think there’s a need for a fork right now (if there was I’d be the most gung-ho about spearheading it I think) but maybe in the future depending on how things go.

Unfortunately I don’t trust ROLI not to remove the GPL licensing option (i.e. any compiled JUCE must be under one of their compiled licenses, redistributing source isn’t allowed, like the VST or AAX SDKs). If they did it would render the efforts of a community-driven JUCE fork somewhat moot since the majority of the updates for the fork would still rely on ROLI’s work.

One thing I have considered, however, is making a fork consisting of only ISC-licensed bits (which is like a third of the library at this point, and a lot of it is extremely useful) under a CMake build system. i.e. a totally free community-driven distribution of a set of audio tools built from (and including) the ISC chunk of JUCE.

1 Like
#3

Don’t panic.

The logic behind this is actually a great benefit, a giveaway. It says you may start out with a commercial closed source project and they are waiving the license fee until you reach a revenue limit. It’s a very generous offer that helps indie developers getting started without investing money up front. Only if you exceed the revenue limit of the personal license (basically a license fee waiver), you’ll need to decide whether to upgrade your personal license to indie (pay a fee), or go GPL.

I doubt anyone making north of $50k will want to go GPL at that point. This clause just points out that going GPL would be the only option left to avoid the license fee.

(please anyone correcty me should I be wrong)

1 Like
#4

I can’t really think of any reason why we’d ever choose to do that. The GPL/commercial option has worked really well for us, and not even our lawyers ever suggested changing it! We want to encourage people to use it under the GPL, not stop them.

Forks are also a good thing - our github repo already has over 400 of them!
If someone came along who took a fork and did such an amazing job of maintaining and developing the codebase that other people started to prefer their version to the original, then that’d be (a) surprising! and (b) actually great for us, because we’d also benefit from their work! (or offer them a job)

4 Likes
#5

@ans

i did not intend any panic at all - it seems you mis-understood my concern - i had already fully understood what you explained but i want my programs to be open-source from the very start and so none of that actually applies to my use case

the point i was making (and the one that you completely missed) is that the new agreement says only that if you make too much money selling a closed-source product made with JUCE then you MUST use the GPL - but it should also say that these new rules apply to you ONLY if you want to release closed-source - or else you may still use JUCE entirely under the GPL - but it does not so much as indicate that option which is confusing - it is left only to experienced GPL users to infer on their own that this has not changed since version 4

#6

@jonathonracz

i admit that i posted this thread a bit hastily after i read the new agreement but before i actually looked at the sources - indeed someone pointed out to me later that these new features can be easily disabled for GPL programs which makes them essentially non-issues

as i said though, i already do maintain a fork that makes JUCE easier to use with a GPL/gcc/Makefile workflow and i have mentioned it a few times already over the years on this forum

my main purpose of this thread was not so much to suggest a new fork but to entice others to help me maintain the one i already have started - as jules points out, forking need not be seen as a cause for panic nor was this post prompted by panic - forking can be a very healthy thing for a project - for example, my claim is that JUCE is less than ideal for maintaining the typical GPL program and if my fork helps to ease that situation for others then perhaps more developers will be tempted to use JUCE for GPL programs and the wider community grows

#7

That’s not entirely correct. The terms actually say:

Once your business hits the Revenue Limit for your JUCE license, you will either have to upgrade your JUCE license or release your Applications under the GNU General Public License v.3, which means, among other things, that your code can be freely copied and distributed.

Which is very different. It would be suicidal if ROLI were forcing businesses to release their closed source software as GPL if their revenue is too much :wink:

#8

@zioaxiom

indeed - that was not entirely correct - i am regretting even to mention it now that multiple people have completely missed my point - i should have added “… then EITHER you MUST use the GPL OR you MUST pay us” - but again i was not confused by that nor intending to debate those terms

the point i was making is that this is presented as the only path that can be taken:

  1. write a closed-source program
  2. make 50K
    3 then choose between paying ROLI or releasing as open-source

the path i want to take is this:

  1. write an open-source GPL program
  2. be happy that i have shared something awesome with the world

although that second case is a valid option that many people may like to choose, it is not presented as an option in the JUCE-5 license and only the astute GPL user would be able to infer it - that was the only reason i mentioned it

#9

You say you’ve been maintaining a fork that is more GPL friendly? What is the difference?

#10

there’s a short changelog on this README

not having the license headers clobbered every time you save the jucer is reason enough for me to use it

#11

Hi Bill,

I am not sure why you think that we are forcing people into releasing closed-source projects. JUCE 5 is entirely available on GitHub and there is a mention of the GPL in the log-in section of the Projucer. We have no intention to change things around the GPL license.

You are most welcome to take the path of writing an open-source GPL program using JUCE and share it.

1 Like
#12

i do not think ROLI is forcing anyone to do anything - i tried to make that very clear that i fully understand the terms and i do not disagree with them - it seems like a very good deal and low barrier to entry for aspiring commercial developers

i only meant to say that anyone reading that document who never used JUCE before and is not familiar with the GPL would be fully led to the impression that the only path to the GPL option is through the “personal license agreement” - this person is not likely to then go and download the projucer as it is usually the case that downloading and using some software is tacet agreement to some of it’s terms - and only then could this person find out that they can take JUCE under the GPL from the very beginning without entering any other agreement

case in point - on this web page --> https://www.juce.com/get-juce - there should be a 5th column:
"Open-Source Option (NO STRINGS ATTACHED)"
* ....
* spashscreen (optional)
* phone home (optional)
* revenue limit (not applicable)
* ....