近日，开源视频处理领域知名项目FFmpeg的一位核心开发者在GitHub上公开质疑OxideAV项目，指控其存在“AI许可证洗白”行为，即利用AI技术或声称AI辅助，将原本受GPL等严格开源许可证保护的代码重新包装后发布，规避原许可证的约束。这一事件迅速在Hacker News等开发者社区引发热议，凸显了AI时代开源许可证执行面临的新挑战。

根据该开发者发布的issue，OxideAV项目中的一个名为“oxideav-magicyuv”的组件，涉嫌直接复制或改编自FFmpeg中由该开发者维护的MagicYUV编解码器代码。MagicYUV是FFmpeg中一个高效的无损视频编解码器，采用GPL许可证发布。OxideAV在发布其版本时，却声称采用了更宽松的许可证，并暗示其代码是通过AI模型生成或转换而来，从而试图规避GPL的“传染性”要求。

该开发者指出，OxideAV的行为本质上是“许可证洗白”——通过声称AI介入，将原本受严格许可证保护的开源代码，转化为看似全新的、许可证更宽松的代码，从而绕过原作者的知识产权。这种做法不仅违反了开源许可证的法律精神，也伤害了开源社区基于信任和贡献的合作基础。他在issue中详细对比了两组代码的相似之处，包括函数命名、算法逻辑、注释风格等，证据指向明显的复制痕迹。

此事件之所以引发广泛关注，是因为它触及了AI与开源许可证交叉领域的一个核心灰色地带：当AI模型被训练于大量开源代码后，生成的输出是否仍受原许可证约束？如果开发者利用AI“重写”受GPL保护的代码，并以AI生成为由声称拥有新版权或选择更宽松许可证，这是否构成侵权？目前，法律和开源社区对此尚无明确共识。FFmpeg开发者的指控，实际上是在呼吁社区警惕这种利用AI技术漏洞、破坏开源规则的行为。

OxideAV项目团队尚未对此指控做出正式回应。但该issue下已有不少开发者参与讨论，观点分歧明显。一部分人支持FFmpeg开发者，认为无论是否使用AI，只要实质性复制了受保护代码，就必须遵守原许可证；另一部分人则认为，如果AI确实生成了功能相同但表达形式不同的代码，可能构成“洁净室实现”，但需要提供详细的生成过程和训练数据来源以证明原创性。此次争议也促使更多开源项目开始考虑在贡献者协议中明确AI生成代码的归属和许可证要求。

从更宏观的视角看，FFmpeg开发者与OxideAV的冲突，只是AI与开源碰撞的一个缩影。随着GitHub Copilot、ChatGPT等AI编码辅助工具的普及，开发者越来越依赖AI生成代码片段。这些工具的训练数据通常包含大量开源代码，而输出结果可能无意中复制了受保护代码的“记忆”。类似纠纷未来只会更多。开源社区、法律界和AI开发者需要共同探索新的规范，例如强制披露AI训练数据来源、在许可证中增加AI相关条款、以及建立AI生成代码的可追溯机制。FFmpeg此案，或许会成为推动这些变革的一个重要案例。