Filarr veröffentlicht seinen Quellcode – warum BSL 1.1

Kurze Antwort. Der Desktop-Client von Filarr ist unter der Business Source License 1.1 (BSL 1.1) veröffentlicht, unter github.com/matbel91765/filarr. Sie können den Code lesen, ihn selbst bauen und die kryptografischen Versprechen des Clients prüfen. Das Cloud-Backend bleibt proprietär. Der genaue Begriff lautet „source available“: Open Source im Sinne der OSI wird der Code erst am 19. April 2030, wenn er automatisch zu Apache 2.0 wechselt – das Datum steht fest in der Lizenz.

Heute wird der Quellcode des Desktop-Clients von Filarr öffentlich.

Der Code ist unter github.com/matbel91765/filarr unter der Business Source License 1.1 veröffentlicht. Sie können ihn lesen, klonen, bauen und Korrekturen vorschlagen. Dieser Beitrag erklärt, was veröffentlicht ist, was geschlossen bleibt, warum ich die BSL gewählt habe und was sich dadurch konkret für Sie ändert.

Warum den Code von Filarr jetzt veröffentlichen?

Vom ersten Tag an verkauft Filarr ein präzises Versprechen: Ihre Daten liegen verschlüsselt auf Ihrer Festplatte, und meine Server können sie nicht lesen. Das lässt sich im Code überprüfen. Es ist eine konkrete kryptografische Aussage.

Solange der Code privat war, beruhte dieses Versprechen auf meinem Wort. Sie konnten mir vertrauen oder nicht. Das war eine Vertrauensschuld, die ich nicht stehen lassen wollte.

Den Code zu veröffentlichen, bewirkt zwei Dinge:

1. Sie müssen mir nicht mehr aufs Wort glauben. Sie können die kryptografischen Module und den Algorithmus der Schlüsselableitung lesen – und selbst sehen.
2. Sicherheitsforscher, Neugierige und Mitwirkende können melden, was kaputt ist. Mehr Augen auf dem Code = weniger Fehler, die durchrutschen.

Was steckt im Repository von Filarr (und was nicht)?

Das Repository enthält den Local-First-Kern des Produkts. Genau das, was Sie nutzen, wenn Sie nicht bei einem Konto angemeldet sind:

• Den Desktop-Client auf Basis von Electron/React
• Die kryptografischen Module (AES-256-GCM, KEK/FEK-Architektur, PBKDF2-Ableitung mit 600.000 Iterationen)
• Den Block-Editor auf Basis von TipTap (Aufgaben, Tabellen, Wiki-Links, Transklusion)
• Die Graphansicht (Physiksimulation, Erkennung von Gemeinschaften)
• Das eingebaute 2D-Canvas
• Das System mehrerer Profile mit vollständiger Schlüsseltrennung
• Die verschlüsselte Speicherung auf der Festplatte
• Die Dateivorschau für mehr als 80 Formate

Was nicht im Repository steckt:

• Das Backend api.filarr.com (Authentifizierung, Sitzungen, Kontoverwaltung, Abrechnung)
• Die Logik der Cloud-Synchronisation zwischen Geräten
• Die Infrastruktur auf Cloudflare R2 und die zugehörigen Worker
• Die Verwaltung von Abos und Zahlungen

Das offizielle Binärprogramm auf filarr.com verbindet beides. Ohne Konto verhält es sich genau wie das öffentliche Repository. Mit Konto werden die proprietären Cloud-Module aktiv. Das ist das „Open Core“-Modell in seiner Source-available-Form: Der Kern des Produkts ist öffentlich, die gehosteten Dienste sind das Geschäftsmodell.

Warum BSL 1.1 und nicht MIT, Apache oder AGPL?

Die Wahl der Lizenz zählt. Sie spiegelt wider, was man schützen und was man öffnen will. Drei Optionen standen zur Wahl.

Sofort MIT oder Apache 2.0

Vorteil: die freizügigste Lizenz, die verbreitetste, die einfachste.

Problem: Sie erlaubt einem Konkurrenten, Filarr zu forken, umzubenennen und morgen dasselbe Produkt zu verkaufen. Ich bin Einzelentwickler. Ein paar Monate Arbeit, an einem Nachmittag kopiert, wären das Ende des Projekts. Eine Lizenz, die das Produkt tötet, das sie befreit, hilft niemandem.

AGPL

Vorteil: starkes Copyleft, zwingt dazu, Änderungen offen zu halten.

Problem: Die AGPL ist ein Netzwerk-Copyleft. Wenn Sie den Code in einem Dienst verwenden, müssen Sie Ihren gesamten Stack offenlegen. Das bremst Verbreitung und Beiträge, besonders in Unternehmen, deren Rechtsabteilung die AGPL oft rundweg ablehnt. Und sie schützt nicht wirklich vor Konkurrenz: Ein Konkurrent kann seine Änderungen zurückgeben und dann denselben Dienst verkaufen.

BSL 1.1

Die BSL wurde genau für dieses Szenario entworfen: den Code für Prüfung und Beiträge öffnen, aber vorübergehend kommerzielle Nutzungen verbieten, die das Projekt töten würden.

Das besagt sie konkret:

• Sie dürfen: lesen, klonen, ändern, bauen und für persönliche, Bildungs-, Forschungs-, Evaluierungs- oder Entwicklungszwecke nutzen.
• Sie dürfen nicht: ihn in Ihrem Unternehmen produktiv einsetzen, einen auf diesem Code basierenden Dienst verkaufen oder ein konkurrierendes kommerzielles Angebot hosten. Dafür braucht es eine separate kommerzielle Lizenz (schreiben Sie an contact@filarr.com).
• Change Date: 19. April 2030. Dieses Datum steht fest in der Lizenz. Ab dann wird der Code automatisch zur Apache License 2.0 – vollständig Open Source, ohne Einschränkungen.

Dieses Modell verwenden Sentry, CockroachDB, MariaDB MaxScale und Couchbase. Projekte, die gezeigt haben, dass es funktioniert: sofortige Transparenz, kommerzieller Schutz für einige Jahre, am Ende echte freie Software.

2030 wird der heutige Code Apache 2.0 sein. Jedes zwischenzeitliche Release hat sein eigenes Change Date. Das ist die öffentliche Garantie: Dieser Code wird am Ende vollständig Open Source, ein Zurück ist nicht möglich.

Was ändert die Veröffentlichung des Codes für Nutzer von Filarr?

Wenn Sie Filarr heute nutzen, ändert sich nichts an Ihrer Nutzung:

• Das Binärprogramm auf filarr.com ist identisch
• Die Tarife Free, Solo und Pro bleiben gleich
• Ihre verschlüsselten Dateien auf Ihrer Festplatte liegen genau dort, wo sie waren

Was sich ändert, ist, was Sie zusätzlich tun können:

• Den Code lesen, der auf Ihrem Rechner läuft. electron/storageService.ts ist der Einstiegspunkt, wenn Sie eine bestimmte kryptografische Aussage prüfen wollen.
• Sicherheitsprobleme melden, per verantwortungsvoller Offenlegung an security@filarr.com.
• Das Binärprogramm selbst bauen, wenn Sie dem, das ich signiere und verteile, lieber nicht vertrauen.
• Beitragen – Fehler, Funktionen, Übersetzungen, Dokumentation. Die Datei CONTRIBUTING.md erklärt, wie.

Wie lesen Sie den Quellcode von Filarr?

Das Repository ist groß. Wenn Sie direkt zu den wichtigen Teilen wollen:

• Um die Verschlüsselung zu prüfen: Beginnen Sie mit electron/storageService.ts (Schlüsselableitung, Verpacken und Speichern – die KEK/FEK-Architektur).
• Die Kette des Cloud-Uploads (electron/sync/) ist nicht im öffentlichen Repository: Wie das Backend gehört sie zu den Cloud-Modulen.
• Für die React-Oberfläche: src/renderer/ enthält die gesamte Benutzeroberfläche.

Eine README.md im Stammverzeichnis enthält die Build-Anleitung (Node, npm, electron-builder), und eine SECURITY.md dokumentiert das Bedrohungsmodell.

Wie melde ich ein Sicherheitsproblem in Filarr?

Der ganze Sinn der Öffnung des Codes ist, ihn prüfbar zu machen. Wenn Sie eine Schwachstelle entdecken – gebrochene Kryptografie, Schlüsselleck, Rechteausweitung –, melden Sie sie bitte per verantwortungsvoller Offenlegung statt in einem öffentlichen Issue.

Sicherheitskontakt: security@filarr.com. Antwort innerhalb von 48 Stunden an Werktagen. Ich nenne öffentlich jeden, der eine echte Schwachstelle meldet und die Sperrfrist der Offenlegung einhält.

Wie geht es mit dem öffentlichen Code von Filarr weiter?

Für die nächsten Monate plane ich:

1. Ein unabhängiges Sicherheitsaudit durch ein externes Team, mit veröffentlichtem Bericht
2. Eine ausführliche CHANGELOG.md im Repository, abgestimmt auf die auf filarr.com verteilten Versionen
3. Eine Seite zur Build-Pipeline, damit Sie prüfen können, dass das verteilte Binärprogramm einem getaggten Commit im Repository entspricht
4. Die schrittweise Öffnung der Logik der Cloud-Synchronisation, wenn das sinnvoll ist, ohne das Geschäftsmodell zu gefährden

Wenn Sie es einfach ausprobieren wollen: Filarr herunterladen. Wenn Sie zuerst lesen wollen: Das Repository ist öffentlich. Wenn Sie Fragen haben: contact@filarr.com.

Danke an alle, die Filarr genutzt haben, als es noch geschlossen war. Ihre Geduld hat geholfen, das Produkt so weit zu stabilisieren, dass die Öffnung des Codes wirklich sinnvoll war. Jetzt können Sie ihn lesen.