pfft - il just added this to another post also
to be clear - the GPL does not require anyone to distribute source code with every
binary - it only requires that source code be made available upon
request - developers may even charge a reasonable fee for the service
This is a “maintenance hassle”…?
-#define JUCE_DISPLAY_SPLASH_SCREEN 1
-#define JUCE_REPORT_APP_USAGE 1
+#define JUCE_DISPLAY_SPLASH_SCREEN 0
+#define JUCE_REPORT_APP_USAGE 0
sry - i have not even looked at the new code yet - that would be nice if they are only switches - but these are not the first anti-features i have needed to maintain patches for - just the latest crop
If you are experimenting does that mean you might change the type of data you are collecting during the JUCE 5 license term? Is there anything that should be more specific about this in the license agreement? Do you have any processes defined for how to handle when these changes would happen?
When you talk about analytics services, are you meaning a service that would provide value back to JUCE developers about their user’s usage? I suppose their may be some value to the developer in that but personally if I decided that I needed to know this kind of stuff I’d much rather write the code myself.
Is the following possible
A) allow developers to explicitly transmit the information to you (IE number of users, regional data, OS, etc) to comply with your license
B) transmit the the data you request without containing user-identifiable data?
If you’re just after number of users, platforms, regional information, etc, why do you need to transmit the IP address for any reason other than laziness? Can’t you just extract regional information, hash the IP to get a unique identifier, then transmit that information instead of the IP directly?
I’m all in favor of your terms here, I think getting better data about end users means developers will get a better product. But I think our end users concern is over identifiable data, so if we could provide privacy policies that guarantee no explicitly identifiable information is transmitted to a third party, everyone could be a bit happier about the situation.
Them mentioning “IP Address” and “tracking” in the terms is probably for legal precision only. The mere establishing of a connection will always transfer (or at least reveal) your IP address. This is nothing you could avoid or obfuscate.
Other than for geographical mapping, which Google Analytics does under the hood, the IP is probably not of much use for ROLI. IIRC, there’s an option with Analytics to obfuscate or hide the IP information from the reporting, basically throwing it away after the mapping. Maybe that’s a viable path to ensure anonymity?
My concern isn’t whether or not people are willing to accept the loss of anonymity when it comes to connecting to the internet. I’m concerned with the implicit agreement between developer and user that I’m not going to try and connect to the internet from their machine, because my software doesn’t need to in the first place. And in the event that it does, I’d like to guarantee users that despite their machine making an unwanted connection to a third party that they have not agreed to share information with, their personally identifiable information is not shared nor stored by that 3rd party.
If it’s possible for me personally to collect data from licensing my products and share it in aggregate with ROLI, then I’m fine with that. My concern is ROLI stepping past the licensee to the end users, who are not agreeing to the same license terms I am.
We’re really not doing anything evil or underhanded here! This is my high-level summary:
Set a flag to disable it, and carry on as before.
This is all off by default so won’t affect you. In future we hope to be able to offer a simple analytics dashboard, so this may become something you’ll want to opt-into if you decide you’d like some low-effort basic analytics.
There’s a saying about the internet: “When you get something for free it means you’re the product, not the customer”. The splash + analytics is how you’re paying for our service!
If it means you have to worry about how it affects app store or other 3rd-party EULAs then that’s just something you’ll have to figure out. But there are millions of apps out there which do all kinds of far more insidious call-homes, so it’s clearly not an unusual thing to do.
Please don’t take my semi rants at the start as not valuing Free or OS work, I have been involved with OS for over a decade.
My only “gripe” was that you went to the trouble of explaining the splash screen in great detail but failed to mention this network usage requirement for free users.
This IS a permission in Android(that we as a developer must ask for) and yes it’s in the EULA and we all should read it like a Tech Manual, 
but you don’t say anything about this network connection requirement in the bread and butter advertisement for licences tiers.
I am 100% with you, I hope my post didn’t come across differently. I think it is a really fair deal to contribute to Roli’s assets by providing usage statistics. My only point was, it would have been nice to have that noted alongside the splashscreen in the tier chart.
I am still more than happy with my choice to use JUCE for my developments.
Keep up the good work!
I think it is also worth reminding that the Free License, which is the only for which splash screen + analytics are required, is an entirely new option introduced with JUCE 5.
As such, no previous user of JUCE is retroactively forced to use it.
Instead, I think old and new developers that use JUCE should see the Free License as a new alternative that they may wish to opt-into if they like. If they don’t, then the two other routes (GPL or Paid) are still there as they were before, nothing changed for them.
(in short, I think @jules in the summary post above could have added a big fat [NEW] tag next to the “Free License” entry, to make that more prominent)
small edit: the above being said, I also agree with those who think that the presence of the analytics stuff could/should have been mentioned together with the splash-screen in the email/website communication. Doing otherwise gives the feeling that ROLI would have liked it not to be really noticed.
I don’t mean to suggest evil stuff is going on either. It’s just that data tracking is a pretty touchy subject and so I think everyone should be careful about it. If it’s in the code base then (regardless of license tier) we should all be making sure that the code doing what it’s supposed to.
It is in #ifdefs, so it won’t be in the compiled code, if you didn’t opt-in. So not that bad after all
I think we all understand you’re not doing anything nefarious here.
There are various state laws in the US (not sure about the EU, but I’m guessing it’s just as varied) where the provider of online applications that collect identifiable user data must provide a privacy policy and comply with it, in order to legally sell or provide a product in those states.
So does ROLI provide the privacy policy, or do we?
Given that our customers don’t know about Roli, we have to inform them.
See the Juce 5 T&C under 10.1:
Users of free versions of JUCE, such as JUCE Personal or JUCE Education, may not opt out of the tracking of IP addresses associated with the use of your Application by end-users. You agree to inform the end-users of your Applications about our collection of their IP addresses, if applicable, and have your end-users agree to such collection.
It’s you. I also see the problem, that the data is going to a third party… I don’t know, if that is a problem. It might be possible, because it is anonymised. But IANAL
It’s your app - we have no idea what it does, or which bits of our code you decide to use in it, or which countries or states or app-stores you’re working in, so there’s no way we could do this for you.
We are adding a pop up window to the Projucer that will display information about our application data usage, and allow Indie and Pro users to opt out.
If only intending to release software thru the GPL license, can developers also opt out of the Projucer usage analytics thing?
If not a problem it’s certainly a can of worms. Ideally we get a lawyers to reassure us that it’s not personal data being collected by ROLI. Maybe this has already been done?
The issues are pretty much covered in these two links:
https://ico.org.uk/for-organisations/guide-to-data-protection/key-definitions/ - what is personal data.
And:
Otherwise:
[deleted some stuff here because I think it’s wrong … and besides didn’t really cover the international issues…]
Now the thing that those links don’t cover is the use of static IP addresses by individuals … but I think that’s an edge case 
Users of free versions of JUCE, such as JUCE Personal or JUCE Education, may not opt out of the tracking of IP addresses associated with the use of your Application by end-users. You agree to inform the end-users of your Applications about our collection of their IP addresses, if applicable, and have your end-users agree to such collection.
What exactly is being sent anyway? Just that JUCE is in use at some IP address? Or is information about the application being sent as well? The users computer?
