Filarr goes open source — why BSL 1.1

Quick Answer. Filarr's desktop client is open source under Business Source License 1.1 (BSL 1.1), published at github.com/matbel91765/filarr. You can read the code, build it yourself, and verify the cryptographic claims. The cloud backend stays proprietary. The code automatically converts to Apache 2.0 on April 19, 2030 — the date is fixed in the license.

Today, Filarr's desktop client goes open source.

The code is published at github.com/matbel91765/filarr under Business Source License 1.1. You can read it, clone it, build it, and propose fixes. This post explains what's published, what stays closed, why I chose BSL, and what this concretely changes for you.

Why open-source Filarr now?

From day one, Filarr has been selling a precise promise: your data lives encrypted on your disk, and my servers can't read it. That's verifiable in code. It's a specific crypto claim.

As long as the code was private, that promise rested on my word. You could trust me or not. That's a trust debt I didn't want to let sit.

Publishing the code does two things:

1. You no longer have to trust me on my word. You can read the cryptographic modules, the key derivation algorithm, the upload chain — and see for yourself.
2. Security researchers, curious people, and contributors can flag what's broken. More eyes on the code = fewer bugs slipping through.

What's in the Filarr repo (and what's not)?

The repo contains the local-first core of the product. Exactly what you use when you're not signed into an account:

• The Electron/React desktop client
• The cryptographic modules (AES-256-GCM, KEK/FEK architecture, PBKDF2 derivation with 600,000 iterations)
• The TipTap block editor (tasks, tables, wiki-links, transclusion)
• The graph view (physics simulation, community detection)
• The built-in 2D canvas
• The multi-profile system with full key isolation
• Encrypted on-disk storage
• 51+ format file preview

What's not in the repo:

• The api.filarr.com backend (auth, sessions, account management, billing)
• Cross-device cloud sync logic
• Cloudflare R2 infrastructure and associated workers
• Subscription and payment management

The official binary on filarr.com combines both. Without an account, it behaves exactly like the OSS repo. With a subscription, the proprietary cloud modules activate. This is the "open core" model: the product core is open, hosted services are the business model.

Why BSL 1.1 and not MIT, Apache, or AGPL?

The license choice matters. It reflects what you want to protect and what you want to open up. Three options were on the table.

Immediate MIT or Apache 2.0

Upside: the most permissive license, the most adopted, the simplest.

Problem: it lets a competitor fork Filarr, rebrand it, and sell the same product tomorrow. I'm a solo dev. A few months of work copied in an afternoon would end the project. A license that kills the product it frees doesn't help anyone.

AGPL

Upside: strong copyleft, forces modifications to stay open.

Problem: AGPL is network copyleft. If you use the code in a service, you must open-source your entire stack. That's a drag on adoption and contributions, especially in companies where legal often refuses AGPL outright. And it doesn't really protect against competition: a competitor can contribute their changes back and then sell the same service.

BSL 1.1

BSL was designed for exactly this scenario: open the code for audit and contribution, but temporarily forbid commercial uses that would kill the project.

Here's what it says concretely:

• You can: read, clone, modify, build, use for personal, educational, research, evaluation, or development purposes.
• You cannot: deploy in production for your company, sell a service based on this code, host a competing commercial offering. That requires a separate commercial license (email contact@filarr.com).
• Change Date: April 19, 2030. This date is fixed in the license. Starting then, the code automatically becomes Apache License 2.0 — fully open source, no restrictions.

This model is used by Sentry, CockroachDB, MariaDB MaxScale, Couchbase. Projects that have proven it works: immediate transparency, commercial protection for a few years, then real FOSS at the end.

In 2030, today's code will be Apache 2.0. Each intermediate release will have its own Change Date. That's the public guarantee: this code eventually goes fully open source, no take-backs possible.

What does open-sourcing Filarr change for users?

If you're using Filarr today, nothing changes in your usage:

• The binary on filarr.com is identical
• Free, Solo, and Pro plans stay the same
• Your encrypted files on your disk are exactly where they were

What changes is what you can do in addition:

• Read the code that runs on your machine. electron/storageService.ts is the entry point if you want to verify a specific crypto claim.
• Report security issues via responsible disclosure to security@filarr.com.
• Build the binary yourself if you prefer not to trust the one I sign and distribute.
• Contribute — bugs, features, translations, documentation. The CONTRIBUTING.md file explains how.

How can you read the Filarr source code?

The repo is big. If you want to cut straight to the important parts:

• To verify encryption: start with electron/storageService.ts (key derivation and storage) and electron/argon2Service.ts if you're auditing the KEK/FEK architecture.
• To verify the cloud upload chain: electron/sync/syncService.ts orchestrates, electron/sync/syncR2Client.ts builds the encrypted requests, electron/sync/syncManifest.ts handles local merging.
• For the React UI: src/renderer/ contains the entire user interface.

A README.md at the root gives the build instructions (Node, npm, electron-builder) and a SECURITY.md documents the threat model.

How do I report a security issue in Filarr?

The whole point of opening the code is to make it auditable. If you spot a vulnerability — broken crypto, key leak, privilege escalation — please report it via responsible disclosure rather than a public issue.

Security contact: security@filarr.com. Response within 48 business hours. I'll publicly credit anyone who reports a real vulnerability and respects the disclosure embargo.

What comes next for Filarr's open-source plan?

Over the next few months, I'm planning:

1. An independent security audit by a third-party team, with the report published
2. A detailed CHANGELOG.md in the repo, correlated with the versions distributed on filarr.com
3. A build pipeline page so you can verify the distributed binary corresponds to a tagged commit in the repo
4. Progressively opening the cloud sync logic if it makes sense without compromising the business model

If you just want to try it: download Filarr. If you want to read first: the repo is open. If you have questions: contact@filarr.com.

Thanks to everyone who used Filarr while it was still closed. Your patience helped stabilize the product to the point where opening the code genuinely made sense. Now you can read it.