当 git clone 变成「提交申请」
在开源世界，获取源代码通常只需要一行 git clone。但根据 GrapheneOS 项目近日的公开抨击（via Solidot），想拿到 Android 的某些源码，如今的流程是：先在 Google Forms 里填写申请，等 Google 审批，再从 Google Drive 下载——而且审批「越来越慢」。这个以安全加固著称的 Android 衍生系统直接指出：Google 的做法违反了 GPLv2 许可证。
事情的原委
据 GrapheneOS 的说法，目前的情况大致有三点：
- 部分 Android 源码「表单化」：需要通过 Google 表单递交申请，然后经云盘 Google Drive 获取，处理速度每况愈下；
- AOSP 仓库被「瘦身」：公开的 Android 开源项目（AOSP）现在只提供年度版本和季度更新版本 QPR2，以及针对这两个版本的安全回溯移植（backport）；
- Pixel 代码停止同步：Google 不再向 AOSP 推送 Pixel 智能手机相关的特定代码。
第三点对 GrapheneOS 近乎致命。这个项目长期以来只支持 Pixel 设备——正是看中 Pixel 的硬件安全基线。Pixel 专属代码不再进入公开仓库，意味着 GrapheneOS 拿到的代码永远滞后于 Google 内部，安全补丁的跟进节奏被上游卡住。GrapheneOS 也坦言，正是这一状况促使它与摩托罗拉达成合作，预计 2027 年推出首批支持设备。
「开源」和「守约」之间，隔着一个表单
要理解这场争执，得先看 Android 的许可证结构。AOSP 的绝大部分用户空间代码采用宽松的 Apache 2.0 许可证，但 Android 的内核基于 Linux，遵循 GPLv2，系统内还有一批 GPL 组件。GPLv2 对「对应源码」有明确要求：发布了二进制，就应以合理方式提供完整源码，且不得附加额外条件。
GrapheneOS 指控的核心正在于此：把源码从公开仓库撤下、改为「填表—审批—网盘发放」，等于在许可证赋予下游的权利前面加了一道人为闸门；审批慢，则让这道闸门进一步变成事实上的断供。从法律细节看，GPLv2 并未禁止以申请方式延迟提供源码，「表单」本身是否违规仍有讨论空间；但对下游项目而言，法理争议是次要的——维护节奏被拖慢，是每天都在发生的现实。
这也不是孤立事件。近年来 Google 对 AOSP 的公开投入肉眼可见地收缩：开发越来越多地在内部分支进行，公开同步从过去的持续放送变成大颗粒度的定期批量；Pixel 的诸多驱动、固件与新功能本就从未开源，如今连与安全相关的特定代码也开始「内外有别」。社区对此早有怨言，GrapheneOS 只是把它说得更直白、也更有分量——毕竟它是 Android 生态里最较真的安全团队之一，长期给 Pixel 和 AOSP 报漏洞、提补丁。
谁在被卡脖子
直接受影响的是整个下游生态。定制 ROM 项目（LineageOS、CalyxOS 一类）依赖 AOSP 同步来跟进安全补丁；设备厂商和研究机构需要 Pixel 代码来做适配与审计；而 GrapheneOS 这种以 Pixel 为唯一载体的项目处境最被动——它选择 Pixel 恰恰是因为其安全芯片等硬件能力，如今却要为这个选择承担上游断供的代价。转向摩托罗拉，既是务实的对冲，也是一种表态：当上游不再可靠，下游就该为自己修路。
简短点评
Android 当年正是靠开源承诺吸引厂商与开发者，才长成今天全球最大的移动操作系统。但「开源」从来不是一句营销话术，而是一组有法律效力的义务。当源代码需要审批才能获取，"open source"就在悄悄滑向"source available upon approval"。Google 或许有自己的成本与节奏考量，但许可证面前没有「内部流程」这块挡箭牌。对开发者和厂商而言，这件事的教训也很朴素：评估一个平台，别只看它的 license 文件写了什么，还要看上游这些年实际做了什么。