I do not as a contractor. But my described scenario is at the moment possible and in my opinion not fair for JUCE.
I didn’t say it was common or anything. Just saying it was possible before, it was unfair and now this issue is addressed.
I think it’s fair to ask any company that releases products based on JUCE to purchase at least one license even if the contractor isn’t working for them anymore. I don’t think that’s a core issue people are complaining about.
The problem is with the need to purchase multiple licenses.
8 Likes
Some major hits have been mixed using my plugins. Yet I don’t get any extra money for that… do I care? no. Audio-plugins are tools and buyers are free to create whatever they want with them and sell it. I wished the same was true for JUCE, which is a tool to make tools.
If I have to pay extra every time I use a tool for someone else (or they have to pay), the tool becomes a lot less useful.
7 Likes
Yes, that sucks and all of your above concerns are also valid and handled very badly with the new terms.
But I see where JUCE is coming from
no, that’s not the issue at all. In my opinion, there are different scenarios:
-
Having multiple programmers working on a JUCE-based product. All programmers are using the JUCE framework. You need to purchase N-seats (this basically applies to ANY commercially licensed software)
-
You are an independent using JUCE and use contractor work. The contractors develop using JUCE for you, then you must have an extra seat for the external contractor. That’s not the best, but reasonable.
-
As 2, but your contractors DO NOT use JUCE. You shouldn’t pay the extra seat.
My 2 cents
4 Likes
You can of course argue it from this perspective. But in that case, I find the tool to be way to cheap comsidering the time I save as a developer.
Are you serious? Might be fair to you. But as it stands now, instead of paying 1 Pro license (before $2600, now $3500) for every major JUCE update, I will have to pay extra Pro licenses for:
1x Graphic designer
4x DSP contractors (that already have a license!)
3-5x Sound designers (whose provide IRs, audio recordings, content in general)
10x beta testers who occasionally send me presets that I include in the products or help with layout, ideas, or other product aspects
so, instead of $3500 I would have to pay $73k. Let’s say they remove the absurd “content” requirement. It would still be $17.5k instead of $3500.
12 Likes
That is of course total BS, but as far as I read toms responses, this is gonna be changed, no?
I hope so.
2 Likes
As I said and as I understand Tom, this will be changed and was probably not their intention in the first place.
1 Like
I think there is an important difference. JUCE is putting a lot of work in to maintain its compatibility to all supported platforms and formats. A software owner directly benefits from that and the developer (ideally, maybe a little more complicated than that), just Hits update, recompile and the software is ready.
This should be priced properly in my opinion. Could also be an additional fix price per new JUCE version for example.
which has been already done with this price increase. moreover, we have to pay for a new perpetual license for every major update and that’s fine. I fear that the next step under this new ownership, will be to make JUCE more like the Unreal Engine, ending up with us paying a share on our sales
1 Like
The thing that bugs me about the “contractors need to have a license” is that the license fee isn’t necessarily commensurate with the contribution of the contractor.
Let’s say Company A has one in-house developer and one contractor. Both contribute the same amount of work to the product. In this situation it seems fair to me that the company pays for two full seats.
Company B has one in-house developer and uses two contractors who contribute only a little bit to the product (less than 50% together). Is it fair to charge company B for three full seats?
I understand the difficulty in ascertaining which company owes how much from the outside, but the new terms don’t seem to be doing a good job of approximating this (as seems to have been their intention).
4 Likes
$40/mo is a proper price.
Heya @t0m thanks for listening to feedback. You and the team have been good stewards of JUCE over the years, and it’s good software, so I appreciate you considering changes here and also appreciate that it takes time to discuss anything with lawyers!
One thing I wanted to toss in about the ‘contractor’ situation which I think is tricky - and being appreciative of your problem of defining the ‘edge’ of software - is the assembly of juce with open source libraries. Imagine if, say, my plugin uses a linear algebra library like eigen (which Surge does not but its a good example). Writing my plugin I find a bug in eigen. I report a bug there, someone fixes it, i sweep it into my plugin.
But
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.
now that eigen maintainer has modified source code that is part of software containing JUCE.
I’m assuming that your intent is not that every maintainer of every open source permissively licensed library which is used in any JUCE plugin has to purchase a license, nor that every user of a permissively licensed open source library who ships a JUCE plugin has to buy a license for every maintainer of every library.
Or, in extremis, that everyone who implements libc has to have a JUCE license.
The way this usually gets sorted out is ‘explicit dependency on api’ type terms. So “Every developer writing a program which has an explicit dependency on the API, whether via C++ or via exposing that API via a wrapper”…
There’s a problem on the other side also. Imagine Surge exposes a bug in a hosting environment not written in JUCE. I report it to the DAW manufacturer and they change their code. They have made a code change to a product which uses JUCE etc… and the strictest possible reading of your terms are a problem. Again in this case the bug would be intermediated by a neutral API (VST3, AU, CLAP, AAX, etc…) but lawyers force you to read things pedantically and maximally, so i think you might have a problem here also.
If the daw was directly calling juce:AudioProcessor::process of course it would need a JUCE license to ship but it isn’t
Anyway just sharing these thoughts since they may help you and your counsel find the line you seem to want which is : wrap JUCE in LUA and have everyone code that - they are juce devs. Use a non-juce-related open source library with 1000 contributors, you don’t need 1000 JUCE licenses.
Hope that helps, and good luck with your changes!
21 Likes
That would be the real deal breaker. Too many people wanting a slice of my pie…
In that case I could start looking at Qt.
2 Likes
This definitely discourages companies from hiring contractors for small specific tasks (which can occur from time to time). If I’m paid for work that only takes one day to complete, suddenly the company has to pay $600 a year extra for that.
4 Likes
imho, that’s the simplest solution: anyone using JUCE commercially (either a company or a contractor) need to purchase a license, without useless overlaps. If I hire a contractor who already owns a commercial license, I won’t have to purchase another one.
4 Likes
everyone who implements libc has to have a JUCE license.
2 Likes
And for the “exporters”, just think on a different licensing option. I believe that will be fair for all the involved parties