non-free dependency: Google AR Core

[IzzySoft]

I've just scanned the APK built by F-Droid, and see:

Offending libs:
---------------
* Google ARCode (/com/google/ar/core): NonFreeDep

1 offenders.

This would mean all affected builds need to be disabled, as that's a no-go for F-Droid. So the questions are:

• I've looked at the corresponding smali code (generated via apktool d de.westnordost.streetcomplete_4504.apk), this does not look like a "stub". Am I mistaken?
• If it's no stub (which is to be assumed, as it's explicitly implemented), is this essential – or can it be excluded e.g. by using a build flavor, or replaced by something else altogether?

Being a StreetComplete user myself, and just having made a big announcement at Mastodon how useful the app is, I'd hate seeing it disabled at F-Droid – so I really, really hope you can find a way to mitigate this.

[matkoniecz]

F-Droid can maintain a patch disabling this and remove functionality in few quest relying on it which measure width of some objects.

There is already fallback to measuring width with a tape and entering data manually.

[matkoniecz]

If SC can be changed without making it worse in way that makes maintaining patch easier, I guess that they can submit such pull request.

Or if there is a drop-in replacement for this library (afaik no) that also would be nice to know.

[licaon-kter]

I've seen and asked about this in #3709 at that time and was at ease since it said "but it's foss"

But now looking at https://github.com/google-ar/arcore-android-sdk and comparing with the AAR served by maven https://mvnrepository.com/artifact/com.google.ar/core/1.32.0 which has .so's and classes and whatnot, I fail to see WHERE is the source code exactly. :(

/LE: I've disabled the affected versions for now: https://gitlab.com/fdroid/fdroiddata/-/commit/94c0447a535e3ceed3cd41dd25d83b4666b378b3

[IzzySoft]

Thanks for the fast answer! Indeed I'm not aware of any "smooth replacement" either (but I'm no dev, so I might simply have not heard of it). Thanks for the detail that it's at least not "crucially essential"! @licaon-kter maybe you could take a look at how to achieve that, so builds can be re-enabled?

[HolgerJeromin]

Adding some references for open AR replacements:
#2093 (comment)
microg/GmsCore#1672

[westnordost]

@IzzySoft so which consequences does this scan have at all?

I'd not like to push an F-Droid version of the app that has the AR feature disabled. Only because one installed the app from F-Droid shouldn't mean that the choice is taken away from the user whether he wants to install a non-free app to enable the AR feature or not. As HolgerJeromin linked in the previous comment, you do not even need Google Play Services as you may be able to sideload the ARCore app from another source.

To clarify:

1. The dependency in question is com.google.ar:core and that dependency itself is open source, see https://github.com/google-ar/arcore-android-sdk. So maybe that warning is imprecise(?)
2. That library does little else than to communicate with a separate non-free app on the smartphone called Google Play Services for AR (renamed from ARCore) which does the actual work. If it is not installed and Google Play Services are installed, the above library will ask the user to install it. If not, nothing happens and the AR feature simply does not work. (If I remember correctly, not even the button to start the AR measurement will be shown.)

[licaon-kter]

@westnordost can you read my comment above pls? This issue is not about the separate app.

[westnordost]

I fail to see WHERE is the source code exactly. :(

It is on github. Certainly not in the AAR, I do not think an AAR is meant to contain source code.

[westnordost]

Hmm right... there is not a lot in that repository, most of all, no java code.

[IzzySoft]

@westnordost thanks for the link to the AR repo. But please take a look at the license there:

Governed by the ARCore Additional Terms of Service at
https://developers.google.com/ar/develop/terms

That's "source available" at best (if the code would be there, as you just found out), but not FOSS.¹ And as you wrote yourself, you just include the AAR. F-Droid needs to build it from source (to make sure it matches the source code presented – which certainly would fail here I guess if the source repo does not contain the source).

If I remember correctly, not even the button to start the AR measurement will be shown.

So maybe as a "quick fix" we can set up a rule in the build recipe to "patch out" the two implentation lines, to at least keep the app listed at all until we found a final/better approach?

---

¹ I just see that applies to the pre-compiled binaries – but iif I understood correctly that's what you use by including the AAR? The code itself seems to be Apacke-2.0 – if we can find (and compile) it…

[westnordost]

On the other hand, com.google.ar:core is listed as licensed under Apache License, Version 2.0 on Maven Repository because in the POM file it is stated to be that license by the library author (Google LLC). So either Google violates their own terms in not also publishing the source code or they have hidden it really well.
If they want their additional terms of service to apply to that Android library published via Maven too, then they should (have) stated that in the POM.

But I feel there is some missing information here. That

* Google ARCode (/com/google/ar/core): NonFreeDep

is flagged can only come from that someone added that rule manually in some tool, right? So, how come it was added? Maybe a rationale can be found in the commit message (in the repo for whatever tool is this).

Anyway, at the moment I am not inclined to create a special version for F-Droid without this dependency. You'd have to do this yourself, albeit it is not a lot of work to create a patch.

The reason is that I don't accept that the (alleged) failure to comply with their own open source license of some dependency this app is using should lead to expulsion of this app from the F-Droid. As far as I am concerned, for me it's enough to know that the library is open source on paper, because that means that the app including all its dependencies may legally be distributed under these terms, i.e. including decompilation and modification of the code in e.g. the com.google.ar:core dependency even if the source code of that is nowhere to be found.

[westnordost]

Nevermind my statement about the POM, I noticed that while it says Apache License, Version 2.0 in the name, it actually links to the LICENSE file in the repo. However, in that LICENSE file in the repo, they make clear that the additional terms of service only apply to

• tools/arcoreimg/linux/arcoreimg
• tools/arcoreimg/macos/arcoreimg
• tools/arcoreimg/windows/arcoreimg.exe
• all files ending with *.apk

, with the rest being Apache License, Version 2.0. The AAR published via maven does not contain any of these.

F-Droid needs to build it from source (to make sure it matches the source code presented – which certainly would fail here I guess if the source repo does not contain the source)

As far as I know, F-Droid builds with gradle build, which does not build every dependency itself but (just) download all the dependencies from maven central and google (i.e. the JARs and AARs with precompiled .class files).

[licaon-kter]

It's all fun and games until I ask again about the source? I've got nothing to build...

[westnordost]

How did it work before up until v45.2 then?

[licaon-kter]

How is it that we didn't scan for this dependency before?

As usual, not enough hours in a day for contributors to port nonfreedep from one source ( https://gitlab.com/IzzyOnDroid/repo/-/tree/master/lib ) say via grep -i nonfreedep libinfo.jsonl|cut -d ":" -f2|cut -d "\"" -f2|cut -d "/" -f2-|sed 's!/!.!g' to the fdroidserver scanner ( https://gitlab.com/fdroid/fdroidserver/-/blob/master/fdroidserver/scanner.py#L62 ).

Blacklisting bad stuff is a never ending war, there's always one more.

[licaon-kter]

/rant @eighthave maybe merge some of the "scanner" MRs that await too? https://gitlab.com/fdroid/fdroidserver/-/merge_requests

[westnordost]

That was not my question. How did it build before if allegedly the F-Droid build bot builds each dependency itself from source instead of just the app from source? (That's what I understood you implied in #4289 (comment))

[licaon-kter]

We don't build everything from source, see: https://f-droid.org/en/docs/Inclusion_Policy/ (starting with Though we tried to build everyting from source).

As it would be a wasted effort when things are build already from source. That's the issue here, this dep is hosted on a "trusted" maven repo but they didn't do due dilligence to verify if truly FOSS. Not an isolated case. More info in this future post: https://gitlab.com/fdroid/fdroid-website/-/merge_requests/838/diffs

[IzzySoft]

@westnordost I'd gladly state that I was wrong all along, and apologize in any way – if only the source were there. Until now, all we have is a binary AAR file and a statement that it's supposed to be Apache-2.0 – a license that states we "may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form" – thus granting us the freedoms required to be counted as "F/LOSS". But we cannot make use of that freedom if the source is not even there. There's not even the freedom to investigate the source, making sure what it does and that it corresponds to the AAR – if the source cannot be found.

All I see in google-ar/arcore-android-sdk are some media files, C headers – and example code. But not the source code of this AAR. You've seen that for yourself. So if the source is not available, it cannot be "open source" – and thus cannot be accepted by F-Droid 😢 And no, I don't see any "alternatives" behind the links @HolgerJeromin posted: if I didn't miss something essential, they basically state that you can use AR with StreetComplete if you simply sideload that APK. Which is only possible because StreetComplete includes this AAR.

I fully understand your frustration, Tobias – and believe me or not, I fully share it. I just started using SC a little more than a month ago, and already I am so fond of it that I recommend it everywhere, motivating people to use it. I even made something I didn't do since my repo exists: I set up to have it serve the expert edition, despite of its being more than two times over the size limit (I've never let an app enter my repo that way – that's rather the time I unlist an app). So I very much hope we can find a solution here. Ignoring the fact doesn't count as such (we cannot do that) – so it's either we turn up the source, or we need to "outsource" it somehow.

Now I thought about asking them at their repo – they won't accept that: all questions shall be asked at SO using the ARCore tag. Searching the tag along with the keyword "source", I've stumbled upon Is Sceneform 1.17.1 open source? – which states:

As it is identical to 1.15.0 which is closed source, and the source is not provided separately, it is probably safest to assume it is actually closed

Looking into the smali of SC, there is /smali/com/google/ar/sceneform – so where does this come from? AAR from the same source? For this at least there seems to be an open source variant available: sceneform-android, but it unfortunately seems to depend on the very same ARCode we cannot find the source for (though it seems to be optional if you only need Sceneform itself). I could not find an answer to the sources of Core, though, nor did a web search succeed (just found the same repo, Google's docs, and plenty of how-to-use).

So if we cannot find the source, and neither a FOSS replacement: can that maybe moved to an addon entirely, so the app itself stays FOSS and thus at F-Droid?

[IzzySoft]

PS: For what it's worth, I started a shout at Mastodon. Let's see if it turns something up…

[westnordost]

Sceneform is a separate library and is not a problem. The code is available.

---

@licaon-kter: so that makes this a question of policy rather than a question of necessity. You do not want to have any apps in F-Droid whose dependencies you could not theoretically build from source regardless of whether they are licensed with an open source license or not.

I've read through the Apache license 2.0 and it looks like indeed the licensor does not commit himself to also publish the source, there is no mention of it. Hence, to my understanding, a work can be licensed with Apache 2.0 without the source to be available.

However, this does not seem to touch on the rights of the licensee to produce derivative work, in other words, decompile it, make modifications, redistribute under the same terms:

Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

(comment one condition)

[...]
(c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; [...]

But since there is no (separate) source form of this work, this doesn't apply. Definition of source:

"Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

What I understand from that is that as far as the license is concerned, the compiled blob of bytecode is the "preferred form for (providing for) making modifications" by the licensor, as there is no alternative. E.g. compare to a similarily licensed PNG file of e.g. some complex logo - in the absence of the GIMP "source" file, the PNG is the preferred because only way to make modifications by the licensor.

Most importantly, it doesn't take away any right of the licensee to produce (proper) source code as a derivative work.

My point being: the licensee has every right to decompile the bytecode, make modifications and redistribute it, and that's what free software is about, that you are granted the right to do it. It is not about the ease of doing so. (An obvious flaw in non-GPL licenses)

Hence, I say that this a question of policy, i.e you do not want to include any apps whose dependencies do not also include the (human readable) source code in F-Droid. Regardless of the license.

---

Assuming that the apparent non-inclusion of the source code in the Apache licensed work was even a deliberate act rather than an oversight on the basis of "meh, don't care" by Google ARCode devs, wouldn't it solve the policy issue if a decompiled version of that lib was available somewhere as a "derivative work"?

[mnalis]

I've read through the Apache license 2.0 and it looks like indeed the licensor does not commit himself to also publish the source, there is no mention of it. Hence, to my understanding, a work can be licensed with Apache 2.0 without the source to be available.

Yes, it can. It is then however neither free software (i.e. lacks "preferred form of the program for making changes in") nor open source (i.e. is not "software with source code that anyone can inspect, modify, and enhance.") - license notwithstanding (kind of like Microsoft Windows is not free software nor open source software - although it contains, in binary form, significant amount of BSD-licensed code, and Microsoft Windows do show you all those licenses)

F-droid is a repository of "free and open source software (FOSS)". If software is not FOSS, it cannot (should not) be included there. And yes, that is because of their FOSS-only policy (which I personally happen to wholeheartedly approve of), which is arguably only reason for it's existence.

"Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

What I understand from that is that as far as the license is concerned, the compiled blob of bytecode is the "preferred form for (providing for) making modifications" by the licensor, as there is no alternative

No, I'm pretty confident you misunderstood there. Source is "preferred form for making modifications" -- not "only form actually available publicly" or anything like that. So unless the original authors of software made that .aar library by typing numbers in hex editor, but preferred some other way of creating it, than that other way is actual preferred form of making modifications, and thus the Source is that what original authors used. Even minified javascript (for example) is not source code - because it is not the preferred way to write javascript.

My point being: the licensee has every right to decompile the bytecode, make modifications and redistribute it, and that's what free software is about, that you are granted the right to do it. It is not about the ease of doing so.

Well, it's not what free software is about, at least if you ask Free Software Foundation (/ RMS) who coined that term "free software". See link above, specifically part starting with Therefore, accessibility of source code is a necessary condition for free software. Obfuscated “source code” is not real source code and does not count as source code.

Hence, I say that this a question of policy, i.e you do not want to include any apps whose dependencies do not also include the (human readable) source code in F-Droid. Regardless of the license.

Yes, free software / open source / FOSS / f-droid is always about policy, regardless of license. In fact, you can have code which does not have any license at all (for example, because it is Public Domain, i.e. not covered by Copyright and related rights, and thus not needing license to relinquish that copyrights) - and it can still be free software and open source and included in f-droid.

---

Assuming that the apparent non-inclusion of the source code in the Apache licensed work was even a deliberate act rather than an oversight on the basis of "meh, don't care" by Google ARCode devs, wouldn't it solve the policy issue if a decompiled version of that lib was available somewhere as a "derivative work"?

Uhhh, I wouldn't really want to venture there, nor have people I've become fond of paint such targets on their back for google lawyer-army to practice on, even if they can prove beyond doubt that that binary package indeed corresponds in full to that abandoned github page, and that it's indeed intended to be its license (which is far from conclusive).

[matkoniecz]

in fact, you can have code which does not have any license at all (for example, because it is Public Domain, i.e. not covered by Copyright and related rights

note that in this case it is better described as being licensed as public domain, not as having no license at all

in case of not having any license at all and not having copyright waived by law - works are fully copyrighted

[matkoniecz]

Looking into the smali of SC, there is /smali/com/google/ar/sceneform – so where does this come from?

I am confused by google-ar/arcore-android-sdk#1049 - is sceneform being

• the same as one being published as open source by Google at some point and in new versions of arcore it is missing, because it is not developed and ended on Google graveyard
• developed further but as closed source available only as binary blobs (on which license? is it conflicting with GPL?)

[IzzySoft]

@matkoniecz If I read that correctly, Sceneform was abandoned. The last thing they did was fully open-source it¹, then archive its repo. There's a sill-alive and community-maintained Sceneform fork available, though.

¹ _{v.15 was closed source, 1.16 open-source with parts missing, v1.17 then added missing source parts}

My toot on Mastodon meanwhile brought in some answers. Basically, nobody seems to be able to find the full source; even Marvin W (author of microG) states it is incomplete. Another dev will raise the question in Google's issue tracker today; let's hope we get a positive answer there.

[matkoniecz]

v1.17 then added missing source parts (...) nobody seems to be able to find the full source

So StreetComplete is using an abandoned project that was open sourced - but in way that still left part of code not actually published?

In such case I would at least try asking to publish also missing parts. So "another dev will raise the question in Google's issue tracker today" seems a good next step.

[IzzySoft]

Here's the link to the issue: https://issuetracker.google.com/issues/242730604 (whoever has a Google account can give it a +1 or chime in).

[mnalis]

Are then the quests always disabled by default? The quests should be disabled by default if no AR measure is available (because you need to have a measuring tool with you otherwise to solve the quest)

Yes, quests are disabled by default - the patch basically just makes ArSupportChecker() return false (and removes all offending imports and affected code), and so the SC then behaves as if the phone does not have AR support (so it disables quests by default and does not show AR button in them).

So what's the best solution here?

Ah, I have no experience there, but as @TheLastProject notes, and since we plan to make AR functionality a plugin anyway in relatively near future (or even Google might decide to open source it), the f-droid patch solution would seem simplest to me. Thanks to @TheLastProject example, I could make and submit such MR to fdroiddata, if all agree that is the best approach?

[westnordost]

For the F-Droid patch solution: What happens if one of the files the patch is applied to is changed? The files that this patch touches are not likely being touched except the app/build.gradle.kts which is changed for every release (but at a different position)

[TheLastProject]

They're regular git patches. Git can do some small resolving and generally doesn't mind if unrelated sections get changed (as you can see, I can re-use the Element patches for several versions), but it's really dependent on git itself.

In the patch no longer applies cleanly, git will throw an error and the build will fail until the patch is fixed by someone.

[westnordost]

I think then the solution to post the patch at F-Droid is the easier solution because of the relative isolation of the code and no necessity to rebase+add a fdroid specific tag to a branch on each release

[mnalis]

OK, I've done a fdroiddata merge request here: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11785

@TheLastProject you seem to have experience with the process, if you have a minute, could you take a look and say if that looks good to you? I've tested that the patch applies against v46.0, v46.1, v47.0-alpha1 and v47.0-beta1; also CI/CD for that MR on GitLab seem to have passed OK.

I've updated added a new block for v46.0 with a patch, do you know will f-droid automatically realize it should also use that patch for v46.1, v47.0 and newer when it tries to add them? Or what would be the procedure for the future versions?

[TheLastProject]

I see linsui responded to the MR already, they are a lot more active in fdroiddata than I am so I'd recommend listening to them over me :)

I've updated added a new block for v46.0 with a patch, do you know will f-droid automatically realize it should also use that patch for v46.1, v47.0 and newer when it tries to add them? Or what would be the procedure for the future versions?

Well, right now update checking is disabled. But if all is good it can be re-enabled. With Auto update checking enabled, F-Droid copies the build instructions of the previous version so it'll automatically try the exact same patches for new releases too.

Talking about new releases, is there any reason v46.0 is being added to F-Droid instead of v46.1, given v46.1 seems to be the latest stable?

[mnalis]

I see linsui responded to the MR already, they are a lot more active in fdroiddata than I am so I'd recommend listening to them over me :)

Yup, I'll have to do more research there where to put extra commnads. Your method of just providing patch seemed simpler to me than patch + rm + sed proposed in MR, but I can see how the later would be more robust...

Well, right now update checking is disabled. But if all is good it can be re-enabled. With Auto update checking enabled, F-Droid copies the build instructions of the previous version so it'll automatically try the exact same patches for new releases too.

That is good news! Is that auto checking something I myself can enable in a patch (I see there is field called AutoUpdateMode: None, but it has that value in your example too, so I suspect that is not it), or is it more of fdroiddata admin thing?

Talking about new releases, is there any reason v46.0 is being added to F-Droid instead of v46.1, given v46.1 seems to be the latest stable?

well, v46.0 was the first where the patch applied cleanly (it fails on v45.x and lower), so I though to go with that, and then see if autoupdate code picks it up for v46.1 automatically.

[TheLastProject]

That is good news! Is that auto checking something I myself can enable in a patch (I see there is field called AutoUpdateMode: None, but it has that value in your example too, so I suspect that is not it), or is it more of fdroiddata admin thing?

I've added a suggestion on the MR, let's see what linsui thinks :)

well, v46.0 was the first where the patch applied cleanly (it fails on v45.x and lower), so I though to go with that, and then see if autoupdate code picks it up for v46.1 automatically.

I'm mostly wondering because it seems a bit weird to me to go this route unless there's a reason someone would want to explicitly run v46.0 and not v46.1.

Worst case scenario, the next build cycle starts after the merge but before the next checkupdates, which means users will first get an update to v46.0 and then a few days later an update to v46.1, which would mean users would first update to a version that has some known bugs already fixed in v46.1 and they'd be bothered with a new update again real quickly. Given each update is 56MB (looking at historic data), that could be a bit harsh on users with bandwidth caps with no real gain as far as I can tell.

[mnalis]

I've added a suggestion on the MR, let's see what linsui thinks :)

thanks!

I'm mostly wondering because it seems a bit weird to me to go this route unless there's a reason someone would want to explicitly run v46.0 and not v46.1.

People might want to try to pinpoint in what version something broke... But yeah, it is a little thin for a reason 😃
So I've updated MR to reference v46.1 now.

[IzzySoft]

@mnalis apologies I didn't respond to your ping in time (I was on vacation) – luckily Silvia (@TheLastProject) jumped in with the same track I'd have proposed. Glad a way was found to get SC updated at F-Droid again, looking forward to the update! I became quite addicted to the app I have to admit and am quite proud of my ranking 🙈 Cyprus needed a lot of SC-love, and it received it during the past 2 weeks 🤩

[riQQ]

StreetComplete 46.1 without AR core is available on F-Droid as of yesterday, September 29th.
Thanks @mnalis

[opk12]

licaon-kter: so that makes this a question of policy rather than a question of necessity. You do not want to have any apps in F-Droid whose dependencies you could not theoretically build from source regardless of whether they are licensed with an open source license or not.

No, the source is necessary to ensure that the binary is malware-free, by public scrutiny and reproducible builds (see https://f-droid.org/docs/Reproducible_Builds/ ): when independent builds give a byte-per-byte-identical result, you do not have to trust the build machine, kids, roommates and random guests of whoever submitted each lib binary. That these security hygiene concepts do not exist in Google Play, Windows and generally compulsory education / public legislation is a shame, not something that should be encouraged. This can't be done through decompiling, as it won't help with native code and R8-minified stuff, and is illegal unless allowed in the license.

[FloEdelmann]

Version 47.0 is now available on F-Droid, so everything is working as expected again. Thanks to everyone involved fixing this!

[IzzySoft]

Thanks a lot for all the efforts all of you have put into this. Very much appreciated, and makes me love (and recommend) the app even more! 😍

[mnalis]

@FloEdelmann although, if we closed this issue, we should probably open another issue linked to this one - while F-droid builds now work, the issue with ARcore is not fixed - SC is still in copyright breach on Google Play (and GitHub Releases page) and a final solution (either Google actually opensourcing the lib, or the ARcode being moved to separate companion app + f-droid patch being removed) is still pending.

See this comment for example:
#4289 (comment)

[westnordost]

The Google ARCore team seems to have finally done something about the open license issue by clarifying in the LICENSE.md that indeed the library is not open source (but only some related files in that repo are open source):

google-ar/arcore-android-sdk@6f887e1#diff-c693279643b8cd5d248172d9c22cb7cf4ed163a3c98c8a3f69c2717edd3eacb7R11-R13

So, with the certainty now here, it is time to remove ARCore from StreetComplete.

[mnalis]

Just a short note: before StreetComplete version with removed ARCore is released, we should also undo f-droid MR 11785, so F-droid builds can continue to build new version normally too (as it will take some time for new MR to be accepted there).

I can handle that f-droid part again (if you prefer), when the patch removing ARcore lands in StreetComplete master branch.

[westnordost]

Done now. For v51.0 onwards, the f-droid MR 11785 can be undone. (Note: I do not feel responsible for this because I amm also not the author of MR 11785, someone else will have to do that)

[IzzySoft]

Thanks Tobias! I've forwarded your message to the corresponding MR, asking my two colleagues who were working on it to take care (and linking them here).

[IzzySoft]

It's done. Thanks again for all your efforts, Tobias!