Hacker News

points by colesantiago 4 days ago | 0 comments

Is this PDF engine vibe-coded and derived from reading the MuPDF source code? (Written from C to Rust) I see some slight references to MuPDF in certain places.

If it is you should disclose it and the license should be AGPLv3 instead of Apache.

[–] ligarota 4 days ago

It's using hayro in Rust

[–] vardhan1237 3 days ago

Definitely not! There is zero MuPDF code, FFI, or transpilation in PaperPilot.

The core PDF parsing and AST manipulation is built on pure Rust libraries: lopdf (0.45), pdf-writer, hayro, and image. All of these are Apache 2.0 or MIT licensed.

Any mention of MuPDF in the documentation/planning notes was strictly part of an architectural trade-off analysis (evaluating existing Python/C extraction pipelines like PyMuPDF vs. pure Rust). The entire crate stack in paperpilot-pdf is 100% Apache 2.0 / MIT clean.

[–] jacquesm 4 days ago

Licenses are so yesterday. /s

Seriously though, can you list some examples?

[–] tredre3 4 days ago

Unless they meant vaguely similar code (which I can't judge), the only mentions of mupdf are in the AI instructions:

    > **The Opportunity:** Capturing the high-growth enterprise AI engineering market by replacing bloated, slow Python extraction pipelines (`Unstructured.io`, `Docling`, `Marker`, `LlamaParse`, `PyMuPDF4LLM`) with a pure-Rust, sub-10ms, multi-format ingestion kernel.
    - This structure guarantees that if we ever swap the PDF engine to `pdfium` or `mupdf`, not a single line of business logic in `paperpilot-core` or CLI tools will need to be rewritten.
    > Directly captures the high-growth AI Engineering & RAG pipeline market (displacing bloated Python stacks like Docling, Marker, PyMuPDF4LLM, and Camelot) with sub-10ms, pure-Rust, on-device parsing.
    | A.2.5 | `MuPdfBackend` adapter (Future) | Use MuPDF for OCR-heavy workflows via FFI |

[–] jacquesm 3 days ago

That's not vague. That's derivation. To use an AI-ism.

[–] jasomill 3 days ago

Without context, just reading the above, it sounds more like they're attempting to create an abstract interface for pluggable PDF engines, which shouldn't pose any licensing issues assuming all the licenses are AGPL v3 compatible and builds that include AGPL engines are only used under the terms of the AGPL, sort of like how ffmpeg works with the "--enable-gpl" switch.