当GitHub研究指出华为盘古大模型与阿里『通义千问』参数结构相似度高达0.927时，一场关于AI伦理与开源合规的行业地震就此爆发。更戏剧性的是，一位自称华为员工的爆料者揭露了"套壳续训""洗水印"等操作细节，而华为官方坚称"严格遵循开源协议"。这场争议背后，暴露的是每个开发者都可能踩中的开源协议雷区。
开源争议事件始末
事件始于GitHub用户HonestAGI发布的对比研究，显示盘古PanguProMoE与阿里Qwen-2.514B在注意力参数分布上存在异常相似性。面对质疑，华为诺亚方舟实验室声明强调盘古是基于昇腾平台原创开发，仅参考了业界开源实践，并保留了原始版权©️声明。
转折出现在7月6日凌晨，自称盘古团队员工的爆料称，由于算力不足和考核压力，实际采用了"Qwen1.5110B续训+参数扩增"的方案，并通过"训练脏数据"消除水印。该爆料与华为声明的关键矛盾点在于：基于开源代码的增量训练是否构成协议允许的"修改"，以及参数结构调整是否属于"衍生作品"。
开源协议的"隐形炸弹"
Apache2.0协议允许商用和修改，但必须保留原始声明。这正是华为代码中保留Qwen logo的法律依据，也是争议最小的部分。真正的风险隐藏在三个层面：
- 传染性条款：若原始模型使用GPL3.0等强传染性协议，衍生模型必须同样开源。虽然Qwen使用Apache2.0，但混合不同协议依赖项可能触发连锁反应。
- 专利陷阱：Apache2.0要求使用者自动授权相关专利，企业若未建立专利防火墙，可能面临核心技术被动开源。
- 衍生界定：美国法院在Jacobsen诉Katzer案中确立，即便微小修改也可能构成衍生作品。大模型的"续训+结构调整"是否属于此范畴，尚无司法先例。
开发者常踩的5大雷区
Redis Labs与AWS的诉讼揭示：AGPL协议要求SaaS服务公开全部调用代码。而盘古事件暴露的新问题是：
- 协议嵌套：当项目同时引用GPL和MIT代码时，GPL的传染性可能导致整个项目被迫开源。需用ScanCode等工具扫描依赖树。
- 数据清洗：通过脏数据消除水印可能违反DMCA反规避条款，Artifex诉Hancom案已确立此类行为的违法性。
- 声明缺失：即便只使用几行开源代码，未标注来源也可能面临诉讼。Google因Android未完全遵守Linux内核GPL协议支付巨额和解金。
- 参数争议：模型微调后的权重文件是否受版权©️保护？美国版权©️局2023年明确表示"纯参数不构成作品"，但结合架构的完整模型可能受保护。
- 商业边界：将AGPL模型用于内部训练可能无需开源，但对外提供API即触发协议义务，MongoDB与AWS的争端正源于此。
合规自查实战指南
以盘古事件为例，若确实存在Qwen续训，合规做法应包括：在模型文档中明确标注基础模型信息、保留所有原始声明、确保未使用GPL传染性组件。华为声明中提到的"清晰标注版权©️声明"正是合规关键。
开源世界的生存法则
这场争议折射出AI时代的开源困境：当模型训练成本高达数百万美元💵时，"站在巨人肩膀上"的冲动与合规要求形成尖锐矛盾。建议企业设立开源合规官岗位，建立代码审计流程，并参与OIN等专利保护联盟。
正如Linux基金会执行董事Jim Zemlin所言："开源规则不是限制创新的枷锁，而是确保技术革命可持续的轨道。"在算法日益同质化的今天，或许真正的竞争优势将来自对规则的敬畏而非突破。
