I know this feels a little redundant, but there are other, more complex, ways to provide JUCE-as-a-service that fall outside the definition of a Product, and we need the latter part to protect against them.
We want to retain the definition of a Product to not impede use cases as described in the linked thread.
Sorry, to be more clear: “mapping parameter ranges” in a dynamic way such that those mappings are defined by functions, and authoring those mappings is not functionally distinct from scripting.
Ok - so would not cover say Massive, but would cover Reaktor, Bidule, MAX/MSP preset designers? How about Serum preset designer who are using the wavetable editor forumla function, would they need it? It’s definitely logic…
The actual wording in the contract is not at all clear here.
EDIT (a picture, in case you’ve not been in this annex of Serum):
configuration files or “presets” that embed, inject, or otherwise incorporate logic that directly or transitively depends upon the Framework
That would count as logic that directly or transitively depends upon the Framework.
This seems over the top? Imagine you design something and send it out to a bunch of beta testers and artists who send you some presets? Should they really be required to have a JUCE license paid for?
Ok, let’s pick a simpler example, in a sampler you set the key range (it’s not a parameter), and that determines when a sample plays. That seems to me to be ‘logic’, basically an if condition wrapped up as a slider. Does someone making presets for a simple sampler need a JUCE license?!
What happens if we buy presets off someone who already has the sampler who made them independently, i’m pretty confused?
What happens in the case of a modular synth. Where the user can create presets from a selection of modules, Drag cables between the virtual jack ports, and assign macro controls. This is all done in a drag and drop GUI, no scripting, or direct editing of text files. This is my current full-time project.
I depends on the legal agreements you have in place with your beta testers and artists.
For the purposes of this Agreement, a “User” is an employee, agent, independent contractor, or third party developer of the Licensee or any of the Licensee’s Affiliates
If they are Users then they will require a licence if they are doing something that is not functionally different from computer programming. I suspect in most cases they will not be Users.
It would be difficult to argue that that was logic, rather than static data.
They will not require a JUCE licence, and you will not require a JUCE licence for them.
I think that resolves questions 2, 3, 4, and 5.
Are your preset creators in question 1 Users?
Thanks for the prompt positive response.
I have someone making a promotional video (paid) who has offered some of his preset creations( for no fee). A few from unpaid beta tests, and was hoping to include some from my forum users in the future. I guess the only one in question would be the video creator?
Thanks for listening. The Indie revenue limit of $300k hits a sweet spot. It’s just enough to sustain a small business and cover the costs associated with global reach.
I’m not sure it’s clear in the contract at all? It sure sounds like ‘if this then that’?
Maybe you mean complex logic and that needs a definition? Or logic that normal electronics won’t be using to operate the product?
Maybe you need to differentiate between the stuff users configure to get the desired normal output of the app and the stuff developers and designers might configure in order to make the product fit for sale?
to clarify.
I’m working on a plug-in whose individual components are static but moveable in the audio chain, and parameters are full scriptable.
a kind of internal automation.
user do not create any new products or services.
he is scripting the synth’s internal parameters.
Can I consider them simple presets?
the user can enter mathematical formulas and functions.
he is scripting the internal parameters of the dsp, do not create any new products or services.
Can I consider them simple presets?
@t0m thanks for the update and the changes. I understand what are you trying to cover when mentioning “presets”, but I think it’s too broad and prone to misunderstandings.
I assume one of the scenarios you want to avoid is programmers developing in a scripting language whose interpreter has been wrote using JUCE and depends on it. Currently those “script developers” won’t need a license and that’s one of the things you are trying to fix, right?
To clarify, we have several products featuring a customizable signal path where users can rearrange the modules (up to 7 I think) and save their configurations as presets. The underlying logic relies on JUCE. Often, our beta testers or friends submit presets that incorporate various combinations of these internal modules, and we include these in the final products. In this scenario, do we need to consider multiple licenses?
For the purposes of this Agreement, a “User” is an employee, agent, independent contractor, or third party developer of the Licensee or any of the Licensee’s Affiliates.
Are you talking about users of your software, or Users within your company? If they are not Users within your company then you do not require licence seats.
@audiothing the same question, but that would also qualify as static content if those beta testers are not defining functions or naming parameters, etc.
That is one of the things we are trying to fix, and it is the easiest one to understand. There are a whole class of similar ways to work around the licence agreement, and we are seeing companies doing this.
This seems like a good suggestion, but I don’t think it gives us the protection we need in other problematic situations we already know about.
In other words, could it be said that people employed by the Owner, need a JUCE license if their contribution to a Product is expressed in a programming language (textual, visual or otherwise) that is turing-complete?
Also, I think that the term User is may create confusion, because in the context of the EULA, it means User of the Framework, but it’s very easy to forget that and, out of habit, make the assumption that User = user of the final Product made with the Framework.
Perhaps “Developer” or “Programmer” (as in: one that develops a Product programming with the Framework) would make it easier on the readers of the EULA to understand the role that it refers to?
