Every tool that touches your backup asks for a kind of faith. You download a binary, you point it at the most private folder on your computer, and you hope. You hope it doesn't quietly upload anything. You hope it doesn't stash a copy. You hope it isn't phoning home with a list of your contacts.
With closed-source tools, that's all you can do. The binary is opaque. You can watch its network traffic with packet inspection, but you can't see why it's doing what it's doing. You're trusting a company, and companies can change owners, leadership, or priorities overnight.
Open source changes the unit of trust. Instead of trusting a company, you trust code you can read.
What the MIT license actually says
OpenExtract is MIT-licensed, which is roughly the most permissive open-source license that exists. In plain English, it says:
- You can use it for anything, including commercial purposes.
- You can read every line of source code.
- You can modify it however you like.
- You can redistribute it, including modified versions.
- Our only ask: include the copyright and license notice in copies.
What it does not do — and this is worth being clear about — is automatically guarantee that the binary you download from our release page matches the source code on GitHub. That's a separate property called reproducible builds, and it requires its own discipline. We're working toward it; we're not fully there yet. For the strongest guarantee today, the option is to clone the repo and build from source yourself. It's one command.
What you can actually verify
Here are things you can check right now, in under five minutes, about OpenExtract's source code:
- Whether it makes network calls. Search the repo for
urllib,requests,socket,fetch,http. Every network-capable API in Python and Electron has a recognizable name. If none of them appear in the runtime code, the program cannot reach the network. - Whether it has a telemetry toggle. Search for
analytics,telemetry,track,report. No hidden variants. - Whether the sidecar writes to disk anywhere unexpected. The Python sidecar that parses your backup runs as a subprocess. You can read the entire file list of paths it writes to — it's a finite, inspectable set.
- What happens to your password. Grep for where the backup password enters the code, and follow it. It enters PBKDF2 and is discarded. It isn't stored, isn't logged, isn't hashed-then-saved-for-convenience.
You don't have to take our word for any of it. If we'd wired in a data-harvesting pipeline, it would be a visible commit in the public history, attributable to a specific author, at a specific time.
"I can't read code" — the second-order trust
Most people can't audit a codebase. That's fine. The point of open source isn't that every user personally reads the source; it's that anyone can, and the resulting social pressure is real. Security researchers, hobbyists, competitors, and critics all have access. A vulnerability or a data-harvesting line would be identified publicly — often within days of being committed.
What you're trusting when you use open-source software isn't the original author. It's the visibility. Something harmful added to OpenExtract would be in the public diff, findable by grep, publishable on any blog, within the reach of any security team.
Data as a mirror you can inspect
There's an interesting parallel between why open-source software matters and why extracting your own data matters. Both are about owning a mirror you can inspect. With closed software, you're told what the tool does — you can't check. With a locked-up iPhone backup, you're told what your data says about you — you can't check that either.
We wrote a separate piece about what happens when you can finally check the second one: when you get your own messages out and look at the patterns in the record. It's called The Fortress of Nothing Matters, and it's on Medium. Not a how-to. A reflection on what an inspectable mirror reveals.
The same logic applies to software. A tool you can inspect is a tool that can't lie to you about what it's doing.
Our commitments, in plain form
Because MIT-license-plus-public-repo is still abstract, these are the concrete commitments we hold ourselves to:
- Zero network calls at runtime. The extractor doesn't call home, doesn't check for updates automatically, doesn't send crash reports without opt-in. If you want to verify, the repo is
charleswest775/openextract. - No account, ever. No email capture. No license server. The installer doesn't know who you are.
- No analytics on the desktop app. The website uses Plausible (cookieless, privacy-respecting). The app itself is silent.
- Every change is public. The commit history is the source of truth. We don't rewrite it.
- If this ever changes — if somebody takes over, if the project gets sold, if a new funding model pressures us — it will be in the diff. You'll see it. You can fork.
The right to fork
This is the last and maybe most important thing. If OpenExtract ever becomes something you don't like, you don't have to stop using it. You can fork it — clone the repo, strip whatever you disagree with, maintain your own version indefinitely. The MIT license makes that legal. Git makes it easy. This is the structural guarantee closed-source software can never match.
The one-line takeaway
With closed software, you trust the vendor. With open-source software, you trust the record. Records are harder to corrupt than promises.
— OpenExtract