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.