Filarr passe en open source — pourquoi BSL 1.1

Réponse rapide. Le client desktop de Filarr est open source sous Business Source License 1.1 (BSL 1.1), publié sur github.com/matbel91765/filarr. Vous pouvez lire le code, le construire vous-même et vérifier les claims cryptographiques. Le backend cloud reste propriétaire. Le code passe automatiquement en Apache 2.0 le 19 avril 2030 — la date est fixée dans la licence.

Aujourd'hui, le client desktop de Filarr devient open source.

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, l'algorithme de dérivation de clé, la chaîne d'upload — 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 51+ 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 OSS. Avec un abonnement, les modules cloud propriétaires s'activent. C'est le modèle "open core" : le cœur du produit est open, 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.

Ce modèle est utilisé par Sentry, CockroachDB, MariaDB MaxScale, Couchbase. Des projets qui ont prouvé que ça marche : transparence immédiate, protection commerciale sur quelques années, puis vraie FOSS à la fin.

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 l'open-source 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 et stockage des clés) et electron/argon2Service.ts si vous auditez l'architecture KEK/FEK.
• Pour vérifier la chaîne d'upload cloud : electron/sync/syncService.ts orchestre, electron/sync/syncR2Client.ts monte les requêtes chiffrées, electron/sync/syncManifest.ts gère le merge local.
• 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 de l'open-source pour 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 ouvert. 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.