B-5ISD-obsidian-research-provenance-and-commercial-use
The solutions/agent-pants/docs/vault/research/ documents about Obsidian were derived by unpacking
the shipped application bundle and reading its minified source. Six of them reproduced fragments of
that source verbatim; open-in-agent.md also reproduced three fragments from the Claude Code
binary. #1312 and #1317 removed the reproduced code and restated every finding as observed
behaviour. This entry records what those PRs did not settle.
Obsidian’s Terms of Service prohibit reverse engineering in unusually broad terms — the clause reaches “the source code, object code or underlying structure, ideas or algorithms”, which is wider than copyright reaches, since an algorithm is not itself copyrightable. There is one carve-out, “except for the purpose of developing Third Party Plugins for non-commercial use”, and a separate clause against accessing the software “in order to develop a competing product or service”.
Three things follow, in descending order of how much they matter.
The competing-product clause is the real question, and commercial intent closes the carve-out.
determined is a notes application that reads Obsidian vaults. The plugin exception plausibly
covered the agent-pants plugin work while it was non-commercial; commercial application removes
that shelter and leaves the competing-product clause pointing directly at the vault-reading app.
This wants a human answer — ideally a lawyer’s — before anything ships commercially, not an
engineering judgement call. Copyright and contract are separate here: the interoperability
precedent that would protect intermediate copying (Sega v. Accolade, Sony v. Connectix,
Google v. Oracle) does not dispose of a contractual term, and the EU Software Directive’s
non-waivable study and decompilation rights are EU-specific.
Method: observation is both compliant and better evidence. Using the application and recording
what it does with a given vault is not disassembly, and it produces exactly the input → output
tables the research now carries. bundling-executables.md is the worked example: it asserted
Node-in-renderer from a webPreferences literal while the very next sentence proved the same thing
from the running process arguments. The observation was always the stronger claim and did not need
the bundle. Going forward, prefer driving the app; never check reproduced source into the repo.
The behaviour tables themselves are facts about observable behaviour and are kept. But they were
learned by the prohibited method, and deleting the quotations does not change that. Re-grounding
them by observation is cheap for most rows — the fixture vault at
packages/rust/wikilink/tests/fixtures/vault/ makes them checkable by anyone with a copy of
Obsidian — and it is what would let the specification stand on its own provenance. The ambiguity
rows are the ones that need it most, since they are not settled by any public documentation.
Git history still holds the removed source. #1312 and #1317 clean HEAD; the blobs remain
reachable in history and on the remote. Scrubbing them means a history rewrite across a shared
repository with many open worktrees and branches — disruptive, and plausibly not worth it, but it
should be a decision taken knowingly rather than discovered later.
What to do
Section titled “What to do”- Get a human/legal read on the competing-product clause before any commercial release, given the plugin carve-out no longer applies.
- Re-ground the resolution behaviour table by observation against a running Obsidian, starting with the ambiguity rows that public documentation does not settle.
- Decide, explicitly, whether the history rewrite is worth its cost — and record the answer either way.
- Keep the rule that made the cleanup cheap: research by observation, and no reproduced source in the tree.