Replicant

h1. FDroidCompliance

h2. 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

h2. Plan

TODO:

1. Cleanup this draft

2. Fill the missing information that can easily be found

In parallel:

a1. Precise how the people want to be paid (per tasks, hours, per months, etc) and the amount

a2. Find out how to do it legally (employment, contract work, grant, etc)

a3. Steering commitee vote on that

a4. Find a way to legally formalize it through the FSF if needed

In parallel:

a1. Write a very rough proposal and send it, don't wait too much as we might get a shot sooner

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 and get paid, and redo that until everything is finished.

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

|_. Task |_. Budget |_. Comments |_. Deliverable |

| Define with F-Droid upstream which properties we can use in package definition to comply with the FSDG guidelines | Hard to predict as it depends on the outcome of the discussion with F-Droid => Replicant funding | | Specifications that are ready to be implemented by Fil bergamo |

| Discuss how to implement build time whitelists and blacklists | Hard to predict as it depends on the outcome of the discussion with F-Droid => Replicant funding | | Precise specifications that are ready to be implemented by Fil bergamo |

| Some light coding tasks (I don't remember which one) | Nlnet? Replicant? Can time be predicted? | | |

Precise specifications: specifications that are clear enough to be implemented without making mistakes, and clear enough to understand for people using it.

Example: non-fsdg compliant property in the package definition.

* 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)

h3. Implementation 

*Person*: Fil Bergamo

|_. Task |_. Budget |_. Comments |_. Deliverable |

| Implement the parsing of the properties | Hard to predict as it depends on the outcome of the discussion with F-Droid => Replicant funding | | |

| Build F-Droid from an FSDG compliant distribution | Hard to predict => Replicant funding | Replicant 6 can't be built with FSDG compliant distros but Replicant 4.2, 9.0 and probably 10.0 too can => We need F-Droid to be built from an FSDG compliant distributions | Building F-Droid from an FSDG compliant distribution + a quick HOWTO |

| Implement build time whitelists / blacklists | Nlnet? Rough number of hours | | Can build F-Droid with custom blacklist and whitelists + quick HOWTO |

| Replicant F-Droid fork package in F-Droid | Nlnet? Rough number of hours | | Package can be built with F-Droid tools, ideally upstream it |