[合规] 依赖 AGPL-3.0 的 PyMuPDF，MIT 项目存在网络服务传染风险

[Alex-Fleet]

标题: [合规] 依赖 AGPL-3.0 的 PyMuPDF，MIT 项目存在网络服务传染风险

正文:

问题

本项目 LICENSE 声明为 MIT，但 backend/package/pyproject.toml 直接依赖 pymupdf（PyMuPDF）。PyMuPDF 采用双许可：AGPL-3.0 或 Artifex 商业许可。

AGPL-3.0 比 GPL-3.0 更严格：即使以网络服务形式对外提供（不发行副本），只要服务端使用了 AGPL 代码，整个服务端程序须以 AGPL-3.0 开源。本项目的 API 是 FastAPI 网络服务，通过 API 对外提供基于 PyMuPDF 的 PDF 解析/预检/OCR 渲染能力，会触发该条款。

使用位置

PyMuPDF (fitz) 直接用于 PDF 处理链路：

• backend/package/yuxi/knowledge/utils/pdf_utils.py — PDF 页树预检（validate_pdf_page_tree_loadable）
• backend/package/yuxi/knowledge/parser/rapid_ocr.py — PDF 渲染为图像供 OCR
• backend/package/yuxi/knowledge/parser/deepseek_ocr.py — 打开/解析 PDF
• backend/package/yuxi/utils/__init__.py — 打开 PDF

建议

1. 评估替换：PDF 结构解析可换 pypdf（BSD，已在约束依赖里）/ pdfplumber（MIT）；但 OCR 流程需要把 PDF 页渲染成位图，pypdf/pdfplumber 均不支持渲染，需评估 pdfium（Apache-2.0）/ poppler 等替代或调整 OCR 输入路径；
2. 或购买 Artifex 商业许可；
3. 或与社区讨论后明确调整项目许可证策略（整体转 AGPL-3.0 不现实，因为大量依赖是 MIT/Apache，需谨慎评估）。

影响面

这是一个需要维护者决策的合规问题，不是简单的 bug 修复。建议优先讨论，再决定代码改动方向。