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 and as such it needs to be compliant with the FSF Free system distribution guidelines (FSDG) that are available here: https://www.gnu.org/distros/free-system-distribution-guidelines.html
F-Droid is not compliant with the guidelines as there are applications like Yalp which are package manager that has repositories that have nonfree software.
To make it compliant we would need to work with both F-Droid metadata and F-Droid upstreams: We need to discuss with upstream add new anti-feature metadata to packages, in order to be able to describe weather a package is compliant with the free system distribution guidelines. As the F-Droid Metadata project wants the tags to be as generic as possible and that we want to be compliant with the FSDG guidelines, we will have to work together to find the best way to meet both requirements. Once that is done we will then need to discuss with the F-Droid client upstream to define how to add a whitelist and blacklist system for packages and/or anti-features in the F-Droid client. Like before, this system will need to be as generic as possible, and it shouldn't create any issue for FSDG compliance. The whitelist/blacklist will need to be selected at build time. This way we would be able to build an F-Droid with the filters enabled at compilation time from the same source code than the Regular F-Droid. In order to be completely upstream with a near 0 maintenance cost, we would then add our special F-Droid build to F-Droid metadata, so it would be automatically be built by upstream. This will not only enable Replicant to include an F-Droid verion that is automatically maintained, but it would also enable other Android distributions to ship it, and users to install it. It would even be possible to have both, F-Droid and the fork installed at the same time. 
As we will need to build F-Droid on FSDG compliant distributions we will also need to make sure that it's possible, and probably work with other attempts to do that on Debian if possible.
https://gitlab.com/fdroid/fdroidserver/-/issues/383

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¶