FDroidCompliance¶

Introduction¶

F-Droid is a community-maintained software repository for Android based operating systems. It is similar to the Google Play store.

Replicant has depended very heavily on F-Droid for a long time now. End users expect app "stores" on their smart phones.

Unfortunately, F-Droid is not currently compliant with the FSF's Free Software Distribution Guidelines, which required Replicant to remove F-Droid from its upcoming 6.0 0004 release so that Replicant can continue to be FSDG compliant.

Much discussion has already been had within Replicant and between Replicant and F-Droid about how F-Droid can be modified in order to make it FSDG compliant so that it can be included again in Replicant in future releases.

F-Droid's build server has not purely free from proprietary blobs for a while now: https://gitlab.com/fdroid/fdroidserver/-/issues/383

It is important for F-Droid to be built using free tools.

Android has a decentralized app building process. This can be a very positive thing, fostering a much more diverse and playful ecosystem than app stores that Google and Apple provide on their smartphones's OSes.

Due to the freedom issues in the F-Droid build system though, a threat exists to user privacy and security.

One of these freedom issues is the fact that far too many pre-builds exist.

Replicant wants an app distribution system that runs a free toolchain so that users can rely on a fully free ecosystem.

One way of achieving this might be to utilize beuc's rebuilds: https://android-rebuilds.beuc.net/

Replicant wants to write environment setup bash scripts to build FDroid with beuc's version of the SDK in order to be able to provide a reproducible build environment that others can test.

Another freedom issue with F-Droid is that F-Droid includes apps with anti-features that are not compatible with the GNU FSDG. These apps are available alongside apps that are compatible and they are only marked with these anti-features. See #1629 for development efforts and further information on this topic. https://redmine.replicant.us/projects/replicant/wiki/FDroid

Plan¶

Define what to work on:
1. Cleanup this draft
2. Fill the missing information that can easily be found

Rationale: we need a rough idea of what needs to be worked on.

In parallel for Replicant:
a1. Precise how the people want to be paid (per tasks, hours, per months, etc) and the amount
a2. Find a way to report the progress if not paid by the task (quick blog post, wiki status, very fast mail on the mailing list, etc). /!\ It can take up to 1/2 day per week, as for the crowdfunding to free and upstream the Allwinner VPU. => Find a way to do it that suits people.
a3. Find out how to do it legally (employment, contract work, grant, etc)
a4. Steering commitee vote on that
a5. Find a way to legally formalize it through the FSF if needed

In parallel for NLnet:
a1. Write a very rough proposal and send it, don't wait too much as we might get a shot sooner. Make sure to be accepted in round 1 before starting to work on it or make sure to have a backup (like Replicant money).
a2. Fill the budget by calculating hours x price per hour. Keep in mind that it's a grant so you don't have the usual taxes (you need to check how to declare grants with your state) but the usual employee stuff is not covered (social security, state welfare, hollidays, extra time where you don't do productive work in an office but get paid, time spent on responding to email, or filling or preparing the MOU for NLnet etc)
a3. Send the MOU
a4. Sign it
a6. Finish a big task group, send a request for payment + bank details the first time and get paid, and redo that until everything is finished.

For the request for payment you need to point to resources that proves that the task is done. The reporting is done this way.

Example: git.replicant.us/GNUtoo/kernel_replicant_linux.git in this branch + build howto
Example2: post on the bugtracker of F-Droid with the agreed specification for the properties

Discuss with F-Droid to find a way to implement the FSDG compliance¶

• Specs for implementation:
  Tag format: "Antifeature: non-fsdg-compliant, <reason>"
• Definition:
  • Property that indicates that the package doesn't meet the FSDG guidelines as per <fsdg guidelines address>.
  • reason: textual description of why the package is not fsdg compliant. (see parabola blacklist for examples + git-url of paraobla blacklist repo + file)

Implementation¶

Person: Fil Bergamo

NLnet application¶

PortReplicantToAnewerAndroidVersionInitialApplication¶

NLnet foundation Grant application for "Finish porting Replicant to a newer Android version"¶

Contact information:¶

General project information¶

 Replicant is a fully free software Android distribution that needs to be
compliant with the FSF distribution guidelines (FSDG) that are available here:
https://www.gnu.org/distros/free-system-distribution-guidelines.html
F-Droid is not compliant and has applications like Yalp which is a package
manager that has repositories with nonfree software.
To make F-Droid compliant we would need to work with upstream to discuss how to add
new anti-feature tags to Fdroid metadata, in a way that enable to describe weather
a package is FSDG compliant while, as upstream requested, making it as generic
as possible to enable broader use of such tags.
Once that is done we will then need to discuss with upstream to define package
and/or anti-feature whitelist/blacklist to be implemented in the F-Droid client
in the most generic way possible.
The new anti-feature tags will then be implemented in the F-Droid client, as well
as the whitelist/blacklist, which will need to be selectable at build time, to
to be able to build an FSDG compliant F-Droid from the upstream source code.
We will then add that FSDG compliant F-Droid to the Fdroid metadata repository.
This way:
- The maintenance cost will be almost 0
- Users or other Android distributions will be able to use this FSDG version as well.
We will also need to share work with Debian, Replicant or other FSDG compliant
distributions to make sure that F-Droid can be built on them without any nonfree
dependency.

Requested support¶

Explain what the requested budget will be used for?

The budget will only be used to fund Fil Bergamo and Kurtis Hanna to work on this task.
Do you need a budget for other stuff? Like hardware or conference if Covid confinment ends, or whatever is necessary to work on that?

Replicant will also fund part of the tasks and/or complete the funding as we don't know how much time talking with F-Droid can take

We think it will take something between <3> and <6> months of work
for one full time developer. <- Very rough estimation, more precise one can be done in stage2

However it is always difficult to evaluate precisely the amount of time
that this kind of project would take as sometimes it can be slowed down
a lot due to <f-droid discussions>.

<Maybe E/month * months >

The Replicant project will also take care of ensuring that the
people that will work on this task have the necessary hardware 
<and help if necessary, but will probably not be necessary>.

The 2 people here are long time contributors to Replicant and
have a direct interest in making the project succeed.

We also have a very basic documentation on the Android 9 port here:
https://redmine.replicant.us/projects/replicant/wiki/FDroidFSDGCompliance

Compare your own project with existing or historical efforts.

The first attempt was done by Wolfgang Weidermeier, and patches were merged, then reverted.
The patches also addressed the problem very partially so, even if they were merged it wound't have been sufficent.

The next step was to discuss more to avoid issues like that, but that failed because people could only find the time to discuss it for short period of times. So after several attempts like that it failed.

This is why we made this proposal: it will give us the necessary time to focus on it.

Point point to the bugreport in Replicant, in F-Droid + the old bugreport and reverted patch.

What are significant technical challenges you expect to solve during the project, if any?

The most complicated challenges are not technical but human: we need to discuss with upstream to find the right solution.

Describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes?

Explain the first step with F-Droid data and that we will open a bugreport there, after having carefully read the FSDG compliance specification and checked with the FSF lawyers if something is unclear.

Other Replicant developers will most probably help a bit as there is a big interest in getting that issue fixed and that we already spent a big ammount of time discussing plans on how to fix it at various conferences like FOSDEM <2018?>

How may we handle your information¶