Aufnahmekriterien

Alle Anwendungen im Repository müssen Free, Libre and Open Source Software 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. Bei Zweifeln an einer Lizenz, nehmen Sie Bezug auf die GNU-Lizenzliste.

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 AntiFeatures), 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. unfreie Erweiterungen, automatische Aktualisierungen usw.).
  • The software should use its own unique Android package ID. Where the application is a fork of another (even one not included in the F-Droid repository) it must have a new ID, different from the original. Make sure to rename your fork accordingly (including all active translations).
  • 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 bezogen werden (siehe Handbuch).

Idealerweise:

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

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