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 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 and has applications like Yalp which is a package

manager that has repositories with 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

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

* part of the steering commitee

Kurtis Hanna:

* public relations (blog posts, etc) <= Important as you need to discuss with F-Droid

* documentation <= You know Replicant well |

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 |

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.

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

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

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