Closed IzzySoft closed 1 year ago
Thanks for your comment! I'm not sure how Collect was listed on your repo and I'm sorry that it doesn't meet requirements. Feel free to unlist.
We will be removing the Google Drive API this coming fall.
We have no plans to remove the Mapbox or Google Maps APIs at this time. We do also include osmdroid -- end-users can switch between the three libraries.
We don't have plans to replace the others at this time because alternatives are either cost-prohibitive, don't meet requirements, or have too high of a switching cost. As you know, there are real tradeoffs there.
First thanks for your reply!
I'm not sure how Collect was listed on your repo
It's FOSS and has a libre license (one approved by OSI/FSF), but was not included with F-Droid – which is where my repo comes in, if possible. We should give the people who care a lot about FOSS and privacy a good selection to choose from, which is what I (with my repo) try to help with.
Feel free to unlist.
Well, that wouldn't be the outcome hoped for; I'd only do that if all other options fail. Main concerns are that with proprietary libraries, you as the developers of the app can never be 100% sure if they (only) do what their makers advertise: you cannot check against their code. And especially when their makers are those known to live on selling our data, I'm always skeptic.
I see your problem: replacing so much also takes a lot of time, testing – in addition to what you already pointed out. May I make a suggestion for a compromise I hope both sides can live with?
Would it maybe possible to have a separate build flavor ("lite") where at least the non-essential of the above "offenders" are removed? You'd then certainly get sufficient data from the majority installing your app via PlayStore – while those working with more sensitive data¹ and having concerns might feel easier with the flavor that has less "Google ties". That flavor could come without the 2 analytics frameworks, and maybe also without Google Maps (as OSM would be still available). Since you plan to remove Drive anyway, that would shrink the list of "offending libs" by at least 3 or 4 (maybe more which are just dragged in as dependencies). That would, by the letter, still be a bit beyond the inclusion criteria – but counting e.g. all remaining Firebase libs as one (i.e. "just Firebase, even if multiple times"), I could interpret that as "acceptable" then.
Thanks in advance for considering! It would be really great if such a solution would be possible.
¹ if collections made would include personal data, it could otherwise not be done with your app without violating GDPR, or at least being in the very dark gray zone
Thanks! We’ll consider this as part of our roadmapping process (https://getodk.org/roadmap)
@lognaturel may I ask what the status of this is? I've looked at the linked roadmap, but didn't spot a corresponding item. Thinking maybe it was already processed I've taken the latest APK provided and scanned it, all the above "offenders" are still there.
Note that the app was marked to be removed if the issue cannot be solved in time (date currently stands on July 31). An app that deals with PII (and as your roadmap states, even with sensitive ones like health data) cannot have trackers (here: Crashlytics, Firebase Analytics) inside which you cannot control (not saying YOU would actively send data somewhere – but those libraries are proprietary, so you cannot make sure nothing will be transmitted "accidentally"; wouldn't be the first time with Google, unfortunately). These 2 (marked with "Tracking" above) are my main concerns. The others are in a "gray zone", though some a little "dark gray" – while it would be good to have all the "NonFreeDep" removed as well, removing the "Tracking" ones would be what's needed to keep the app in my repo.
Apologies for my insistence, but privacy is an important part of my work – and people using my repository trust that I take care for this. We have a responsibility for the data of people when dealing with it.
Thank you for coming back to this. Please remove from your repository for now.
Just done, effective with the next sync around 6 pm UTC. Please give me a ping once the underlying issue has been solved, and I'll gladly re-establish your app.
Btw: Thanks for going as far as opening a merge request for it. Had to close it though, what you found was the list of library signatures – os obviously there are some apps using libraries from here, which is why they are listed there. That list is for checking what libraries apps include and whether they are really FOSS. Fr details, see e.g. my article Identify modules in apps.
Great, thank you!
Whoops, apologies for going to the wrong place, I saw the issue and evidently took an overly mechanical approach! Are the actual resources used to build your repo open source?
see e.g. my article Identify modules in apps.
Very interesting, thank you.
I saw the issue and evidently took an overly mechanical approach!
No need to apologize – I bow to the efforts you've taken! Would the actual YAML files be part of that Git repo, it would have been clearer – so the fault is rather mine. One day I might consider adding those metadata as well.
Are the actual resources used to build your repo open source?
Sure: my parts are licensed GPL-2.0, F-Droid's use AGPL-3.0. Most of the code is there, in the very same Git repo. If you plan to set up your own F-Droid repo, there are two articles you might be interested in, starting with Setting up a simple binary F-Droid repo and following up with the next part of the series, Extend the „simple binary repo“: Screenshots & more. If it's just for your own app, you won't need my entire framework (which takes care for update checking of the about 1.100 apps currently listed, library scanning, malware scanning etc. pp.). Just check the two articles; should you run into questions, I can try to help.
Very interesting, thank you.
Gladly! And happy if that helps you :smiley: Some devs have included my scanner with their workflows (to make sure no dependencies sneak in), and F-Droid itself uses it for its issuebot. So be welcome to use it if you like!
Thanks all around! I'll hopefully be seeing you back over there in the not too distant future. 😊
Looking forward to that, thanks!
ODK Collect version
v2023.1.2
Android version
n/a
Device used
n/a
Problem description
Your app is currently listed in my repo, as updates are disabled at F-Droid for quite a while now. It just came to my attention today that the number of non-free and tracking libraries exceeds those permitted with the inclusion criteria by far:
Which means I'll have to remove it from there as well – unless you could provide the APK of a build flavor cutting that number down, so I could switch to that build flavor. Would such a flavor be possible? There are replacements for some of those libraries/SDKs you could use if they match:
Steps to reproduce the problem
Just check the
build.gradle
, or use a library analyzer :wink:Expected behavior
no (or almost no) non-free libraries in a FOSS application :see_no_evil:
Other information
Thanks in advance for your time spent on this!