Thanks for clarifying. Let me rephrase to make sure I get this right. You are both talking about a case where an application was built with JUCE 3, but you haven't registered for a license for JUCE 3, and are about to release it on the market. Your question is whether you need to buy a license for JUCE 4, even if you are not planning to use JUCE 4. Correct?
We are not distributing JUCE 3 anymore, as we are not maintaining it, so the answer to your question is that you need to get a license for JUCE 4. If you had planned to release a product on several platforms using JUCE 3 only, please get in touch via e-mail to discuss.
Are you considering OS X and Windows to be under the "PC Platform" label, and thus are considered ONE platform?
Yes, OS X, Windows and Linux are considered one group of target.
How many licenses do I need to buy to develop these 5 plugins for the 2 PC platforms(Windows and OS X) in those plugin formats?
You will need as many licenses as you have developers. If you are the only person working on those 5 plug-ins, you will need only one license.
Do i need just 1 license and I can develop as many plugins as I want as long as they're for OS X/Windows and it's exclusively me doing the development?
Yes, correct.
What if I add someone to the development team?
Then you need to acquire a new license for the extra developer.
What if I decide to create an iOS version?
Then you need to acquire a license for deployment on iOS
Most have already been said but I really agree on this being a hard blow on us indie devs working on project on our spare time.
Having to pay per seat makes sense, it is more fair since before an indie dev was paying the same as large companies. It shuold however been accompanied by a price lowering to make more sense.
It is a shame licenses are no longer cross platform though. Paying full price times three...ouch!
This especially since perhaps the biggest selling point of JUCE 4, the projucer live build thingy is not even working yet.
I'm one of those that bought a JUCE license recently enough to have JUCE4 license as well so all good for now. I'm a bit hesitant to think about porting my stuff for mobile though as I probably won't upgrade with all platform licenses the day when JUCE5 comes out (not too soon I hope!)
I'm looking forward to use ProJucer when you get it to work though, being able to code C++ real time is mildly revolotionary!
If you had planned to release a product on several platforms using JUCE 3 only, please get in touch via e-mail to discuss.
As I'm sure this might apply to quite a few people here from the discussions that have been going on, can't this be detailed globally rather than individually?
I understand why you would want to have an open discussion about this, and I wish we could. But we can't discuss globally details before they are finalised in a contract and reviewed by the lawyers. We can however, at our discretion, explore ways in which we can help developers who had planned a commercial release imminently and encounter difficulties to do so because of the license change.
One thing I'm wondering is, who in his right mind would ever buy a subscription license? Especially since with the 12 month minimum term it's not that much cheaper than the perpetual license. And keep in mind once you decide to base your app on some toolkit it will very quickly become impossible to switch to another toolkit. You'll need to rewrite a lot of your code from scratch. So suppose you bought a subscription license for your platform:
If the company that sold you that subscription goes bankrupt or discontinues the product, you're screwed.
If the company decides to increase the price to a point where you can no longer afford it, you're screwed.
If the company decides to remove a feature you depending on, you're screwed.
And so on. In short, after you buy that subscription the survival of your business is 100% at the mercy of that company, so you had better buy from a company you can trust. And guess what, regarding item (2), for a solo developer building his app for desktop + android + ios, the price just went up from around $1100 (≈ £700) to $3000.
The license page is also pretty sparse on information. Figuring out you have to buy 3 separate licenses for desktop, android and ios requires at least creating an account. And does anyone know if you have 3 developers and all 3 target platforms, do you need 3 licenses or 9? This doesn't really inspire much confidence, but I guess it will be sorted out at some point.
Anyway I'd say keep up the good work on JUCE. Price changes (in either direction) will always cause some uproar, we'll see what happens when this all settles down.
(And also I'm curious as to how the ProJucer will work. I'm on Windows so I'll have to wait for a while to try it out.)
Indeed! Rather than just Jules, there is now also me (Joshua), Fabian, Timur and JB directly involved in JUCE, and many others within ROLI contributing in a variety of ways.
How many people Roli is now employing to work on Juce is irrelevant. Roli just like the rest of us is in the business of making products, and either Roli's products are going to attract enough people to buy them at their offered price and Roli will be able to continue to pay people to work on them or they're not.
Here's how this announcement struck me. Imagine a company named Ilor is selling a reverb plugin you bought for $1000, and some OS update broke the reverb plugin. You go to Ilor and ask to buy an update to get the reverb plugin working again on the new OS, and they tell you that they've been working on a source separation plugin and you can only get an update for your reverb plugin by buying it as a bundle with their new source separation plugin for a few thousand dollars. "Why would I want a source separation plugin?" you say. "Have you made any material improvements to the actual reverb plugin?" "No, not really," they say.
The price of Juce on deskops and iOS which are the platforms most people are using went from $1000 to $2000 without much improvement being made to either. If they had announced a new iOS Juce module with native iOS widgets for example that would be sold separately for $1000, that would be a different story. It takes months of work to make Juce actually behave somewhat like a native iOS app, and that would be a new product that solves a real problem Juce users are having. Charging $1000 for Juce's current level of iOS support is just wrong. It's price gouging. Juce users have spent years building up products on top of Juce, and we're all locked in to a certain extent. When new updates to OSX or iOS come out, we're eventually going to have to fix the problems they raise in Juce ourselves or upgrade.
I've been concentraing on desktop sruff mainly and haven't built and iOS/Android stuff yet. What you say is somewhat worrying, though would like to ask if this is the case in V3 and this has been improved for V4, or are you saying this is still the case in V4 as far as you are seeing?
I guess i got lucky (or maybe not) and managed to buy my licence in the window before ROLI takeover and my licence says it includes v 4.x. The thing is that it is a single product licence. What I don't understand is how to upgrade to a multiple products licence at this point. Back then there was something like 299 or 399 pounds upgrade (don't remember the exact number) which I intended to buy but did not have the money (I am a startup student) at the point. Can I still upgrade my Raw Material licence?
How much work it is depends partly on the nature and scope of the app you're creating of course, but if you just look at the Juce Demo running on iOS, you'll see what you're going to be dealing with. I remember showing the Juce Demo to some colleagues back in 2010 because I was trying to convince them to do an iOS app based on Juce. After seeing it they refused because it didn't look at all like a native app, and really nothing has changed since then in that regard. Offhand there is no viewport class in Juce that let's you scroll through the content by dragging on it with your finger. There are no classes in Juce for handling transitions between nested pages. Some widgets like the ComboBox aren't used on iOS; people are used to seeing those spinning wheel controls, i.e. UIPickerViews. Neither are toggle buttons; people are used to those sliding switches. Neither are radio buttons; people are used to either arrays of buttons or wheels. And unfortunately, although you can spend a bunch of time making wrappers for the iOS widgets by creating C++ to Objective C++ bridges, because the iOS widgets are heavy weight components if you try to put a dialog or something like that over them, they're going to draw through them. So, if you do make your own wrappers, you have to be careful about which contexts you use them in. And there's also the whole problem with Juce's mouse handling making it impossible to recognize certain kinds of gestures. I certainly put a lot of work into trying to make my Juce app look like a native app, but we still get bad reviews from users on the AppStore or whatnot because it's obviously not a native app. I personally don't know if I'd use Juce for an iOS project if I had to do it again given the fact that Apple now has Swift in addition to all the unpleasant recent changes surrounding Juce.
I've taken the approach of using JUCE only for views that need to display custom graphics and for audio processing, and using native iOS/Android API's for the rest of the app. This has a few advantages - native toolkits make building mobile UI's quite straightforward, and give users familiar UI elements. It also makes using a database such as sqlite or couchbase lite easier as you can do all the viewing and editing of data natively and then send the data to your JUCE app. This way you can reuse your custom graphics classes and processing code across all platforms. The disadvantage is that you have to build the UI for each platform. I came to this conclusion the hard way, after spending months trying to do all of my mobile UI in JUCE.
I must admit this idea does not seem so attractive anymore given the recent licence changes. I hope that more consideration is given to indie developers to make this kind of approach financially viable.
I'm a sole developer with a single, reasonably successful but very niche cross-platform product. Choosing the library you're leveraging off is a lot like picking a bride - you'll be stuck with her for a loooong time to come, so choose wisely! I was young and foolish, which is why from the wreck of a marriage to Qt (don't ask) a full rewrite based on JUCE looked, well, juicy, and worth an investment of blood, sweat, and (when ready for release) 699 quid.
What a rude awakening now! Not just that the price tag has tripled overnight for my use case, but even more so because of how it's being done: a prominent $999 price tag - with "per platform" in the small print 5 pages later, just before you enter your credit card number. Subscription at only $49 a month - with "12 months minimum" in the small print. Zero advance warning, apparently even entrapment of some who were ready to buy in just before. A web site that seems to value chic design above useful information. Questionable bundling (projuicer, priority support) and unbundling (the platforms) decisions that undermine what at least I perceived as the core mission of JUCE.
And deeper down, the feeling that whereas before I was tying my luck to Julian, whom I've come to trust & respect immensely through his fantastic work, both coding and helping us on the forum - I'm now supposed to wed a company that I only know through what they're currently doing to (not for) JUCE. It's a very sad conclusion for me, but it does look like the wedding is off. JUCE is still a fantastic code base, but an expensive bride that has shown no sign at all of caring about me is an unacceptable long-term business risk.
So, ROLI: show us that you care. It's not too late yet to win back some hearts.
