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

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 

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 |

h2. NLnet application

h1. PortReplicantToAnewerAndroidVersionInitialApplication

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

h3. Contact information:

|_. Your name | Fil Bergamo and Kurtis Hanna |

|_. Email address | contact address at the replicant.us domain |

|_. Phone numbers | The phone number of Fil Bergamo which is in European union |

|_. Organisation | Replicant |

|_. Country | Italy(Fil Bergamo), USA (Kurtis Hanna) |

h3. General project information

|_. Project name | Make F-Droid FSDG compliant |

|_. Website / wiki | https://redmine.replicant.us/projects/replicant/wiki/MakeFdroidFSDGCompliant |

|_. Abstract: Can you explain the whole project and its expected outcome(s).in 1200 characters | <pre>

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.

</pre> |

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

h3. Requested support

|_. Requested Amount (Between 5000 and 50000 Euros) | Something rough works too, I've added 50000 by mistake and it was re-defined later |

|_. Does the project have other funding sources, both past and present? | The Replicant project has about 200000 dollars at disposition:

* The Replicant project has a donation page https://crm.fsf.org/civicrm/contribute/transact?reset=1&id=19. Part of the donations were used for buying devices and reimburse conference attendances. We have about 20000 dollars remaining from the donation.

* The Replicant project recently received 200000 dollars from Handshake: https://www.fsf.org/news/free-software-foundation-receives-1-million-from-handshake As the FSF takes 10% that leaves us 180000 dollars

* Denis Carikli is being funded by NLnet to port Replicant to Android 9

* David "dllud" Ludovino and Ricardo "Grim" Cabrita are being funded by NLnet to work on the Replicant 9 graphic stack

Explain what the requested budget will be used for? 

<pre>

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

</pre>

Compare your own project with existing or historical efforts.

<pre>

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.

</pre>

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

<pre>

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

</pre>

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

<pre>

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?>

</pre>

|_. Attachments | None |

h3. How may we handle your information

|_. What should we do in the other case,

 e.g. when your project is not immediately selected? | Feel free to choose whatever you want here |

|_. Send me a copy of this application. | check-box checked |

|_. PGP pubkey | None (if we use Replicant contact address, we can't encrypt to it) |