Il codice di Filarr diventa pubblico: perché la licenza BSL 1.1

Risposta rapida. Il client desktop di Filarr è pubblicato con la Business Source License 1.1 (BSL 1.1), su github.com/matbel91765/filarr. Puoi leggere il codice, compilarlo da solo e verificare le affermazioni crittografiche del client. Il backend cloud resta proprietario. Il termine esatto è «source available»: il codice diventa open source nel senso dell’OSI solo il 19 aprile 2030, quando passa automaticamente ad Apache 2.0; la data è fissata nella licenza.

Da oggi il codice sorgente del client desktop di Filarr è pubblico.

Il codice è pubblicato su github.com/matbel91765/filarr sotto Business Source License 1.1. Puoi leggerlo, clonarlo, compilarlo e proporre correzioni. Questo articolo spiega cosa è pubblicato, cosa resta chiuso, perché ho scelto la BSL e cosa cambia concretamente per te.

Perché pubblicare adesso il codice di Filarr?

Fin dal primo giorno Filarr vende una promessa precisa: i tuoi dati vivono crittografati sul tuo disco, e i miei server non possono leggerli. È verificabile nel codice. È un’affermazione crittografica specifica.

Finché il codice era privato, quella promessa si reggeva sulla mia parola. Potevi fidarti di me oppure no. È un debito di fiducia che non volevo lasciare in sospeso.

Pubblicare il codice fa due cose:

1. Non devi più fidarti della mia parola. Puoi leggere i moduli crittografici e l’algoritmo di derivazione della chiave, e verificare da solo.
2. Ricercatori di sicurezza, curiosi e collaboratori possono segnalare ciò che non va. Più occhi sul codice = meno bug che sfuggono.

Cosa c’è nel repository di Filarr (e cosa no)?

Il repository contiene il cuore local-first del prodotto. Esattamente ciò che usi quando non sei collegato a un account:

• Il client desktop Electron/React
• I moduli crittografici (AES-256-GCM, architettura KEK/FEK, derivazione PBKDF2 a 600.000 iterazioni)
• L’editor a blocchi TipTap (attività, tabelle, wiki-link, transclusione)
• La vista a grafo (simulazione fisica, rilevamento delle comunità)
• Il canvas 2D integrato
• Il sistema multi-profilo con isolamento completo delle chiavi
• L’archiviazione crittografata sul disco
• L’anteprima di file in oltre 80 formati

Cosa non c’è nel repository:

• Il backend api.filarr.com (autenticazione, sessioni, gestione degli account, fatturazione)
• La logica di sincronizzazione cloud tra dispositivi
• L’infrastruttura Cloudflare R2 e i worker associati
• La gestione degli abbonamenti e dei pagamenti

Il binario ufficiale su filarr.com unisce le due parti. Senza account, si comporta esattamente come il repository pubblico. Con un account si attivano i moduli cloud proprietari. È il modello «open core», nella sua forma source available: il cuore del prodotto è pubblico, i servizi ospitati sono il modello di business.

Perché la BSL 1.1 e non MIT, Apache o AGPL?

La scelta della licenza conta. Riflette ciò che vuoi proteggere e ciò che vuoi aprire. Sul tavolo c’erano tre opzioni.

MIT o Apache 2.0 subito

Il vantaggio: la licenza più permissiva, la più adottata, la più semplice.

Il problema: permette a un concorrente di fare un fork di Filarr, cambiargli nome e vendere lo stesso prodotto domani. Sono uno sviluppatore solo. Qualche mese di lavoro copiato in un pomeriggio metterebbe fine al progetto. Una licenza che uccide il prodotto che libera non aiuta nessuno.

AGPL

Il vantaggio: un copyleft forte, che obbliga le modifiche a restare aperte.

Il problema: l’AGPL è un copyleft di rete. Se usi il codice in un servizio, devi pubblicare come open source tutto il tuo stack. È un freno all’adozione e ai contributi, soprattutto nelle aziende, dove spesso l’ufficio legale rifiuta l’AGPL senza discutere. E non protegge davvero dalla concorrenza: un concorrente può restituire le sue modifiche e poi vendere lo stesso servizio.

BSL 1.1

La BSL è stata pensata esattamente per questo scenario: aprire il codice all’audit e ai contributi, ma vietare temporaneamente gli usi commerciali che ucciderebbero il progetto.

Ecco cosa dice concretamente:

• Puoi: leggere, clonare, modificare, compilare, usare per scopi personali, didattici, di ricerca, di valutazione o di sviluppo.
• Non puoi: metterlo in produzione nella tua azienda, vendere un servizio basato su questo codice, ospitare un’offerta commerciale concorrente. Per questo serve una licenza commerciale separata (scrivi a contact@filarr.com).
• Change Date: 19 aprile 2030. Questa data è fissata nella licenza. Da quel giorno il codice diventa automaticamente Apache License 2.0: completamente open source, senza restrizioni.

Questo modello è usato da Sentry, CockroachDB, MariaDB MaxScale, Couchbase. Progetti che hanno dimostrato che funziona: trasparenza immediata, protezione commerciale per qualche anno, poi vero software libero alla fine.

Nel 2030 il codice di oggi sarà Apache 2.0. Ogni versione intermedia avrà la propria Change Date. È questa la garanzia pubblica: questo codice finirà per diventare completamente open source, senza possibilità di tornare indietro.

Cosa cambia per gli utenti la pubblicazione del codice di Filarr?

Se usi Filarr oggi, non cambia nulla nel tuo utilizzo:

• Il binario su filarr.com è identico
• I piani Free, Solo e Pro restano gli stessi
• I tuoi file crittografati sul disco sono esattamente dov’erano

Quello che cambia è ciò che puoi fare in più:

• Leggere il codice che gira sul tuo computer. electron/storageService.ts è il punto di partenza se vuoi verificare un’affermazione crittografica precisa.
• Segnalare problemi di sicurezza con una divulgazione responsabile a security@filarr.com.
• Compilare il binario da solo se preferisci non fidarti di quello che firmo e distribuisco.
• Contribuire: bug, funzioni, traduzioni, documentazione. Il file CONTRIBUTING.md spiega come.

Come leggere il codice sorgente di Filarr?

Il repository è grande. Se vuoi andare dritto alle parti importanti:

• Per verificare la crittografia: comincia da electron/storageService.ts (derivazione della chiave, incapsulamento e archiviazione: l’architettura KEK/FEK).
• La catena di caricamento nel cloud (electron/sync/) non è nel repository pubblico: come il backend, appartiene ai moduli cloud.
• Per l’interfaccia React: src/renderer/ contiene tutta l’interfaccia utente.

Un README.md nella radice fornisce le istruzioni di compilazione (Node, npm, electron-builder) e un SECURITY.md documenta il modello di minaccia.

Come segnalo un problema di sicurezza in Filarr?

Il senso stesso dell’apertura del codice è renderlo verificabile. Se trovi una vulnerabilità (crittografia difettosa, fuga di chiavi, escalation dei privilegi), segnalala per favore con una divulgazione responsabile invece che con una issue pubblica.

Contatto per la sicurezza: security@filarr.com. Risposta entro 48 ore lavorative. Citerò pubblicamente chiunque segnali una vera vulnerabilità e rispetti l’embargo di divulgazione.

Cosa viene dopo per il codice pubblico di Filarr?

Nei prossimi mesi prevedo:

1. Un audit di sicurezza indipendente da parte di un team esterno, con il rapporto pubblicato
2. Un CHANGELOG.md dettagliato nel repository, allineato con le versioni distribuite su filarr.com
3. Una pagina sulla pipeline di build, così potrai verificare che il binario distribuito corrisponda a un commit etichettato nel repository
4. L’apertura progressiva della logica di sincronizzazione cloud, se ha senso senza compromettere il modello di business

Se vuoi solo provarlo: scarica Filarr. Se vuoi prima leggere: il repository è pubblico. Se hai domande: contact@filarr.com.

Grazie a te, se hai usato Filarr quando era ancora chiuso. La tua pazienza ha aiutato a stabilizzare il prodotto fino al punto in cui aprire il codice aveva davvero senso. Ora puoi leggerlo.