It would depend on the legal agreement between yourself and fuo and if that made you “a contractor acting within the scope of the services they provide for the Licensee”.
Just to be absolutely clear: are we still talking about code that actively uses JUCE’s API? Are we clear that “pure” C++ is out of the equation, right?
The relevant part of the above is “directly or transitively dependent upon the Framework”.
“Pure” C++ would not be directly or transitively dependent upon the Framework, so it would not be included.
2 Likes
Thanks Tom
1 Like
That is great, I can absolutely work with that.
Thank you @t0m !
1 Like
In our latest Portal application (Portal - UVI), we allow the download of our soundbank and apps through a webview (currently using Choc webview).
If I move to Juce 8 and its own webview, do you consider we should buy seats for web developer
that do the backend of the application ?
Thanks !
1 Like
I would love to jump into JUCE 8, however based on this clause, it seems it wouldn’t be beneficial for us to upgrade:
1.5. Owners of Products
For the purposes of this Agreement, the owner (“Owner”) of a Product may be either the legal owner of the Product or the entity represented as the owner in any branding or information supplied with the Product.
1.6. Licences for Product Owners
Contractors, software development companies, or any other third parties creating or maintaining a Product for an Owner must be provided with a Licence to use the Framework by the Product Owner.
From what I can see, a product owner would still need to purchase a license even if we just supplied binaries. I’m having trouble understanding why that is the case.
That would be like clients needing to license a copy of Photoshop if a graphic designer happened to create the assets using Photoshop. The client doesn’t want to know or care about the tool the graphic designer used. Why would it make sense for us to impose this additional condition on the client when they don’t even have any code?
Thanks for any help in understanding this.
Note: Reading in between the lines, I’m sensing that these types of clauses are to prevent a future “Mid-Journey” type of offering where you could provide some prompts and spit out a binary with JUCE providing the heavy lifting on the back end.
Something like Hise / Falcon but maybe completely automated?
I know it must be challenging to come up with the right language that can prevent those while providing the right freedoms to developers who are acting in good faith.
6 Likes
That is indeed still a drawback of the new agreement.
Maybe there could be a slightly more expensive publisher license for those who don’t deal with the code at all, in which case the people owning the code (the development team) need their own license?
4 Likes
Yes, I second a publisher license for someone who publishes plugins and otherwise doesn’t use JUCE themselves. This is a common scenario. I serve clients like this myself - and I find it super hard to explain to them, why they need to buy a code tool, that I’m using to deliver what they’re buying from me - imagine a freelance graphics artist telling their prospective client they’ll have to buy photoshop for the image the artist is supposed to deliver [//edit: haha oops, just saw that @theaudioprogrammer made the same analogy just a few comments above…].
A publisher license would explain itself, could be communicated up-front easily and if only necessary when there is no other JUCE license in the business makes absolute sense, if you’re earning money by selling JUCE based products. This takes away from all the mess that the current model creates.
Everyone who works with JUCE buys their license and can publish under their respective tiers, everyone who only publishes JUCE buys a license as well for publishing, no one is double-licensed. Am I missing something?
2 Likes
This is an important point, and should probably be made more explicit.
I was under the impression that every time I upgraded my perpetual (sic) license, I was allowed to keep making/publishing software under that previous license forever (sticking, of course, to the JUCE version the license was covering, and of course until it’s too old to be usable on the latest platforms…)
So if you want that, you should not upgrade, but buy a new license.
Good to know.
4 Likes
As for the proposed idea of deleting the thread, that would seem a lot like a “cover up”, whereas leaving it online, locked, edited with a big text in the first post saying “the information here is not relevant any more, see this other thread instead”, would be a much better act of transparency. The experience gained with this thread is important for future memory IMHO
5 Likes
Indeed. I was planning on upgrading to benefit the discount for when I’ll be jumping to JUCE 8. But I’m planning on sticking to JUCE 7 for some more time, so I guess I’ll wait and buy the JUCE 8 license if/when I need it (can maybe jump to JUCE 9)
beware: if you don’t buy a JUCE 7 perpetual license your subscription will automatically be switched to JUCE 8 when it is released.
1 Like
To me, it gives the impression that you get the upgrade discount at the price of the rights you give up by surrendering the rights granted by the JUCE 7 license.
If the upgrade discount were just a loyality reward for the money paid for previous licenses, there wouldn’t be any problem in leaving JUCE 7 holders the possibility to maintain JUCE 7 code with their perpetual license of it.
That’s like admitting that the JUCE 8 license has more restrictions and disadvantages than the 7 one IMHO
2 Likes
Still, it doesn’t solve the problem of an OEM product (including JUCE code), be it hardware or software, which is prepared as a black box solution, and as such offered to external companies and distributors, which should buy another license then, their relabelers another one, etc. Who is responsible for tracking licenses? Anyway, I have serious doubts if such license chaining would be legally possible, but what I know 
2 Likes
This is referred to in the current JUCE 8 Agreement… but doesn’t differentiate between upgrades vs separate existing licenses the user has…
Perhaps that can be re-phrased to remove any ambiguity? I will buy a separate JUCE 8 license to support JUCE development, but would also like to continue using JUCE 7 under the original license terms.
Rail
2 Likes
Ok, let’s change it in JUCE 8 so that upgrades unambiguously don’t replace the existing licence agreement.
I also can’t see how the JUCE 7 EULA unambiguously means that an upgrade results in a termination, and so we will not treat it as such: If you have purchased a JUCE 7 perpetual licence then you can continue contributing to JUCE 7 projects under the terms of the JUCE 7 EULA even if you upgrade to JUCE 8.
If you have already taken action based on my previous message please email info@juce.com and we will sort it out.
11 Likes
It would depend if the content in the WebView is either directly or transitively dependent upon JUCE. A good test is if you were to delete JUCE, could you still use the full functionality of the code in the WebView?
See that’s confusing… I thought upgrades do replace any existing licenses the owner has, where non-upgrades don’t replace any existing licenses the owner has.
Cheers,
Rail
1 Like
Full fonctionality is hard to define.
For example in our Portal app, you can click download in the webview, and we intercept a JS code and launch the download itself using CURL, then unrar, then install in the right location using c++ code.
We have a cutdown version in web only but where you only download directly the rar file, no automatic unrar and so on.
In that case, you don’t have the full fonctionality without Juce as you cannot bind the JS function.
But here Juce is just a tool to ease some stuff but the actual web job has nothing to do with JUCE.
Clearly we won’t upgrade to Juce 8, if we need to buy licence for our web developer just because of this app. Right now it’s Juce 7 with Choc webview.