F-Droid: Appstore für freie und quelloffene Apps

F-Droid ist ein Apps­tore für Handys mit Android-Betriebs­system, der in seiner Haupt-Paket­quelle ausschließ­lich freie und quellof­fene Soft­ware (FOSS: Free and Open Source Soft­ware bzw. FLOSS: Free/Libre and Open Source Soft­ware) anbietet, wobei die geprüften Android-Apps strenge Aufnah­mekri­terien erfüllen müssen. Das gemein­schaft­lich betrie­bene Projekt wird von vielen Mitwir­kenden entwi­ckelt und gepflegt.

F-Droid gibt die Anzahl der verfüg­baren Apps in ihrer Haupt-Paket­quelle mit 4495 an, weitere Paket­quellen, wie die microG F-Droid repo oder das Guar­dian Project Archive, können manuell hinzu­gefügt werden. Obwohl jede App FLOSS sein muss, können manche verfüg­baren Apps trotzdem uner­wünschte Merk­male aufweisen (dazu später mehr). Neben der Geschichte und einigen tech­nischen Details wird im Weiteren auch auf das Auswahl­ver­fahren und Dritt­anbieter-Paket­quellen, wofür F-Droid keine Verant­wor­tung über­nimmt, einge­gangen.

Die Geschichte von F-Droid

F-Droid-Logo
Bild: gitlab.com/fdroid Das F-Droid-Projekt wurde 2010 vom Briten Ciaran Gult­nieks gegründet. Der Quell­code der App ist ein Fork (also eine Abspal­tung) von Aptoide, einem quellof­fenen Markt­platz für Android-Apps. Ursprüng­lich wurde das Projekt von der Non-Profit-Orga­nisa­tion F-Droid limited betrieben, die aber 2021 ihre Geschäfts­tätig­keit einstellte. Seit 2012 betreibt das 2009 gegrün­dete Guar­dian Project, das unter anderem mehrere Apps mit mehreren Millionen Down­loads entwi­ckelt hat, eine eigene F-Droid Paket­quelle. Bekannte Apps des Guar­dian Projects sind Orbot, Orfox (einge­stellt) und Tor Browser for Android.

Nur ein Jahr Später, 2013, sorgte das Entfernen des popu­lären Werbe­blo­ckers AdAway aus dem Google Play Store für einen raschen Anstieg von Suchen nach und Instal­lationen von F-Droid. Die F-Droid-App selbst ist übri­gens eben­falls nicht in Googles Apps­tore verfügbar, da sie Googles Konkur­rent und der Play Store proprietär ist. Als vorin­stal­lierter Stan­dard-Apps­tore ist F-Droid unter anderem im Betriebs­system CalyxOS zu finden.

Vor- und Nach­teile von F-Droid

Die Paket­quellen von F-Droid enthalten mehrere Tausend Apps, wohin­gegen Google Play mehr als drei Millionen Apps anbietet. Während man also bei Google Play fast garan­tiert immer eine App zum gewünschten Thema findet, kann sich das bei F-Droid schwie­riger gestalten. Was Kate­gorien angeht, so sind vor allem Banken- oder Messenger-Apps auf F-Droid kaum oder gar nicht verfügbar. Eine Suche nach den belieb­testen Messen­gern - WhatsApp, Threema, Signal, Tele­gram und Viber - brachte nur bei Tele­gram ein posi­tives Ergebnis mit dem Hinweis, dass es sich um einen reinen FLOSS-Fork handelt. Weitere beliebte Apps, die bei F-Droid nicht gefunden werden können, sind beispiels­weise Insta­gram, Snap­chat, ICQ, TikTok und Face­book. Was WhatsApp und Face­book angeht werden zwar einige Ergeb­nisse ange­zeigt, dabei handelt es sich aber nicht um eine FLOSS-Version der jewei­ligen Original-App, wie sie z. B. im Play Store verfügbar ist.

Auf der anderen Seite bietet F-Droid einige FLOSS-Apps, die es so nicht im Play Store gibt und für die sich eine Instal­lation von F-Droid lohnt. Unter anderem sind das neben AdAway und F-Droid selbst die Apps­tores Aurora Store, Aurora Droid, Aptoide und Yalp Store (einge­stellt) sowie NewPipe, WebTube (beides YouTube-Front­ends) und SimpleRT (Reverse Tethe­ring). Dazu kommen vor allem Diagnose- und System-Werk­zeuge wie Magisk (root) und microG-Bestand­teile. Die große Verbrei­tung von Android bzw. dem Google Play Store sorgt dafür, dass viele Apps nicht nur in F-Droid, sondern in beiden Apps­tores vorhanden sind. Ist dies für die gewünschte App der Fall, kann der Nutzer dementspre­chend entscheiden, ob er lieber auf eine FLOSS-Version zurück­greift oder die Original Play-Store-Version wählt. Neben Apps, die tatsäch­lich ausschließ­lich bei F-Droid zu finden sind, ist eine FLOSS-Alter­native für Play-Store-Apps durchaus zu begrüßen.

Freie und quellof­fene Soft­ware

Free Software Foundation Logo
Bild: gnu.org
Sowohl die App F-Droid selbst als auch die in der F-Droid-Haupt­paket­quelle verfüg­baren Apps sind alle FOSS bzw. FLOSS wobei es zwischen diesen beiden feine Unter­schiede gibt. Daher ist hier eine möglichst eindeu­tige Defi­nition vonnöten.

Das "F" in beiden Akro­nymen steht für Free/Frei. Eine Soft­ware kann dann als frei bezeichnet werden, wenn dem Benutzer die vier Frei­heiten gewährt werden. Diese Defi­nition und die vier Frei­heiten wurden von Richard Stallman, Gründer der Free Soft­ware Founda­tion (FSF) und des GNU-Projekts, formu­liert und von der FSF veröf­fent­licht. Für die Frei­heiten 1 und 3 ist ein veröf­fent­lichter Quell­code erfor­der­lich.

• Frei­heit 0: Die Frei­heit, das Programm so auszu­führen wie der Nutzer es möchte, und zwar egal für welchen Zweck.
• Frei­heit 1: Die Frei­heit zu analy­sieren, wie das Programm funk­tio­niert und es so zu verän­dern, dass es nach den Wünschen des Benut­zers Daten verar­beitet.
• Frei­heit 2: Die Frei­heit, Kopien dieses Programms weiter­zuver­teilen und somit anderen zu helfen.
• Frei­heit 3: Die Frei­heit, Kopien des selbst modi­fizierten Programms weiter­zuver­teilen.

Als 1986 die ersten Frei­heiten formu­liert wurden, gab es nur zwei: Die Frei­heit, Kopien des Programms weiter­zuver­teilen und die Frei­heit, das Programm zu verän­dern, damit es nach den Wünschen des Benut­zers funk­tio­niert (ähnlich den o. g. Frei­heiten 1 und 2). Um 1990 wurde auf der GNU-Home­page eine weitere Frei­heit hinzu­gefügt: die Frei­heit, das Programm zu analy­sieren. Da zum Ändern des Programms (eine bereits erwähnte Frei­heit) eine vorhe­rige Analyse Voraus­set­zung ist, unter­streicht die jetzt expli­zite Erwäh­nung der Analyse ihre Wich­tig­keit. Nach Hinzu­fügen von Frei­heit 3 wurde schließ­lich eine vorerst letzte Frei­heit formu­liert (Frei­heit 0), wodurch die Form von 1996 erreicht wurde. Eben­falls explizit erwähnt werden sollte also auch die Frei­heit zum Ausführen des Programms an erster Stelle, da dies klar grund­legender als die anderen Frei­heiten ist. So wurde diese Frei­heit noch vor die 1. Frei­heit auf Platz 0 gestellt.

Open Source Initiative Logo
Bild: opensource.org Das "L" in FLOSS wiederum steht für "Libre" (franz./span., auf Deutsch: frei), hat also ausschließ­lich die Bedeu­tung von frei im Sinn von Frei­heit und nicht auch gleich­zeitig für gratis/kostenlos, wodurch dieses Wort genauer bzw. eindeu­tiger ist. Freie Soft­ware muss also nicht zwangs­läufig kostenlos sein, und im Umkehr­schluss ist natür­lich nicht jede kosten­lose Soft­ware auch "frei", was die zusätz­liche Benut­zung von "/Libre" verdeut­lichen soll. Die Kontro­verse, ob nun FOSS oder FLOSS korrekter oder genauer ist, zu der sich auch Stallman äußerte, dauert bis heute an. F-Droid entschied sich für die Verwen­dung von FLOSS.

Zu guter Letzt bedeutet das "OSS" in beiden Akro­nymen Open Source Soft­ware, also quellof­fene Soft­ware. Kurz gesagt bedeutet quelloffen, dass der Quell­text einer Soft­ware veröf­fent­licht wurde und von jedem einge­sehen, geän­dert und genutzt werden kann. Eine genaue Defi­nition, die heute in der Gemein­schaft allge­mein aner­kannt ist, veröf­fent­lichte die Open Source Initia­tive (OSI), in Person von Bruce Perens, mit ihrer The Open Source Defi­nition, die ihrer­seits von den Debian Free Soft­ware Guide­lines (DFSG) abge­leitet wurde.

Uner­wünschte Merk­male

Apps mit unerwünschten Merkmalen
Screenshot: teltarif.de Soft­ware, die zwar FLOSS ist, sich aber Prak­tiken bedient, die von einigen, den meisten oder sogar allen Nutzern uner­wünscht sind, wird trotzdem - soweit reali­sierbar - in die Paket­quelle aufge­nommen. Aller­dings ist diese dann eindeutig mit "Uner­wünschte Merk­male" ("Anti-Features") gekenn­zeichnet. Diese sind: Werbung, Über­wachung, proprie­täre Netz­werk­dienste, proprie­täre Erwei­terungen, proprie­täre Abhän­gig­keiten, "NSFW" (not safe for work), kein freier Quell­code, proprie­täre Güter, bekannte Schwach­stellen, untaug­licher Algo­rithmus und Quell­texte, die nicht mehr verfügbar sind.

Werbung hingegen ist nicht per se verboten. Jedoch sind die meisten Apps, die Werbung enthalten, keine freie Soft­ware, weil sie für die Werbung proprie­täre Soft­ware (wie z. B. AdMob) enthalten. Dementspre­chend werden diese nicht aufge­nommen. Apps, die Werbung ohne proprie­täre Soft­ware enthalten, sind dagegen erlaubt. In der Doku­men­tation von F-Droid sind weitere Details zu uner­wünschten Merk­malen beschrieben.

Aufnah­mekri­terien für Apps

Immer wenn es um Soft­ware geht, sind auch Lizenzen zu beachten, denn sie spielen eine entschei­dende Rolle. Eine Soft­ware­lizenz ist ein Doku­ment, das verbind­liche Richt­linien für die Nutzung und Verbrei­tung von Soft­ware enthält. Bei FOSS bzw. FLOSS werden Nutzungs­rechte pauschal jedem Nutzer einge­räumt. Bei der Auswahl von akzep­tierten Lizenzen beruft sich F-Droid auf vertrau­ens­wür­dige Orga­nisa­tionen und Stan­dards wie insbe­son­dere die DFSG, die FSF, das GNU-Projekt und die OSI. Beson­ders wich­tige und häufig genutzte Lizenzen sind die GNU General Public License (GNU GPL), vor allem in der 2007 veröf­fent­lichten und empfoh­lenen Version 3 (GNU GPLv3), und die Apache-2.0-Lizenz. Zu beachten ist hierbei, dass für verschie­dene nicht funk­tio­nale Bestand­teile der App - z. B. künst­leri­sche Darstel­lungen - auch weniger frei­zügige Lizenzen akzep­tabel sind, solange sie in irgend­einer Form einer Lizenz unter­liegen und keine Urhe­ber­rechte verletzen.

Ebenso muss eine Soft­ware, um FLOSS zu sein, in ihrer Gesamt­heit FLOSS sein, also einschließ­lich aller Abhän­gig­keiten und Biblio­theken, sowie allein mit FLOSS-Instru­menten herstellbar sein. Darüber hinaus kann F-Droid keine Apps erstellen, die Googles proprie­täre "Play Services" nutzen, die proprie­täre Über­wachungs- bzw. Analy­seinstru­mente nutzen wie Crash­lytics oder Fire­base, die proprie­täre Werbe­biblio­theken nutzen oder die unfreie Build-Werk­zeuge benutzen wie Oracles JDK oder Ähnli­ches. Schließ­lich gibt es noch eine Reihe weiterer tech­nischer Krite­rien, die hier nur kurz zusam­men­fas­send skiz­ziert werden können, da sie sehr detail­liert beschrieben werden. Dazu gehört eine adäquate Veröf­fent­lichung und Pflege des Quell­texts, die Sicher­heit, dass keine zusätz­lichen ausführ­baren Binär­dateien herun­ter­geladen werden, eine eigene einzig­artige Android-„Appli­cation ID“ der entspre­chenden App und eine eigene ID von Forks dieser App, keine Verlet­zung von Marken­zei­chen, Einhal­tung sämt­licher juris­tischer Vorgaben und das Ersetzen von Binär­datei-Abhän­gig­keiten (wie z. B. JAR-Dateien) durch quell­tex­terstellte Versionen, falls sie nicht aus vertrau­ens­wür­digen Repo­sitorys bezogen werden. Idea­ler­weise sollten die Apps durch Schlag­worte oder andere Methoden eindeutig gekenn­zeichnet werden. Eine detail­lierte Auflis­tung samt genauen Erklä­rungen ist hier zu finden. So sieht F-Droid aus
Bild: f-droid.org

Aufnah­mever­fahren für Apps

Wie im vorigen Abschnitt beschrieben, gibt es strenge Aufnah­mekri­terien. Nun soll näher beschrieben werden, wie neue Apps in die Haupt­paket­quelle aufge­nommen werden, um eine Vorstel­lung von der Arbeits­weise von F-Droid zu erlangen. Am Anfang steht zunächst der Vorschlag, eine neue App aufzu­nehmen. Jeder kann neue Apps vorschlagen, nicht nur Entwickler oder Main­tainer. Es gibt zwei Methoden für einen Vorschlag: Entweder werden alle notwen­digen Infor­mationen über die App an die "Submis­sion Queue" gesendet oder es kann die gesamte Meta­daten-Datei selbst geschrieben, getestet und direkt im fdro­iddata Git-Repo­sitory vorge­schlagen werden. Letz­tere Methode (Merge-Anfrage) ist nur für Fort­geschrit­tene geeignet.

Bei der Submis­sion-Queue-Methode wird ein Ticket erstellt, wie man es von einigen anderen Berei­chen ebenso kennt, woraufhin dann eine Maske erscheint, in die alle notwen­digen Details und Mini­mal­bedin­gungen einge­tragen werden. Anschlie­ßend prüft das Team von F-Droid einge­hend die App und unter­nimmt alle weiteren Schritte, bis die App dann schließ­lich verfügbar ist. Diese Methode ist wegen der inten­siven Prüfung die lang­samere, aller­dings auch die einfa­chere.

Bei der zweiten Methode wird eine Git-Merge-Anfrage in der Meta­daten-Paket­quelle der F-Droid-Anwen­dung (fdro­iddata GitLab-Repo­sitory) ausge­füllt, wodurch eine viel schnel­lere Aufnahme der App möglich ist: Die Meta­daten-Datei ist bereits vorhanden, sodass die Arbeits­belas­tung der Prüfer bei Durch­sicht der Meta­daten erheb­lich redu­ziert wird. Die Einrei­chung einer korrekten Meta­daten-Datei wird voraus­gesetzt. Weiterhin sollte der Benutzer über einige spezi­elle Kennt­nisse verfügen und der FLOSS-Bewe­gung gegen­über aufge­schlossen sein.

Alles in allem scheint das Projekt einiges zu bieten. Zu sämt­lichen hier erwähnten Themen stehen auf der Website genü­gend weiter­rei­chende und -führende Infor­mationen in der umfang­rei­chen Doku­men­tation zur Verfü­gung. Inter­essierte werden hier also unter Garantie fündig.