Alle Anwendungen im Repository müssen Free, Libre and Open Source Software (FLOSS) sein – zum Beispiel unter einer GPL- oder Apache-Lizenz veröffentlicht werden. Es werden alle Anstrengungen unternommen, um nachzuweisen, dass dies tatsächlich der Fall ist, sowohl durch Durchsicht der Quelle, als auch durch Herstellung der Anwendung aus der publizierten Quelle. Um festzustellen welche Lizenzen FLOSS sind, berufen wir uns auf weithin vertrauenswürdige Organisationen mit einer erwiesenen Erfolgsbilanz. Insbesondere erkennen wir diese Standards an: DFSG, FSF, GNU und OSI.

Damit Software FLOSS sein kann, muss die Software in ihrer Gesamtheit so sein - einschließlich aller verwendeten Bibliotheken und Abhängigkeiten. Zusätzlich muss sie allein mit FLOSS-Instrumenten herstellbar sein.

Zu beachten ist:

• Wir können keine Apps erstellen, die Googles proprietäre „Play Services“ nutzen. Sprechen Sie mit dem Upstream über eine unbedenkliche Build-Variante (entweder durch Verwendung von microG oder vollständige Entfernung unfreier Abhängigkeiten).
• Wir können keine Apps erstellen, die proprietäre Überwachungs-/Analyseinstrumente nutzen, wie Crashlytics und Firebase. Sprechen Sie mit dem Upstream über eine makellose Build-Variante (entweder durch Verwendung einer FLOSS-Analysesoftware, wie ACRA, oder durch vollständige Entfernung unfreier Abhängigkeiten).
• Wir können keine Apps erstellen, die proprietäre Werbebibliotheken nutzen. Wir haben nichts gegen Werbung (siehe Anti-Features), aber sie muss in einer dem FLOSS-Gedanken entsprechenden Weise bereitgestellt werden.
• Wir können keine Apps erstellen, die unfreie Build-Werkzeuge benötigen, einschließlich Oracle’s JDK oder irgendwelcher Toolchains für Vorabversionen.

Darüberhinaus:

• Der Quelltext für die Anwendung muss in einem öffentlich zugänglichen Versionsverwaltungssystem gepflegt werden, das von uns unterstützt wird (Git, Hg, SVN, Bazaar), und der Quelltext muss auf dem neusten Stand gehalten werden.
• Die Software darf keine zusätzlichen ausführbaren Binärdateien (z. B. Addons, automatische Aktualisierungen, usw.) ohne ausdrückliche Zustimmung des Nutzers herunterladen. Zustimmung bedeutet, dass es sich um eine Opt-in-Lösung handeln muss (es darf nicht schwieriger sein, sie abzulehnen, als sie zu akzeptieren oder sie muss so präsentiert werden, dass die Nutzer wahrscheinlich auf “Akzeptieren” drücken, ohne sie zu lesen) und sie muss so strukturiert sein, dass den Nutzern klar erklärt wird, dass sie sich dafür entscheiden, die Kontrollen von F-Droid zu umgehen, wenn sie sie aktivieren.
• Die Software sollte ihre eigene einzigartige Android-„Application ID“ besitzen, der auf einem vom Entwickler kontrollierten Domain-Namen basiert. Wenn die App zum Beispiel Teil einer Gruppe namens „foo“ auf gitlab.com ist, dann könnte die Domain io.gitlab.foo heißen. Sie sollte nicht auf jemandes Domain-Namen beruhen (z. B. com.google.foo). Maven Central OSSRH stellt eine gute Anleitung bereit.
• Wo die Anwendung ein Entwicklungszweig einer anderen ist (selbst einer, die nicht ins F-Droid-Repository aufgenommen ist), muss sie eine neue ID besitzen, die sich vom Original unterscheidet. Sorgen Sie dafür, dass Ihr Fork (einschließlich aller Übersetzungen) entsprechend umbenannt wird. Forks, die eine App lediglich mit einem neuen Namen versehen, ohne einen Mehrwert für den Anwender zu erbringen, werden unter Umständen nicht akzeptiert.
• Wenngleich nicht ideal, können “nichtfunktionale” Medieninhalte (z. B. künstlerische Darstellungen), die einer weniger freizügigen Lizenz unterliegen als der funktionale Code, akzeptabel sein - ein Beispiel wären Illustrationen, die nur zur Verwendung mit diesem bestimmten Spiel lizenziert sind. In jedem Fall müssen sie allerdings irgendeiner Form einer Lizenz unterliegen und dürfen keine Urheberrechte verletzen.
• Markenzeichen dürfen nicht verletzt werden und sämtliche juristische Vorgaben sind einzuhalten.
• F-Droid meldet sich nicht für irgendwelche API-Schlüssel an. Selbst wenn sie von Drittanbietern bereitgestellt sind, schließen wir sie sowohl in Binärcode- als auch in Quellcode-Versionen ein.
• Binärdatei-Abhängigkeiten wie beispielsweise JAR-Dateien müssen aus dem Quellcode hergestellt oder aus Debian-Repos installiert werden.

Idealerweise:

• Versionen sollten durch Schlagworte (oder auf andere Weise) eindeutig gekennzeichnet sein.

Obwohl wir versucht haben, alles aus dem Quellcode zu bauen, benötigen wir immer noch einige vorgebaute Binärdateien. Daher haben wir einige Ausnahmen:

• Vertrauenswürdige Maven-Repositorys. Solange nicht garantiert ist, dass deren Binärdateien frei sind und dem Quellcode entsprechen, erlaubt F-Droid aktuell die folgenden bekannten Repositorys:
  • Maven Central - das Original-Repo, festprogrammiert in Maven und Gradle.
  • Google Maven Repo - festprogrammiert in Gradle, dieses Repo hostet google-eigene Bibliotheken.
  • jCenter - festprogrammiert in Gradle, dieses Repo von Bintray ist bemüht, eine einfachere Bedienung anzubieten. Es wird mit Maven Central synchronisiert und enthält einige Extra-Bibliotheken. Es wird demnächst geschlossen, dieses Repo daher möglichst vermeiden.
  • OSS Sonatype - betrieben von den Leuten hinter mavenCentral, konzentriert sich dieses Repository auf Hosting-Dienste für Binärdateien von Open-Source-Projekten. Es synchronisiert sich mit Maven Central und enthält einige Extra-Bibliotheken.
  • OSS JFrog - betrieben von den Leuten hinter jCenter. Der Schwerpunkt dieses Repositorys liegt auf Hosting-Diensten für Binärdateien von Open-Source-Projekten.
  • JitPack.io - erstellt Builds direkt aus GitHub-Repositorys. Sie bieten allerdings keine Optionen, die Ausgabebinärdateien zu reproduzieren oder verifizieren. Erstellt in manchen Fällen Builds von Pre-release-Versionen.
  • Clojars - Clojure-Bibliotheken-Repo.
  • CommonsWare - Repo, das eine Sammlung von Open-Source-Bibliotheken bereithält.
  • Gradle Plugin Repo - festprogrammiert in Gradle, dieses Repo hostet Gradle-Plugins.
• Android SDK/NDK. Sie werden als proprietäre Binärdateien veröffentlicht, aber wir haben derzeit keine Alternative. Es wird daran gearbeitet, aktuelle Android-SDK-Versionen in Debian zu paketieren.
• Gradle. Nur einige alte Versionen von Gradle sind in Debian paketiert. Derzeit laden wir sie von der Entwickler-Website herunter.
• Flutter SDK. Es ist FOSS, aber nicht in Debian paketiert und wir sind nicht in der Lage, sie aus den Quellen zu bauen. Derzeit laden wir sie von der Entwickler-Website mit den Flutter-srclib-Skripten.
• JSC/Hermes. Sie können aus den Quellen gebaut werden, was Stunden dauert. Derzeit haben wir sie von npm heruntergeladen und scanignore’ieren sie.
• Binärdateien von pip wheels. Einige Anwendungen installieren Deps mit pip und wir vertrauen einfach dem nicht vertrauenswürdigen Pypi.
• Binärdateien aus dem Nix-Cache. Diese Binärdateien sind größtenteils reproduzierbar.
• Rust/Rustup. Derzeit laden wir sie von der Entwickler-Website mit den Skripten in der Rustup srclib herunter. Möglicherweise können wir die Debian-Pakete verwenden.
• Golang & Nodejs. Sie sind in Debian verfügbar, aber wir verwenden eine sehr alte Debian-Version, sodass aktuelle Versionen nicht verfügbar sind. Derzeit laden wir sie von der Entwickler-Website herunter.
• Einige andere Compiler/Build-Tools, die nicht in unserer sehr alten Debian-Version enthalten sind.

Manche Software, obwohl frei und quelloffen, kann sich Praktiken bedienen, die für einige oder alle Nutzer unerwünscht sind. Wenn möglich werden wir alle diese Anwendungen trotzdem ins Repository aufnehmen, aber sie werden mit dem entsprechenden Kennzeichen AntiFeatures ausgewiesen. Auch wenn solche Software eingeschlossen werden kann, wenn sie entsprechend markiert ist, ist es häufig so, dass andere „FLOSS“-Software mit diesen Merkmalen eigentlich nicht völlig frei ist. Zum Beispiel wird Werbung und Überwachung von Nutzern über proprietäre Binärdateibibliotheken ermöglicht, die wir nicht einschließen können.

Bei Einschluss von Spendeninformationen, müssen die entsprechenden Spendenverknüpfungen (z. B. Bitcoin, PayPal, Flattr usw.) auch hier abrufbar sein:

• In einer README- oder ähnlichen Datei im Projektquellcode.
• In einer FUNDING.yml-Datei, die im Projektquellcode enthalten ist.
• Auf der Homepage der Anwendung.
• Wenn die Software auf GitLab gehostet wird, ist es ausreichend, dass die, dem fdroiddata-Repository hinzugefügten, Informationen zur Person, die zu Spenden aufruft, zum selben Benutzerkonto gehören, über das der Quelltext der Anwendung verwaltet wird.

Dies soll verhindern, dass jemand willkürlich Spendenverknüpfungen von Anwendungen im F-Droid-Hauptrepository ohne Zustimmung des einspielenden Entwicklers böswillig ändert.

Zu weiteren Informationen über das Hinzufügen von Anwendungen zum F-Droid-Repository, siehe Aufnahmeverfahren.