Aufnahmekriterien

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 sollte keine zusätzlichen ausführbaren Binärdateien herunterladen (z. B. proprietäre Erweiterungen, automatische Aktualisierungen usw.).
  • 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 durch quelltexterstellte Versionen ersetzt oder aus vertrauenswürdigen Repositorys wie Maven Central OSSRH bezogen werden (siehe Handbuch).

Idealerweise:

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

Though we tried to build everyting from source, we still need some prebuild binaries. Therefore we have some exceptions:

  • 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/Hermers. They can be built from source which takes hours. Currently we downloaded them from npm and scanignore them.
  • 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.
  • Some other compilers/build tools not packaged in our very old Debian version.

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.