[Replicant] Review of MicroG and collaboration with Free Software Directory

[Denis 'GNUtoo' Carikli]

On Fri, 23 Jul 2021 11:05:59 -0300
Adonay Felipe Nogueira via Replicant <replicant at osuosl.org> wrote:

> Em 16-07-2021 12:05, Denis 'GNUtoo' Carikli escreveu:
> > Are they supposed to be used as-is or are they supposed to be
> > integrated in the Android distribution somehow?
> 
> As far as I have researched, they either require the system
> distribution to support signature spoofing ([1]) or they use the
> “package” and “android:name” attributes on their AndroidManifest.xml
> (the so called application/activity/service/intent identity or
> “true/system names”) in a way to replace their corresponding Android
> originals (to get a proper idea, clone some of their source
> repositories and search for an *extended* regular expression such as
> “com(\.google)?(\.android)?”).
> 
> However, I don't know if there are any other requirements.
Thanks.

So it's something like f-droid privilege extension. That could be
integrated if there is some interest and that people send patches for
that. We'd probably need to build it from source in that case to make
sure that it can be built and that we ship corresponding source code
with the releases.

> > At least that functionality is not suited for distributions that
> > follow the Free System Distribution Guidelines (FSDG)[2] because
> > "The distro must contain no DRM, no back doors, and no spyware."[2].
> 
> Interesting take.
> 
> I don't know if the FSF or the reviewers of FSDG-fit distros consider
> sending Push Notifications information to a pre-defined set of
> third-parties an infringement of that section of the FSDG, if the core
> of the issue is just that it would be sending it to a set of
> centralizing parties such as Google or, if Push Notifications itself
> is to be considered a problem (since the concept basically involves a
> third party storing and spying on the messages sent to the client
> 24/7 just for the sake of power saving). In any case, I do recognize
> that this is a good argument. I'll open a discussion on the review
> work group to raise and question these points.
I guess that what typically happens is that the software is patched to
be FSDG compliant in general so I'd suppose that it would be the same
for spying though I don't have examples in mind to check for spying.

In the Parabola blacklist (https://git.parabola.nu/blacklist.git) most
of the software mentioned there seems to be blacklisted for freedom
reasons (and often replaced by free versions). Many of the packages
that were originally problematic are also probably just patched and not
in that list.

As if upstream is notified, I've no idea. I personally try to work with
upstream when working on Parabola at least, but I guess that it takes
more time in the short run (and might save time in the long run
assuming that local patches don't accumulate when there are less
patches). I also tend to do it more when I already know how to
contribute patches to the upstream project.
> > That would be interesting but I've no idea of the requirements of
> > the free software directory.
> 
> Mostly they are the same as the FSDG itself.
Nice. In that case I probably need to make sure it can be built in
an FSDG distributions at least.

Then I could try the GNU/Linux-libre for the issue of the apk being
shipped that is built differently if it's somehow not reproducible.

I've looked a bit closer at RepWifi and it uses ant as the build
system, so it's probably even compatible with the Replicant 4.2 SDK.

I don't recall if we ever built it in Replicant or if we always shipped
the APK from f-droid.

> I'm no longer a reviewer myself, but back when I used to do those, an
> eligible entry would have all its dependencies either on the Directory
> or on the repositories of FSDG-fit distros (to simplify: any
> dependency of any level or any strength, except “system libraries”
> per GPL definition).
ok. We should probably see with GNU/Linux-libre and/or the Free
software directory how to handle that for Android as there is way more
risk of finding problematic software in Android than in GNU/Linux due
to how things are packaged (it's much easier to check a package
definition than the Replicant source code, even if there are still
mechanism to generate licensing information somehow in Android).

> If the release is historical (see [2] to know what I mean) we might
> still be able to add it to the Directory.
Here I'm not sure that historical applies for Android in the same way as
older Android versions tend to stay around for very long, and you can
also use older build systems to build applications that run on more
recent Android versions.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20210723/152f026b/attachment-0001.asc>