[r3dbars]

Fixes the privacy-licensing findings from the bug hunt over #2530. This PR only touches THIRD_PARTY_LICENSES.md and docs. No code, build script or workflow changes. Every license text added here was fetched from the upstream repo at the exact tag or commit and pasted unchanged, none typed from memory.

What was wrong, and what changed

One commit per finding.

1. Sentry notices (cabb6e8). The app ships Sentry.framework 9.10.0, which contains SentryCrash plus code derived from other projects. The notice file only had Sentry's own MIT text, so the KSCrash MIT, the YANDEX MIT, the fishhook BSD-3-Clause and the Apple Public Source License 2.0 notices were missing from every signed build. Added all four with full texts, copied from THIRD_PARTY_NOTICES.md at the 9.10.0 tag, plus a pointer to the 9.10.0 source (the APSL asks for that).

2. FluidAudio notices (764270d). fastcluster (BSD) is statically linked into the app and its license requires the copyright notice, conditions and disclaimer to travel with binaries. The file just said the texts "ship in the upstream repository". Added fastcluster, VBx, the Japanese G2P/UniDic notices and the Spanish/French lexicon notices, copied from ThirdPartyLicenses/ at v0.17.2. The finding suggested dropping the Kokoro G2P and UniDic text if unlinked. They are linked (JapaneseG2P, JapaneseCutlet, JapaneseMecabDictionary and the multilingual G2P model objects are in a local app build's link map), so I kept them. I left out the NeMo text-processing notice because that trait is off and its library isn't linked.

3. llama.cpp (e581ea6). The section said the revision "isn't recorded yet" (it is: 2115b73d8e...) and that vendored license texts live in upstream's licenses/ directory. At that commit that directory holds only the nlohmann/json text. Now recorded: the commit, a table of what llama-server is built from (read from upstream's CMake files and source headers, because the shipped helper is stripped), and the texts for nlohmann/json, cpp-httplib, llamafile sgemm, the YaRN-derived code, xxHash, rotate-bits and the Unlicense/stb_image/miniaudio dedications. I also checked the web UI snapshot: all 70 embedded assets in the pinned helper decompress to the same SHA-256 as the 70 files in the b10612 dist.tar.gz, so the provenance doc's "likely b10612" is now confirmed, and I updated it.

4. Packages swift-transformers pulls in (72f95b9). Hub depends on swift-huggingface, swift-collections, swift-crypto and yyjson, and swift-huggingface on EventSource. A local build's link map shows swift-huggingface, swift-collections (OrderedCollections), EventSource and yyjson objects linked, and the file listed none of them. Added sections for swift-huggingface 0.13.0, EventSource 1.6.0, swift-collections 1.7.6, swift-crypto 4.5.2 (with NOTICE.txt) and yyjson 0.12.0, at the revisions a fresh swift package resolve of the build-deps graph returned today. Fixed the header, which said library versions are pinned in build-deps.sh (only the top-level ones are). Clarified the MCP section's swift-collections sentence: it is about the helper's lockfile, while the app does link OrderedCollections.

5. Diarizer notice wording (ce3feae). The notice named FluidAudio's pinned model revision as if the app used it. FluidAudioCompatibility.keepUnpinnedDiarizerCaches() overrides it to main, so a runtime download can differ from the checked revision. Reworded, and described the build-beta.sh cache copy accurately (no allowlist, no hash check). This is the notice-wording half of that finding only.

6. New doc (96bba72). docs/third-party-notices.md, indexed in docs/README.md: a before-release checklist saying which version variable each entry follows and how to see the versions SwiftPM resolves for the floating packages. It is a new file so I did not touch docs/release-packaging.md, which the test matrix maps to full release builds.

Where I disagreed with the findings

• swift-crypto is not in the binary. The finding says its code is linked. It isn't: on macOS the Crypto module re-exports CryptoKit, BoringSSL/XKCP build only on other platforms, and none of the package's 94 Crypto objects (or the BoringSSL ones) appear in a local build's link map. swift-asn1 isn't linked either and has no entry. I kept a swift-crypto entry anyway because its version floats, and wrote the linking status into the entry.
• VBx is Apache-2.0 and the Apache text was already in the file, so the real gap was only its copyright line, which vbx-LICENSE.md carries. Added the whole file.
• Pinning the transitive versions (the finding's other suggestion) needs a build-deps.sh change, which was out of scope. The notice file now says plainly that they float.

Not done here: owner follow-ups

1. .github/workflows/publish-mcp-registry.yml (finding 5). The .mcpb it zips holds only transcripted-mcp, manifest.json and an icon. The helper statically links the MCP Swift SDK, swift-system, swift-log and EventSource, and none of their notices are in the bundle. Suggested fix: copy THIRD_PARTY_LICENSES.md (or an MCP-only extract) into $stage before the zip. Bundles already attached to releases won't change unless rebuilt.
2. scripts/entrypoints/build-beta.sh (finding 6). ditto copies the whole local diarizer cache into the app with no allowlist and no hash check, so any legacy model file sitting in a build machine's cache would ship. Suggested fix: copy only the Community-1 files, verify their SHA-256s against the pinned provenance.json, and fail on anything else. Record bundled model hashes and cached revisions in a build manifest #2664 already edits this file, so I left it for that PR.
3. llama-server web UI notices. The embedded UI is minified JavaScript from the npm dependencies of tools/ui (the lockfile has 1,213 packages, build tooling included). The shipped bytes carry no notices and the bundled subset can't be read back from them, so I left this as a marked GAP in the file instead of guessing. The file lists the direct imports with their lockfile licenses and includes the texts for the libraries vendored under tools/ui. Closing it means either an owned build without the UI or generating the notices from the lockfile. If you go the owned-build route: at that commit LLAMA_BUILD_UI=OFF alone doesn't stop the prebuilt UI download, you also need LLAMA_USE_PREBUILT_UI=OFF (from reading upstream's scripts/ui-assets.cmake; not built to confirm). I noted this in docs/llama-server-provenance.md.
4. Floating transitive versions. Pin them in build-deps.sh or commit a lockfile for the generated graph, so a release build can't pick different versions than the notices name.

Checks

• bash check.sh changed --base e66e3e4f : PASS (source pins, doc-paths self-test, doc-paths).
• bash check.sh quick : PASS, every step, including doc paths, known traps, rule registry, test shape and the privacy leak sweep.
• scripts/dev/agent-preflight.sh : PASS.
• .githooks/public-repo-guard.py on the outgoing commits : exit 0. I also grepped the diff and commit messages for competitor names and found none.
• Verbatim check (scratch script, not committed): every reproduced text (20 upstream files, the 4 Sentry blocks, and 4 extracted snippets) is found byte-for-byte in the notice file. For the five SwiftPM packages and two of the FluidAudio files I also compared against SwiftPM's own checkouts of the same revisions and the bytes match.
• No Swift build or tests: nothing under Sources/ or Tests/ changed.

What isn't verified

• The link-map claims come from a recent local app build in a sibling worktree, not from a build of this exact head. The dependency graph is the same, but I haven't rebuilt at e66e3e4.
• The 70/70 UI asset match used a local copy of the pinned helper from a sibling worktree's deps-tools.
• The versions of the floating packages are what SwiftPM resolved on 2026-11-12. A release build could resolve others.
• The YaRN license text is from that repo's current head, since llama.cpp's comment names no commit. Its copyright line matches the one quoted in llama.cpp's source.
• The vendored-code table for llama-server comes from upstream's build files and headers, not from the stripped binary.
• No regression test. Tests/README.md points consistency checks at scripts/dev/check-*.py, which would need wiring into the rule registry and test matrix, outside this PR's docs-only scope. A check that compares the versions in build-deps.sh with the notice file would be the right follow-up.
• Two license texts keep an upstream copyright line that includes an email address (yyjson, rotate-bits), because the notice has to be reproduced as written. Say if you want those handled differently.

🤖 Generated with Claude Code