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.
If it is you should disclose it and the license should be AGPLv3 instead of Apache.
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.
Seriously though, can you list some examples?
> **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 |