开源协议困境：AI时代下malus项目的讽刺性警示

AI时代的开源协议，正面临前所未有的脆弱性。最近的一个典型案例是Claude Code，其源码刚刚泄露，第二天你就能看到一个用Rust重写的版本。类似的例子还有OpenClaw，开源没多久，各种用其他语言重写或精简重构的变种就已经出现了十多种。

而一个名为Malus.sh的项目，恰好尖锐地讽刺了这一点。它提供的是一种“AI clean-room”服务，你可以理解为“开源洗白即服务”。

它的逻辑很简单：只要有足够的Token，AI就能进行“拷贝”。这就像雇佣了能复制任何忍术的卡卡西，只要投入足够的“查克拉”（Token），你就能规模化、低成本、自动化地“洗白”任何开源项目，规避掉许可证的约束。

这动摇了开源协议长久以来的基本闭环。传统模式下，开发者开源代码，公司可以免费使用，但需要遵守许可证的规则，至少在明面上大家要维持这个平衡：

• MIT、Apache这类宽松许可证，至少要求保留原作者署名和声明。
• GPL、AGPL这类Copyleft许可证，则要求衍生作品在特定条件下也必须开放源代码。

这些机制的核心意图，往往并非“禁止商业使用”，而是希望建立一种最低限度的回馈：使用了公共成果，至少保留作者的信用；如果基于强Copyleft项目进行了派生开发，至少应该把改动贡献出来。

这其实和版权保护的逻辑有些类似——版权保护的是具体的“表达”，而不是背后的“创意”或“思想方法”。那么问题来了：如果我让AI去“阅读”你的项目，然后根据其功能和设计，输出一个全新的、代码完全不同的实现，这是否还受原项目开源协议的约束？

在过去，要想规避开源协议进行“洗白”，需要投入大量时间进行人工重写和痕迹清除。但现在，AI可以轻易做到这一点。在最近的FOSDEM 2026大会上，就有相关演讲专门讨论了这个棘手的问题。

开源许可证约束的是你对“这份具体代码”的使用、复制、修改和分发行为。但如果AI重写后的版本，使用了另一种编程语言、换了一套实现写法，甚至架构都不同，那么原来的许可证还能否适用？从目前的实践来看，答案很可能是否定的。

这就带来了一个更深刻的悖论。以AGPL为例，它最初就是为了防止SaaS公司使用开源项目提供云服务却不回馈源码。但如果现在公司可以利用“AI clean-room重写”技术，轻松绕开AGPL的约束，那么这个协议本身的意义何在？原作者的持续影响力和可能获得的开源赞助，又将如何&维系？

Malus.sh的作者自己也坦言，这个项目既是讽刺（Satire），又是功能完备（Functional）的。它揭示了一个根本性矛盾：开源许可证过去依赖“复制代码”这一物理事实来建立约束力，而AI却让“复制功能而不复制代码”变得几乎没有成本。

因此，一个清晰的趋势正在浮现：单纯的“代码开源”已经很难再成为坚固的护城河。未来的壁垒可能会更多地向品牌、社区治理、专属数据、测试集、兼容性认证、云服务、发布工程、安全响应能力等维度转移。甚至在AI时代，许多关键的测试集和基准数据本身，就可能走向闭源。

Malus项目恰恰讽刺了当下这种尴尬现状：我可以充分利用你的社区智慧、产品设计、API经验以及生态验证，但只要我不直接复制你的代码，我就可以声称不欠你任何东西。

这也折射出GitHub当前的一种现象。在AI时代，人们疯狂地为项目点Star，但许多时候，这些Star更像是为一种“概念”或“故事”买单，带着一种FOMO（错失恐惧症）的色彩。某种程度上，GitHub正在成为AI界的“小红书”，热度与项目的实际可持续性未必完全相关。

这一切都指向一个不容回避的现实：在AI的重写能力面前，传统的开源协议显得十分脆弱。

来源：互联网