First, quick disclaimer to say I love JUCE and appreciate all of the hard work the dev team puts in to maintain such a complex codebase. Thank you all so much.
Second, it’s understandable that there is a desire to attempt to combat abuses of the license to get around paying for seats in bad faith, such as the lua binding example.
However, it really bothers me that a) no one on the JUCE team read these provisions and raised any flags around the absurdity of some of the resulting scenarios (especially regarding purely content contributions to the product), or b) they did raise these concerns, but were powerless to push back against the mandate from “above”, or worse c) had a hand in crafting some of these provisions themselves.
If it’s extremely hard to effectively create legal wording in which the rules around API interaction/bindings/wrappers are defined, does it really follow that it’s somehow easier to create legal wording that appropriately defines all possible scenarios around the types of content that do or do not qualify? I would imagine that latter is actually much harder. For example, is my installer binary considered part of the Product? If I have a legal professional draft up terms of service or any other legal statement and I include it in my product, is that considered content and does the company providing legal services now need a license? What if I buy non-exclusive stock content (images, sounds, etc.) from an online company and include them in my product (such as Adobe Stock, Shutterstock, etc.), will they also need a license? What if I initially contract a designer to create assets for a completely different non-JUCE product, but then decide to use them instead (or reuse them) on a product that includes JUCE? It’s just a massive slippery slope.
The JUCE team may say, “well obviously not we don’t care about a license agreement, etc.,” but unless all of these scenarios are explicitly spelled out in a gigantic license agreement, there will always be the fear and mistrust that the lack of explicit wording could be used against us in bad faith in the future. Promises are not going to cut it, unfortunately.
Hopefully this really is just an well-intentioned, but poorly executed attempt to deal with some bad faith customers out there, but these broad content provisions, even if revised after feedback unfortunately smell like a pure money grab, and I fear the damage is already done. It’s also unfortunate to upset the majority of the good faith customers by introducing these terms based on presumably a minority of customers acting in bad faith. If even a tiny group of JUCE customers were surveyed and solicited for feedback before this license was finalized this moment could have mostly been avoided, and the JUCE team would have saved money on legal services regarding the inevitable rework of some of theses terms.
I acknowledge there is probably a lot more going on behind the scenes that we’re not privy to, but we’re all reacting to only the information we have in front of us.
JUCE team: you all seem like intelligent and reasonable people, so I hope through some discussion and consensus building with your community and customers you can find a decent balance that address the biggest concerns with the new license agreement while still meeting some of your internal objectives to close up some of these loopholes that have been exploited in bad faith, etc. Please don’t let this turn into Unity 2.0. Good luck.
(jk)