Filarr passe en open source — pourquoi BSL 1.1

Réponse rapide. Le client desktop de Filarr est publié sous Business Source License 1.1 (BSL 1.1), sur github.com/matbel91765/filarr. Vous pouvez lire le code, le construire vous-même et vérifier les claims cryptographiques du client. Le backend cloud reste propriétaire. Le terme exact est « source available » : le code ne devient open source au sens de l'OSI que le 19 avril 2030, quand il passe automatiquement en Apache 2.0 — la date est fixée dans la licence.

Aujourd'hui, le code source du client desktop de Filarr devient public.

Le code est publié sur github.com/matbel91765/filarr sous Business Source License 1.1. Vous pouvez le lire, le cloner, le build, et proposer des correctifs. Cet article explique ce qui est publié, ce qui reste fermé, pourquoi j'ai choisi la BSL, et ce que ça change concrètement pour vous.

Pourquoi ouvrir le code de Filarr maintenant ?

Depuis le début, Filarr vend une promesse précise : vos données vivent chiffrées sur votre disque, et mes serveurs ne peuvent pas les lire. C'est vérifiable dans le code. C'est une proposition crypto précise.

Tant que le code était privé, cette promesse reposait sur ma parole. Vous pouviez me faire confiance ou pas. C'est une dette de confiance que je ne voulais pas laisser durer.

Publier le code fait deux choses :

1. Vous n'avez plus besoin de me faire confiance sur parole. Vous pouvez lire les modules cryptographiques et l'algorithme de dérivation de clé — et constater par vous-même.
2. Les chercheurs en sécurité, les curieux, les contributeurs peuvent signaler ce qui cloche. Plus d'yeux sur le code = moins de bugs qui passent.

Que contient le repo Filarr (et que ne contient-il pas) ?

Le repo contient le cœur local-first du produit. Exactement ce que vous utilisez quand vous n'êtes pas connecté à un compte :

• Le client desktop Electron/React
• Les modules cryptographiques (AES-256-GCM, architecture KEK/FEK, dérivation PBKDF2 avec 600 000 itérations)
• L'éditeur bloc TipTap (tâches, tableaux, wiki-links, transclusion)
• Le graph view (simulation physique, détection de communautés)
• Le canvas 2D intégré
• Le système multi-profil avec isolation complète des clés
• Le storage chiffré sur disque
• La prévisualisation 80+ formats

Ce qui n'est pas dans le repo :

• Le backend api.filarr.com (auth, sessions, gestion des comptes, billing)
• La logique de synchronisation cloud multi-appareils
• L'infrastructure Cloudflare R2 et les workers associés
• La gestion des abonnements et des paiements

Le binaire officiel sur filarr.com intègre les deux. Sans compte, il se comporte exactement comme le repo public. Avec un compte, les modules cloud propriétaires s'activent. C'est le modèle "open core", dans sa version source available : le cœur du produit est public, les services hébergés sont le modèle économique.

Pourquoi BSL 1.1 et pas MIT, Apache ou AGPL ?

Le choix de licence n'est pas anodin. Il reflète ce qu'on veut protéger et ce qu'on veut rendre. Trois options étaient sur la table.

MIT ou Apache 2.0 immédiate

Avantage : la licence la plus permissive, la plus adoptée, la plus simple.

Problème : elle permet à un concurrent de forker Filarr, de le rebrander, et de vendre le même produit demain. Je suis solo dev. Quelques mois de travail copiés en une après-midi, ce serait la fin du projet. Une licence qui tue le produit qu'elle libère n'aide personne.

AGPL

Avantage : copyleft fort, force les modifications à rester open.

Problème : l'AGPL est copyleft réseau. Si vous utilisez le code dans un service, vous devez libérer votre stack entière. C'est un frein à l'adoption et aux contributions, surtout en entreprise où la juridique refuse souvent l'AGPL. Et ça ne protège pas vraiment contre la concurrence : un concurrent peut contribuer ses modifs en retour puis vendre le même service.

BSL 1.1

La BSL a été conçue exactement pour ce scénario : libérer le code pour audit et contribution, mais interdire temporairement les usages commerciaux qui tueraient le projet.

Voici ce qu'elle dit concrètement :

• Vous pouvez : lire, cloner, modifier, build, utiliser en perso, en éducatif, en recherche, en évaluation, en dev.
• Vous ne pouvez pas : déployer en production pour votre entreprise, vendre un service basé sur ce code, héberger une offre commerciale concurrente. Ça, c'est une licence commerciale séparée (écrivez à contact@filarr.com).
• Change Date : 19 avril 2030. Cette date est fixée dans la licence. À partir de là, le code devient automatiquement Apache License 2.0 — donc totalement open source, sans restriction.

MariaDB a créé ce modèle pour MaxScale, et Couchbase l'utilise. Sentry l'a utilisé de 2019 à 2023, avant de passer à sa propre Functional Source License ; CockroachDB l'a utilisé de 2019 à 2024, avant de passer à une licence entreprise unique. Leur parcours montre ce que le modèle apporte — transparence immédiate, puis protection commerciale sur quelques années — et qu'une entreprise peut encore changer de cap pour ses versions futures : ce qu'une version publiée garde, c'est la Change Date inscrite dedans.

En 2030, le code d'aujourd'hui sera sous Apache 2.0. Chaque release intermédiaire aura aussi sa Change Date personnelle. C'est la garantie publique : ce code finit open source pour de vrai, sans retour arrière possible.

Que change la publication du code de Filarr pour les utilisateurs ?

Si vous utilisez Filarr aujourd'hui, rien ne change dans votre usage :

• Le binaire sur filarr.com est identique
• Les plans Free, Solo et Pro restent les mêmes
• Vos fichiers chiffrés sur votre disque sont exactement là où ils étaient

Ce qui change, c'est ce que vous pouvez faire en plus :

• Lire le code qui tourne sur votre machine. Le dossier electron/storageService.ts est le bon point d'entrée si vous voulez vérifier une claim crypto précise.
• Reporter un problème de sécurité en responsible disclosure à security@filarr.com.
• Build le binaire vous-même si vous préférez ne pas faire confiance à celui que je signe et distribue.
• Contribuer — bugs, features, traductions, documentation. Le fichier CONTRIBUTING.md explique comment.

Comment lire le code source de Filarr ?

Le repo est grand. Si vous voulez aller droit au but sur la partie qui compte :

• Pour vérifier le chiffrement : commencez par electron/storageService.ts (dérivation, encapsulation et stockage des clés — l'architecture KEK/FEK).
• La chaîne d'upload cloud (electron/sync/) n'est pas dans le repo public : comme le backend, elle fait partie des modules cloud.
• Pour l'UI React : src/renderer/ contient toute l'interface utilisateur.

Un README.md à la racine donne les instructions de build (Node, npm, electron-builder) et un SECURITY.md documente le modèle de menace.

Comment signaler une vulnérabilité dans Filarr ?

Le but d'ouvrir le code est de le rendre auditable. Si vous repérez une vulnérabilité — crypto cassée, fuite de clé, escalation de privilège — merci de la reporter en responsible disclosure plutôt qu'en issue publique.

Contact sécurité : security@filarr.com. Réponse sous 48 heures ouvrées. Je créditerai publiquement toute personne qui signale une vulnérabilité réelle et respecte l'embargo de divulgation.

Quelle est la suite pour le code public de Filarr ?

Dans les prochains mois, je prévois :

1. Un audit de sécurité indépendant par une équipe tierce, avec publication du rapport
2. Un CHANGELOG.md détaillé dans le repo, corrélé aux versions distribuées sur filarr.com
3. Une page pipeline de build pour que vous puissiez vérifier que le binaire distribué correspond bien à un commit tag du repo
4. Ouvrir progressivement la logique de sync cloud si ça a du sens sans compromettre le modèle économique

Si vous voulez juste tester : téléchargez Filarr. Si vous voulez lire avant : le repo est public. Si vous avez des questions : contact@filarr.com.

Merci à toutes les personnes qui ont utilisé Filarr pendant qu'il était encore fermé. Votre patience a aidé à stabiliser le produit jusqu'au point où ouvrir le code avait un vrai sens. Maintenant, vous pouvez le lire.