Awkward question #1: So if I develop a module and offer it to the JUCE community - does anyone offering a commercial product that uses my module then have to pay a license seat because of my contribution?
Awkward question #2: if I want to offer a closed source application for free use (& without splashscreen), do I require an Indie (or Pro) license?
Awkward question #3: this isn’t new to the v8 licence, but clause 11.8.3 is curious. Why is half the world’s population subject to Californian state law? For a library which resolutely retains its English spelling heritage, it’s a bit rough to force us to read up on American law
I agree with Peter. The Indie/Pro threshold change is galling for those who earn the vast majority of their income in an unrelated field.
I wouldn’t be too bothered if the income test was related to JUCE derived software or corporate income - but capturing personal income unrelated to JUCE means that you are penalising some hobby developers who prefer to release close sourced apps for free use by the community.
I’m joining the thread a bit late and I’m confused. The 10usd increase of the indie license is totally fine however the change of terms is quite worrying.
Wouldn’t it be more reasonable to attach the number of JUCE licenses needed for a vendor to the number of products built with JUCE? IMHO the revenue of a vendor comes from the products offered not from the number of developers involved in their creation. I think that a lot of freelancers here are very worried because unfortunately it is very common that a vendor changes the contractor several times during the development of the same product.
I also think that the revenue shouldn’t be the general revenue of the company but what is generated by the products built with JUCE.
@t0m let me add one other case which I think is important, and I’ll make it an explicit example
melatonin_inspector by @sudara is an amazing bit of software adding the ability to runtime inspect and modify your JUCE UI. It is MIT licensed software depending on JUCE so it can be used to extend and improve your product in both open and closed source situations. It is clearly software derived from JUCE. Obviously deploying the software today requires either (1) your combined work is open source or (2) you have a JUCE license allowing you to deploy plugins for your self / your entity.
Until 5 weeks ago, there were 6 distinct people who had commits on the package according to the GitHub log.
Does this mean that each closed source system which uses melatonin inspector needs to buy an additional 6 licenses?
5 weeks ago the contributor count went from 6 to 7 (I added some of the tools we used to debug accessibility in Surge to Melatonin!). Does this mean that each closed source system which uses it would need to buy an additional license when upgrading?
I think an explicit explanation of how this particular situation should work with the proposed revised licensing scheme would be really useful. If all of a sudden you need (N-contributor) x (M-deployer) licenses for each open source JUCE extension, I think you will greatly hamper the creation of valuable open source libraries and modules around JUCE.
Thanks for your consideration! Happy to talk about this case on- or off- forum or just wait to see how it all shakes out. I’m sure you can find the right solution!
Exactly. JUCE 8 pretty much excludes incomers who would eventually want to release a product that earns just a modest amount in the beginning.
With JUCE 7 there was the possibility of displaying the splash screen and see if things work out. But now this is not possible. For small projects the fee is unreasonably high.
Under these new terms I wouldn’t have picked JUCE when I was choosing a framework to develop my first app.
Let me have another go at explaining the motivation for these changes.
The JUCE 7 EULA can be exploited. I’ve provided an example with Lua bindings that I thought communicated one of the kinds of exploits that are possible fairly well, so that people can get a feel for the kinds of problems involved. There are other ways of exploiting the existing licensing agreement that are much more damaging to JUCE as a business, and I don’t want to provide details on a public forum for obvious reasons. These exploits are threats to the ongoing operation of JUCE as a business and we need to address them. This will inevitably involve imposing additional restrictions on how people can use JUCE, but we cannot continue with these risks in place. Why are we making these changes now? One big driver is many fairly recent real-world examples of people abusing JUCE like this, and as JUCE has grown it has become more valuable, so the attractiveness of these exploits has also increased. I feel like I should stress again that there is a real risk to the ongoing operation on JUCE if we don’t take action. I realise that isn’t going to persuade the most cynical of you, but it is the truth. If you have interacted with any of the JUCE team you will know that we are all champions of providing as much value, with as few restrictions, as possible, so this is difficult for us. However, we also need to make sure that we can all continue working on JUCE and that means protecting JUCE as a business.
If you don’t understand or agree with the above, then none of the below is going to make any sense.
Contributing “content”
Every individual contributing to or modifying the source code, object code, content or any other copyrightable work that is part of software containing JUCE, or modifying the JUCE framework itself included in any software, requires a JUCE licence seat.
We will fix this. The main driver behind this change is a defensive one, but we can make some exceptions of:
Image files, video, fonts, etc (anything that is purely visual)
Audio files, MIDI (any static media)
Text (EULAs, translations)
Source code, software or libraries that are available to the public as an individual product
Presets - this will need some careful wording
We can add things to this list as required. We recognise that the current wording is problematic and we will change it.
We will not be making exceptions for:
Source code
Any kind of script
Anything that is interactive or adds functionality
UIs written in HTML/CSS/JS
This is an expansion of what is covered by a JUCE licence, but it is required to get the protection we need. We have attempted to make the scope narrower, but we have not found a solution or legal wording that gives us the necessary guarantees.
If this has really gone off the rails in a particular situation then we have a provision in the EULA that allows us to come to a compromise.
Licences for Product Owners
There have been several references to “double licensing” and I think we can get a bit more clarity with some examples.
Large company A has developed a plug-in that required 3 employee-developers all using JUCE. There was a time when all 3 developers were busier and working concurrently, but the plug-in is stable and only needs infrequent tweaking. In this case with JUCE 7, and all previous versions of JUCE, company A requires 3 Pro licence seats. With JUCE 8 there is no change here.
Large company B is in exactly the same situation except they used contractors to develop the software. It seems unfair that they would not also require 3 Pro licence seats as they are getting the same amount of value from JUCE. When they had 3 contractors all working concurrently they would require 3 licence seats, where those seats would be used by the contractors. The contractors themselves would not require their own licence seats. Those 3 original contractors finish their contracts and a new contractor is brought in for infrequent maintenance of the plug-in. That new contractor can use 1 of the 3 licence seats owned by company B. With JUCE 8 company A and company B both require 3 Pro licence seats for exactly the same product.
Under JUCE 7 company B would pay no JUCE license fees, and each contractor might* only be contributing a Indie licence fee each.
There are problems with the contractors being responsible for the licensing of their clients software, rather than the client being the owner of those licences, even if those contractors are using perpetual licences. The easiest target here is that once a contractor’s contract has finished, they do something illegal working for a completely separate company. Their JUCE licence is terminated, and their original client is now breaking the law if they continue to distribute the contractor’s work, with no mechanism for notification. Imagine being on the original client’s legal team and discovering that was possible. There are other similar ways of creating unworkable situations when the owner of the product is not also the licence holder.
*JUCE 7 and all previous versions also already have a line in the EULA about not combining content under different licence tiers. This means that if a contractor does some contracting work for a large organisation that already has a Pro licence then that contractor would be obliged to upgrade their licence to the Pro tier before they could contribute. I suspect that a few contractors are currently unaware of this requirement. Having the organisation be responsible for the licensing avoids this complexity and ensures there is no inadvertent violation of the EULA terms.
Licences for part-time work
This isn’t a provision that JUCE 7 provides explicitly. If a company needs some software development using JUCE, and they are unable to find a contractor that already has a JUCE licence, then they would need to buy a licence irrespective of the time commitment. This is exactly the same as other services like Google Workspace, Teams, Slack, GitHub/GitLab, etc.
Hi Tom - I totally get (and applaud) the motivation. It’s super important that JUCE derives fair value and remains healthy - that’s in the community’s interest.
As you can see from the passion and concern here though, many of us are worried about unintended consequences. To be successful I believe that JUCE needs a ecosystem comprising:
professional developers & organisations who invest in JUCE and derive revenue from products developed with JUCE
enthusiasts who contribute code/modules/library for use by others
a pool of students/hobbyists who may eventually “graduate” to either of the above!
I’m certain that the JUCE team know all this - after all, you’ve always looked after everyone’s interests in the past. So I’m very hopeful that you’ll figure out a way to navigate this and keep the community thriving.
I should be explicit in stating that we’re thinking about everything raised in this thread. A lack of a response about a particular topic doesn’t mean we are ignoring it, probably the opposite. We need to work out what we can do before we make any suggestions in public.
Appreciate the examples, I think we would appreciate even more examples, particularly things like
I’m a contractor with my own Indie licence and Company A which is also an Indie sized company wants me to work for them, do they need to buy an extra Indie licence for me?
I’m guessing the answer is yes because of the concept of the ‘product’ requiring the licence but that also raises other questions - systems built without a ‘product’ on sale, which is then used to create one or more saleable products.
Consider a scenario where a new client wants a plugin and I recommend Juce, can I start developing without a license and make him buy Juce after having convinced him?
This happened several times in the past, not to the disadvantage of Juce.
Before I post, I want to clarify that there’s nothing against you @t0m. I’ve been in your position and I can only imagine the amount of stress on dealing with this storm here. I understand the premises and we are all talking here to find a win-win situation, since all of our businesses are at stake here.
Said that, let’s begin:
I don’t see a way you (JUCE) can enforce that for code that’s not strictly related to the use of the framework. As example: I have my own DSP framework which works without relying on any of JUCE’s classes, keeping it strictly under the standard library to ensure portability and have it future proof. In the rare cases I reach out to another developer for contract work, that’s what I ask. The code must be platform agnostic and work in the bounds of the standard library. I don’t see a reason why I should pay for an extra seat, but that’s the smallest of the issues. As far as I understand, we are talking about “seats” and these are not named. If I’ll get, let’s say, 3 seats, then I’m allowed to have 3 developers working concurrently. If I switch from a guy to another (without exceeding the number of concurrent seats), then I’m covered. Is that correct?
Let’s go ahead with the other entries: scripts, functionalities and HTML/CSS/JS because, I believe, that’s the real point of interest. JUCE spent a lot of time and effort to bring webview as the MAIN feature of JUCE 8, despite there were several other feature requests with higher votes (CLAP, sample accurate automations, iOS functionalities, just to name a few). I understand that this will elevate JUCE to be more than a framework for audio, but also a framework useful for app development. I understand a way to get more leads and more revenue… but how would you profit if a company just need a single seat for JUCE (to build the final product) while having, let’s say, 20 HTML/CSS/JS programmers working at the same time? And there you go.
As previously said, that’s a first time. I never saw a policy like that in over 25 years working in IT. I understand the need to protect the company from abuses, but you are steering towards a way worse road.
First of all, I really want to say that I appreciate the work of the JUCE team, and the effort required to maintain such an important framework. No need to repeat the obvious. That being said…
And that’s why WebView was pushed, even though CLAP is the number one FR, and iOS has been neglected for years.
The issue is that if I pay for an extra Google Workspace seat, I can stop paying for it once a contractor completes their work after a month. However, with JUCE, I have to continue paying for every single small or large contribution a contractor makes to my code. This situation forces me to retain the same contractor to minimize costs, as hiring multiple contractors would mean each new one adds an annual fee of $2,100 or a one-time fee of $3,500 on top of their charges. Can you see the problem here? I have to jump from $3500 for every major JUCE update to potentially $20000+ if I have 4-5 contractors. A 472% increase. A bit far from current UK inflation, innit?
So, on that: I never hire more than one contractor on each project, if I purchase an extra seat, can my contractors use this during the year as long as there’s only one using it?
And another question, if an artist is actively helping with the internal design/signal chain of a product, even though he’s not touching any code, do we need an extra license for that as well?
That is a bit much. People here are expressing there concerns and explaining how these new terms would affect their business (or hobby) in ways that go far, far (far) beyond the challenges you are allegedly facing with the current terms. We are talking about an entire model here!
Again, that is a bit much.
What you are facing with those loopholes is exactly what we are facing when selling plugins: we know that our products can (and will) be illegally used and most of us accepted the fact that past a certain point (which is product-dependent) trying to combat this further will only cause increasing pain to our honest users (which is the majority, and probably even more so in your particular case). We also know that those illicit users would not have bought the product anyway.
In the end, if compagnies resort to shady technics (script bindings and the like) to abuse your terms, what would prevent them to just blatantly ignore them altogether in the future in they feel like their model is not viable anymore? What is it that you are trying to achieve here?
How would you combat this? How would such efforts affect honest users, the community, and your image?
How many lawyers would you have to send to those companies, provided you manage to find them? (and… would each of these lawyers also require a JUCE license? :DD)
