Anthropic删库风波：一纸DMCA误伤8000多个GitHub项目，AI时代的“维权误炸”来了

一场想“止血”的维权，结果先把自己社区吓了一跳

Anthropic这两天上演了一出很典型、也很现代的科技行业戏码：代码泄露了，公司急了，律师出手了，GitHub动了，然后一群本来老老实实参与开源协作的开发者突然发现——自己的仓库没了。

事情起因并不复杂。Anthropic此前泄露了一批Claude Code客户端源码，公司随即通过DMCA，也就是美国《数字千年版权法》的下架机制，要求GitHub移除相关仓库。问题在于，这次下架并没有只精准命中泄露代码所在的仓库和少量明确列出的分叉项目，而是顺着“fork network”一路扫过去，最后波及了大约8100个相关仓库。

这就尴尬了。因为被扫进去的，不只是那些传播泄露代码的镜像仓库，还包括大量基于Anthropic官方公开Claude Code仓库创建的合法fork。换句话说，本来是公司自己公开放在GitHub上、鼓励大家提bug和修修补补的代码生态，一夜之间也被自己家的维权动作误伤了。

开发者社区的反应可想而知。有人在社交媒体上直接开喷，讽刺Anthropic“你们把源代码放出来的是自己人，结果看不懂仓库结构的却是律师”。这种话听起来辛辣，但也点中了问题核心：在GitHub这样一个以fork、协作、派生开发为日常操作的平台上，版权执法如果缺少技术语境，很容易从“维权”滑向“误炸”。

GitHub的fork机制，为什么这么容易让律师团队踩坑

如果你不常混GitHub，可能会觉得这事奇怪：一个仓库泄露了，删掉那个仓库不就行了吗，怎么还能连坐八千多个？答案就藏在GitHub最基础、也最开源精神的设计里——fork。

在GitHub上，fork本来就是协作工具。一个公开项目发布后，任何人都可以把它“分叉”到自己的账号下，做修改、提PR、验证bug、做实验性功能。这套机制是GitHub成为全球开发协作中心的关键。但也正因为如此，当一个侵权仓库本身挂在一个fork网络里，平台如果依据“整个网络都可能同样侵权”的逻辑去批量处置，就很容易把合法仓库也一锅端掉。

从GitHub披露的DMCA文件看，Anthropic最初点名的是一个包含泄露源码的仓库以及近百个明确列出的fork。但GitHub后来扩展处理到了整个相似fork网络，理由是提交方认为“所有或大多数fork都具有同等程度的侵权性质”。这句法律语言看着顺，放在代码世界里就不一定成立了。因为两个仓库处在同一个fork树上，不代表它们的实际内容一样；有的仓库可能早就只保留了官方开源部分，有的甚至压根没有包含泄露文件。

这场误伤其实揭示了一个老问题：法律系统喜欢按“关系”判断，工程系统更强调“内容”判断。可惜在高压应急状态下，很多公司会优先选最快、最保险、最能立刻止损的路径，而不是最精细、最讲开发者体验的那条路。对于法务来说，这是风险管理；对于开发者来说，这就是无差别扫射。

Anthropic为什么这么着急？因为源码一旦泄了，就很难再收回来

站在Anthropic的角度，这次动作也不是完全不能理解。Claude Code并不是普通的营销页面源文件，而是和公司AI编程产品能力、产品路线、工程实现细节都直接相关的代码资产。此前媒体已经从泄露内容里分析出Anthropic不少产品规划和技术线索。对一家正处在大模型竞争最激烈赛段的公司来说，这种泄露不仅是版权问题，也是商业情报问题。

问题在于，互联网时代的源码泄露，最怕的就是“晚一步”。一旦原始仓库被人镜像、fork、打包、迁移到多个平台，它就像洒出去的水。你能擦掉桌面上的一滩，却拦不住地缝里那部分。Ars Technica提到，泄露代码目前仍然能在GitHub上找到，也已经扩散到Codeberg等美国DMCA触达不到的平台。

更麻烦的是，现在还有AI帮忙“洗稿”代码。已经有开发者利用AI编程工具，把原始泄露的TypeScript代码重写成Python和Rust版本，打着所谓“clean room reimplementation”的旗号重新发布。这里的法律争议非常有意思，也非常棘手：如果功能、结构、接口设计高度相似，但具体代码是由AI重写的，它到底算不算衍生作品？

这不是纸上谈兵。过去软件行业也有“洁净室重写”的传统，比如为了兼容某些商业系统，人们会通过隔离文档、隔离团队的方式做合法复刻。但AI让这件事变得模糊了：模型既能高速重写，又很难说清楚“参考”和“复制”的边界。未来几年，围绕AI生成代码的版权诉讼，很可能会越来越多，而这次Anthropic事件只是一个预告片。

更微妙的一层：如果AI写了代码，版权到底还稳不稳？

这件事还有一个特别耐人寻味的细节。Anthropic Claude Code负责人Boris Cherny此前曾公开表示，自己过去30天里对Claude Code的贡献“100%由Claude Code写成”。这句话在产品宣传里听着很酷，像是“我们已经吃上自己做的AI红利了”；可一旦进入版权战场，它就可能变成另一种麻烦。

因为美国版权局这几年对AI生成内容的态度越来越清晰：人类主导、AI辅助的作品，可以获得版权保护；但如果作品基本由AI自动生成，人类创作性贡献不足，那么版权保护就会变弱，甚至无法成立。代码也不例外。

这就引出一个有点黑色幽默的问题：一家AI公司一边宣传“我们的AI几乎自己把产品写出来了”，一边又希望在泄露后主张完整、强力、无争议的版权保护。这两种叙事在市场宣传上都成立，但在法律上未必能完美兼容。未来如果真有法院深入审查这些代码的生成过程，AI参与比例、人类审核与修改程度、代码中哪些部分具有独创性，都会成为关键。

也就是说，这次风波不只是一次仓库下架事故，它还提前碰到了AI时代软件产权的核心难题：当代码生产开始自动化，版权的锚点究竟还落在哪里？落在人类工程师的设计意图上，落在提示词和审核流程上，还是仍然落在最后输出的那段字符本身？

被误伤的不是仓库，而是信任

在我看来，这场事件最值得行业警惕的，不是Anthropic一次操作失误，而是AI公司与开发者社区之间那种越来越微妙的关系。

过去几年，几乎所有大模型公司都在向开发者示好：开放SDK、开放API、维护GitHub仓库、鼓励社区共创，讲的是“我们一起把AI工具做大”。但另一面，这些公司又越来越依赖闭源模型、私有系统提示词、内部工具链和商业机密来维持竞争壁垒。一旦发生泄露，它们又会迅速切回高度防御模式，甚至不惜扩大打击半径。

这种双重身份并不稀奇，OpenAI、Google、Meta其实都面临类似张力。只是Anthropic这次把矛盾暴露得更彻底：你一方面把官方仓库挂在GitHub，欢迎开发者fork；另一方面，一旦危机来临，你的治理机制却可能先伤到最支持你的人。

这也是为什么开发者对误封特别敏感。开源社区最看重的不是“绝对自由”，而是可预期的规则。你可以说哪些东西不能碰，可以说泄露源码必须删，但你不能让大家觉得，自己合法fork一个官方仓库，也可能因为一次大公司法务误判而突然消失。如果这种不确定性变成常态，开发者会慢慢收缩，社区协作意愿也会被消耗。

Anthropic已经撤回了大范围处理请求，GitHub也恢复了相关仓库访问，这当然是纠偏。但修复仓库容易，修复信任没那么快。尤其是在AI代码工具越来越深入软件开发流程的今天，平台、公司和社区都需要一套更细粒度的应急机制：哪些是泄露内容，哪些是公开代码，哪些是功能相似但实现独立的重写版本，不能再靠“看起来像一张网，就整张网一起下掉”。

说到底，这次闹剧提醒了所有AI公司一件事：你当然可以试图关上马厩的门，但在生成式AI和全球代码镜像早已遍地跑的年代，马早就不只跑了，还可能顺手生了几匹新马。真正决定行业走向的，不是谁删仓库更快，而是谁能在商业防线、法律工具和开发者信任之间，找到那个不那么粗暴的平衡点。