If we had explicit exclusions from the licensing terms for image and audio files, and presets, would that address the issue?
Honestly, these license changes seem poorly thought out and if implemented and enforced as stated, likely to absolutely decimate the JUCE community, especially the ecosystem of contractors (like myself) that supply development services to multiple clients - clients who often have no internal development team of their own.
Specifically, the stipulation of 1.6 that Product Owners must provide a license for contractors, etc. even if those contractors ALREADY have a license is ridiculous.
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.
This should be fixed by clarifying that the Owner only need provide a License if the third party does not already have a License (change in bold):
Contractors, software development companies, or any other third parties creating or maintaining a Product for an Owner must either possess their own Licence or be provided with a Licence to use the Framework by the Product Owner.
This still leaves 1.13 as an issue, for smaller contractors who fall under the Indie thresholds but supply services to companies who do not:
1.13. Simultaneous Licence Type Use
You may not use the Personal, Indie or Pro Licence Types simultaneously. You may not combine or integrate content or Products developed with one Licence Type (e.g. Personal) with any of your content or Products that you develop with another Licence Type (e.g. Indie or Pro).
Under the new requirements, the Owner is required to have a Licence appropriate to their tier even if they have zero developers in-house. Given that, why the requirement that all participants in a product must have the same tier License as the highest tier participant?
6 Likes
Since you like to answer with single words, I’ll answer with
No.
5 Likes
Why would that not address the issue?
But you’ve removed the option to add the splash screen and drop down to the lower tier. For a hobbyist, the indie license is a luxury.
1 Like
I think it would address the issue at hand regards 3rd party non-developers contributions to a product, but it still leaves the problem for developer contractors.
It’s probably a little bit of anger showing, which I think given the community and their attachment to JUCE is somewhat understandable.
There are multiple types of ‘content’ added to a product. Could be MIDI files, fonts, video files, HTML, product manual, non-JUCE dlls… I think a JUCE ‘seat’ should only be for people who work on JUCE-related C++ code and not manually exclude every possible type of file that a product may include.
16 Likes
Because of the other issues I raised, individuals working in parallel on multiple projects of different clients, which hits many people here.
You cannot say: I added five problems in the new license. Would removing one solve the issue?
6 Likes
It goes deeper. Even proposing such changes is damaging to small developers - like with Unity last year. The problem is trust. Once you start feeling like the framework owner is going to make terms worse over time, why would you want to invest more into a framework?
These changes seem to be targeting some people abusing the current terms, but the effect is that everybody gets punished with a more restrictive license, and trust is lost.
It makes me consider different solutions a lot more for future products.
18 Likes
My question was a response to the immediately preceding statement about the types of files being contributed to a product. Clearly it’s not going to help with the other issues.
So any statement about the other issues?
1 Like
@tom As @eyalamir suggests, it seems unpractical trying to exclude certain content types from the license and will always lead to edge cases where someone ends up with a ridiculous license situation.
Why can’t you just say “everybody that works with the C++ codebase and / or compiles the source code” needs a license and call it a day? Where does the urge to specify this any further come from?
13 Likes
Almost. What about text files for translations? These could be provided by some web service. We wouldn’t even know the name of the translator. Also, if we get five languages translated, it would be five different people providing the translation.
7 Likes
Unity tanking their entire business model & years of goodwill last year wasn’t supposed to be an inspiration for JUCE to do the same thing.
18 Likes
I am talking with a now retired person to maybe license impulse responses from studios, that he created in the GigaStudio/GigaPulse time (say 20+ years ago). This would be content for my products. Am i reading this sentence above that Juce, in one way or another, wants to get a portion of such content deals?
No way - this would be killing for my startup. Juce is a C++ coding platform, don’t touch my content.
And my subscription goes up 350% - wow.
I am not even going to read about Juce 8 - good luck with it.
3 Likes
Maybe I’m misunderstanding something, what stops you using the personal licence?
“everybody that works with the C++ codebase and / or compiles the source code” is already problematic. We have example of companies doing things like automatically generating Lua bindings to JUCE. The large team of Lua developers are not using C++, nor are they compiling anything.
Are these decisions made at Juce level, or at Pace level? Really curious
6 Likes
I think it would make much more sense to have a provision that says that working with bindings in other languages are subject to paying for JUCE license seats, rather than the current situation which clearly none of your existing customers are happy with at all.
7 Likes
Should have seen this coming with the PACE acquisition of JUCE a while back.
7 Likes