Wait what?
If a developerless company hires company X to make a product, why would they have to get a license? they never get in the code, they don’t maintain the product, they don’t have anything to do with beta testing or anything, as far as I see it, Company X is selling the finished product to developerless company.
No?
You cannot sell a product under your name without a license. That was already the case with previous versions of JUCE, but the number (and tier) of licenses required might increase significantly in JUCE 8 depending on the situation.
Yeah understandable, however, now a question arises, what if the company is not selling the product, but just distributing it (i.e. giving a link to my downloader so that their client gets the product from me)?
For example:
I make a product for Company using Company’s name. I control its code, I compile it, I keep it updated it, and it belongs to me.
Company distributes my software at no cost (they buy the product from me, but distribute it as a freebie with their hardware), they have nothing to do with the development of my product, they don’t sell it, they just offer it.
Does Company need to get a JUCE license?
@t0m ?
If you upgrade from JUCE 7 to JUCE 8, with the 30% discount, then your JUCE 8 licence will replace your JUCE 7 licence and you will be bound by the JUCE 8 terms. If you purchase an additional JUCE 8 licence, without the discount, then you can use your JUCE 8 licence for JUCE 8 projects and your JUCE 7 licence for JUCE 7 projects.
Contact sales@juce.com. In the short term we can make some exceptions.
The intention was, and still is, to do a release at least every 18 months.
The consistent text formatting/unicode/emoji work was anticipated to be very complex, but it was even more complex than we expected. We were also waiting for Microsoft to publish their MIDI 2.0 API, which ultimately came too late. Then we also had the opportunity to work with Matt on the Direct2D renderer. These all pushed back the release date.
Once JUCE 8 is out of the door we’re going to provide something similar. This would be something along the lines of a public roadmap with periodic progress updates.
Say a contractor have a perpetual juce 7 license and coded a product for a company that sells it. (or several products for several companies).
Until now the company didn’t have/needed a juce 7 license, as the contractor had one.
It is also possible for contractors to have their own individual JUCE licences. In this situation the relevant revenue or funding limit will be that of the contractor, so it may be possible for contractors to use Indie licences where the revenue of the hiring organisation would exceed the Indie funding or revenue limit. However, the hiring organisation is responsible for ensuring that the software is appropriately licensed for the whole duration over which it is distributed, including that contractors have perpetual licences (see the answer to the previous question above). You must ensure that the software is appropriately licensed for the whole duration over which you are distributing it
If the contractor upgrades to juce8, he will be bound to the new juce8 terms.
What happens then to the company that still distribute the product made with JUCE 7 ? Do they have to buy a juce 8 license ?
I’d say the answer here is “yes”, as the client is no longer covered by the contractor’s license, and thus the client needs a license of their own (either a JUCE 7 perpetual before the cutoff date, or a JUCE 8 license which will cover their JUCE 7 product).
We’re not going to backdate licence seat requirements. If you are currently using a single seat, then you will only need a single JUCE 8 licence.
It seems like yes. The best/only solution for the contractor in this case would be to buy an additional JUCE 8 license rather than benefitting from the 30% discount for the upgrade.
If I move JUCE 8 that’s probably what I’ll do, but it will delay the process because the 30% made it much more affordable and I’ll need to consider the financial cost.
Got to say as a contractor having to double license myself if I eventually move to 8 just so I can be sure I can work for ppl in the future who don’t want to move to 8 is a bit of a shit situation. It’s almost like Juce have just taken our loyalty bonus off us for being loyal and buying a new license.
I’d really appreciate a comment on this, as it falls in a category I might be in soon…
If I create a product for another company’s hardware, I compile, I maintain, “Company” simply distributes the download method of the product (which will be downloaded from the downloader I use, for free) with their hardware - all software support will be handled by me (i.e. Company will redirect all that to me), and the product will belong to me (using Company’s name in the DAW, but the “About”, and the documentation is all accredited to me).
Does this company need to have a JUCE license? @t0m ?
Thanks in advance,
My understanding is that if you (and any other developers who worked on the product) own a perpetual JUCE 7 license, you are permitted to license the application to them according to the EULA:
1.5. You may not use a JUCE subscription licence to license Applications owned by a third party. Where the Licensee Content is not owned by the licence holder the licence holder must have a perpetual licence.
On a related note, I think there have been many positive developments to the EULA. I think that moving the responsibility of license holding to the product owner makes sense in most instances, however I think this could use a little clarification.
As others have mentioned, there are product owners that do not have access to the source code for their product - only the binaries. They have no interest in owning or accessing the code. In these cases, why should they be required to hold a license for a coding framework, when they have no code?
Thanks for all your hard work, @t0m . I know there must be pressures coming from all directions right now and appreciate your efforts.
Usually a license is so that it can be used on e.g. different computers, but not at the same time, which is the case with the current scheme. That worked best for contractors like me.
When I work mondays for client A and tuesdays for client B (which is reality at the moment), then my license is never used in parallel, and JUCE gets a fair share for everybody working on a JUCE project.
In the proposed changes, if I understand it correctly (there were little comments on that situation), JUCE will collect money for each time I touched JUCE code for ever (until the license had to be renewed).
There is little to no incentive for anybody to hire me, unless I remain working on the product until end of life.
Without this addressed I don’t see many contractors updating, which means the clients they are advising will also be hesitant to upgrade.
I’m not sure I understand what you mean. My understanding of the proposed changes is that in your case, client A and client B would separately have JUCE licenses, and when you’re providing services for them, you’d be writing code using their license. You wouldn’t need to have your own license. Why would that be problematic?
Because I might be added to their team for a short tenure. But JUCE requires that license added for me to be upheld forever.
In addition the claimed money in total of JUCE multiplies by the number of clients I can serve in parallel.
If I were speaking to a client on a work for hire basis (where they own or have access to the code), I would recommend to them that they buy at least one perpetual license (providing they are working with one developer at a time). In my opinion, a subscription doesn’t makes sense in most cases. In fact, I’m struggling to think of a situation where it would make sense.
In addition the claimed money in total of JUCE multiplies by the number of clients I can serve in parallel.
So you’re saying that your clients that (I’m assuming) own the source code shouldn’t need their own licenses, and that they should all be able to point to your license? I don’t think that’s very fair.
Of course they need their own licenses, and at least one perpetual. I don’t want to make money off the back of the JUCE team, I want that it keeps existing.
But the situation I am talking about is this:
Company A has three developers on payroll, so they own three perpetual licenses.
Now they need just one feature they didn’t get right. They call me, I contribute under my license and once done all is fine.
With the new license, they will need to keep paying this additional license forever (either buying a perpetual or the subscription until the next major upgrade).
Right…I understand what you’re saying. It would be very nice if there was a way you could do that. Under this current situation, I would recommend that the company get an additional perpetual seat that could be used as a space for any additional contracting work they need (one at a time of course).
I do understand what you mean, though. That could be improved but I can also see ways that system could be misused. For example, under your proposal a company could downsize to no subscriptions if there wasn’t anyone actively working on the codebase, right?
People misusing a system will do. But making it unusable for the legit users cannot be the alternative.
Many of my clients are single people who need just some help to get over some hump.
But now you can imagine from whose budget those additional 3.5k will be taken from.
