--- title: "下架申诉证据链" date: "2026-08-29" canonical: "https://raytally.com/ideas/2026-08-29-luanti-removed-from-google-play-due-to-baseless-ai-copyright/" generator: "萤录 RayTally · dev-prompt-v4" signal: query: "Luanti removed from Google Play due to baseless AI copyright notice" observed_at: "2026-08-29T00:33:06.143Z" sources: - url: "https://blog.luanti.org/2026/08/27/luanti-dmca-tracer-ai/" boundary: "发布于 2026-08-27T00:00:00.000Z。 观测于 2026-08-29T00:33:06.143Z。" - url: "https://news.ycombinator.com/item?id=49475079" boundary: "发布于 2026-08-28T06:33:57.000Z。 观测于 2026-08-29T00:33:06.143Z。" - url: "https://docs.github.com/en/rest/actions/artifacts?apiVersion=2026-03-10" boundary: "来源记录未提供发布时间。" - url: "https://aboutcode.org/docs/getting_started/license-compliance/" boundary: "来源记录未提供发布时间。" notice: "本任务书中的信号，是在所列时间点截取的有界观察（搜索关注、论坛分数或新品列表），不是市场验证、用户数量或持续需求证明。转述或据此行动时，必须保留这些时间边界与最强反方。" --- [在 RayTally 阅读原始页面](https://raytally.com/ideas/2026-08-29-luanti-removed-from-google-play-due-to-baseless-ai-copyright/) 使用声明：以下信号只是带时间边界的公开观察，不是市场验证、用户数量或持续需求证明；转述或执行时必须保留时间边界与最强反方。 你是资深产品工程师。请把下面这条产品灵感做成一个可以本地运行的 MVP。 ## 灵感 下架申诉证据链 开发者收到版权下架通知后，重建被下架版本，拿到逐项可验证的来源证据和申诉包。 ## 产品概念 独立应用突然收到版权下架通知时，申诉期限往往只剩几天。开发者却得先回忆商店包由哪次提交构建、某张素材从何而来、依赖的许可是否适用于当时版本。下架申诉证据链连接代码仓库、构建流水线、素材目录和许可证文件，把通知中提到的作品、包名或截图拆到具体争议项。 开发者选中被下架的商店版本后，产品在隔离环境重跑对应提交的构建。它从安装包取出文件哈希，再反向追到提交记录、作者、首次引入时间、素材授权和第三方依赖版本。找不到原始凭证的文件会单独标红，不会被一封笼统的申诉信掩盖。 完成核对后，开发者得到按争议项编排的申诉包：每项附有安装包路径、文件哈希、代码历史、许可文本和可复现构建说明。审核方可通过只读链接复核，不必获得整个私有仓库。若开发者修掉了一处真正有问题的素材，产品会把修复版本与原版本清楚分开。 第一批支持 Git 仓库、常见持续集成记录和 Android 安装包，并将证据导出为商店申诉附件。它不替开发者判断侵权责任，也不代替律师提交法律意见。 ## 为什么是现在（有事实支撑） 8 月 27 日，Luanti 称其 Android 应用因一份未指出具体素材的 DMCA 通知而从 Google Play 下架，团队已提交反通知。 截至 8 月 29 日，该事件位于 Hacker News 第 6 名，记录为 430 points 和 135 comments，让独立开发者更容易意识到临时追溯旧包来源的困难。 ## 方向判断（以下为模型推断，未经独立验证） 目标用户：面向独立 Android 开发者、小型工作室和开源维护者。关键时刻是商店版本刚被下架，通知却只给出模糊作品名或截图。此时收入、更新和用户获取可能立即受影响，团队又没有专职法务或合规工程师。负责人需要先确认被投诉包里究竟有什么，再决定反通知、替换素材还是提交修复版。 最小切入点：先接 GitHub App，只申请仓库内容和 Actions 只读权限。通过 Actions 产物接口取得构建包、提交摘要与工作流信息；已有构建证明时一并验证。 APK 在隔离容器内解包，对每个文件计算 SHA-256，并按资源路径建立清单。源码侧用 Git 历史定位首次引入提交、作者记录和后续修改。许可证识别可调用 ScanCode Toolkit，人工上传的授权文件则原样留存。首版只支持可找回提交与构建脚本的 Android 项目，不承诺任意旧版本都能复现。 最强反方：旧版本可能无法复现，这是最先暴露的硬伤。构建镜像、依赖仓库、签名配置或 Actions 产物一旦过期，重跑结果就不能证明与商店包一致。文件哈希只能证明内容相同，不能自动证明授权有效，也不能判断合理使用或版权归属。Git 作者记录还可能只是提交者，并非素材创作者。私有源码和授权合同进入系统后，会带来高敏感数据的隔离、加密与删除成本。若输出暗示了错误的法律结论，开发者可能把有限的申诉机会押在不完整证据上。 以上是模型基于灵感本身与已核验事实的推断，请当作方向假设与真实约束对待：不要默认「最强反方」已被解决，也不要据此在产品里写下确定性结论。 ## 以小博大（模型推断） 第一批用户可从遭遇 Play 商店移除、DMCA 通知或素材争议的开源 Android 项目中触达。围绕真实下架事件发布匿名化证据包示例，让开发者看到输出格式，而非泛讲合规。还可提供一个免费的 APK 文件清单与许可证缺口检查，直接嵌入 GitHub Actions。用户平时积累凭证，出事时再升级到完整重建和申诉导出。 ## 竞品与缝隙（模型推断） - ScanCode Toolkit / ScanCode.io：ScanCode Toolkit 能识别文件中的许可证、版权、作者和来源线索。ScanCode.io 还能用流水线分析包、依赖和二进制，并匹配二进制与源代码。它们适合日常许可证盘点，也能产出 SBOM 和署名材料。 缺口在于工作流仍围绕合规扫描展开。开发者收到下架通知后，还要自行确定被投诉的商店版本，找回当时的构建环境，再把安装包文件与历史提交对齐。扫描结果也不会自动按通知中的争议项编排。产品可复用其检测结果，却把交付物改成可供平台复核的申诉证据包。真正需要补齐的是版本冻结、构建复现、缺失凭证标记、修复前后分离，以及私有仓库的最小披露。 - GitHub Actions 与 Artifact Attestations：GitHub Actions 已保存工作流运行记录和构建产物。产物接口能返回关联提交与摘要，构建证明还能关联仓库、工作流和提交。 这些能力适合证明某个二进制由哪次自动化流程产生。缺口是信息分散在运行页面、日志、产物和仓库历史中。旧产物可能已经过期，素材授权也常在仓库外保存。GitHub 不会理解商店通知中的作品名、截图或包名，更不会判断应附哪些文件。开发者仍需手工解包 APK、逐项追溯来源，再整理成审核方可阅读的材料。该产品的空间是连接现有证明与申诉语境，并提供受限的只读复核链接。 ## 怎么赚钱（模型推断） 按应用项目订阅收费，基础档保存版本证据和生成申诉包；需要私有仓库、较长留存期或团队复核时，升级到团队档。重建任务可设月度额度，超额按次收费，避免隔离构建成本失控。 ## 来源背景 主题：Luanti因AI版权通知被Google Play下架 触发的 Hacker News 原帖（英文原文）：Luanti removed from Google Play due to baseless AI copyright notice 抓取时热度：约 430 分、135 条评论（观测时点数值） 以上数据是抓取时刻的历史快照，分数与评论数会随时间漂移，只用于理解「为什么是现在」，不要写进产品文案当作精确的市场数字。 ## 来源清单 - Luanti removed from Google Play due to baseless AI copyright notice（https://blog.luanti.org/2026/08/27/luanti-dmca-tracer-ai/） - Luanti removed from Google Play due to baseless AI copyright notice（https://news.ycombinator.com/item?id=49475079） - REST API endpoints for GitHub Actions artifacts（https://docs.github.com/en/rest/actions/artifacts?apiVersion=2026-03-10） - License Compliance（https://aboutcode.org/docs/getting_started/license-compliance/） ## 交付要求 - 开工前，先从上文的产品概念与最小切入点提炼 3–5 条可验证的完成标准并列出，交付时逐条对照说明。 - 先交付「最小切入点」描述的核心流程，让核心用户能走通；范围外的账号、支付、后台等通用系统，除非确有必要否则不做。 - 页面或接口里不要展示未经验证的市场数字。 - 关键文案保持克制、可验证；产品内若需要领域事实、安全指引类内容，从「来源清单」等权威来源取材改写并注明出处，不要凭通识编写。 - 若在已有项目里实现：先读 README、依赖与项目约定，遵循既有技术栈与风格，不重构无关代码。 - 若当前目录为空：选一套轻量技术栈，优先交付可运行原型。 - 完成后说明改了什么、如何运行、如何验证。 - 遇到真正会改变产品方向的歧义再提问，普通实现细节自行做工程判断。