Replicant

Wiki

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.

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.

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

Define what to work on:1. Cleanup this draft2. 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 amounta2. 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 thata5. 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 MOUa4. Sign ita6. 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 howtoExample2: post on the bugtracker of F-Droid with the agreed specification for the properties

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.

Abstract: Can you explain the whole project and its expected outcome(s).in 1200 characters

Replicant is a fully free software Android distribution that has to be
compliant with the FSF distribution guidelines (FSDG)
( https://www.gnu.org/distros/free-system-distribution-guidelines.html )
F-Droid has non-compliant applications like Yalp.
To fix it we need discuss with upstream to add define new anti-feature tags
in FDroid metadata, that can describe if a package is FSDG compliant,
in the most generic way possible as requested by upstream.
Once that is done we will 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 tags and the whitelist/blacklist will be implemented in the F-Droid
client. The whitelist/blacklist will need to be configurable at build time,
to enable building a different FSDG F-Droid from the same source code.
F-Droid has already build time branding options.
We will then add that FSDG compliant F-Droid to the Fdroid metadata
repository.
This way we have near 0 maintenance and users of other distributions
could also use this FDroid.
We will also need to work with other projects to build FDroid on FSDG
distributions without any nonfree dependencies.

Have you been involved with projects or organizations relevant to this project before?And if so, can you tell us a bit about your contributions?

Fil Bergamo and Kurtis Hanna are involved in Replicant since a very long time. <add a rough date>Fil Bergamo* Developed RepWiFi.* Is part of the Replicant steering committee.Kurtis Hanna:* Is heavily involved in Replicant public relations, especially with other people working to upstream support for smartphones in Linux or u-boot for other Android or GNU/Linux distributions.* Is involved a lot in the Replicant documentation in the wiki.

The budget will only be used to fund Fil Bergamo and Kurtis Hanna to work on this task.
TODO: 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 complete the funding as we don't know how much time talking
with F-Droid can take, so it's hard to budget for it.
TODO: 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 it depends on how much time the discussions
with upstream will take and what exact implementation is chosen.
<Maybe E/month * months >
The 2 people here are long time contributors to Replicant and
have a direct interest in making the project succeed.
Over time we will document the progress and add more information here:
https://redmine.replicant.us/projects/replicant/wiki/FDroidFSDGCompliance

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 they
wound't have been sufficent to fix the issue.
In the next attempt, people from Replicant (including Fil Bergamo, Kurtis Hanna and
Denis Carikli) tried to discuss with upstream to avoid incomplete fixes, but that
failed because the people involved on Replicant side could only find the time to
discuss it for short period of times. So after several attempts like that we stopped
trying and planned to fund the task instead as it would give people involved enough
time to really fix it for good.
TODO: 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?>