大模型开源模式合规治理研究

摘要：近年来，全球掀起大模型研究浪潮：ChatGPT、豆包、DeepSeek等人工智能大模型接连问世。大模型的开发研究需要强大的技术来支撑，采用开源模式开发研究大模型可以降低研发成本。但采用开源模式并非放弃知识产权，对使用开源代码开发的大模型仍需进行知识产权保护。然而，由于采用开源模式的大模型是通过开源许可协议并非以传统地“面对面”的方式进行签订，由此产生了违反开源许可协议条款的法律责任、开源许可协议中限制商业使用条款、使用开源代码生成合作作品著作权归属等一系列相关问题。本文对上述问题进行了研究讨论并提出完善意见以期推动大模型开源模式合规治理。

关键词：开源大模型；开源许可协议；演绎作品和合作作品

一、引言

大模型是指包含超大规模参数（通常在10亿个以上）的深度学习或机器学习模型。开源是指将源代码公开发布并允许他人查看、修改和使用的行为。开源模式的核心在于开源社区，开源项目发起人可以在开源社区中发布源代码、模型权重或数据等；用户可以使用源代码，也可以通过修改源代码共同参与项目开发。开源大模型开发者在公开源代码时可以选择适用不同的开源许可协议或者制定新的开源许可协议，用户在使用源代码时应遵守该源代码适用的开源许可协议。

大模型往往需要强大的技术和巨大的训练数据来支撑，而开源可以允许社会大众及中小型企业近距离接触大模型研究，有助于吸引大量开发者参与大模型研究、降低研发成本，从而加速推动大模型技术的创新发展及快速应用。《中华人民共和国国民经济和社会发展第十四个五年规划和2035年远景目标纲要》中指出，要支持数字技术开源社区等创新联合体发展，完善开源知识产权和法律体系，鼓励企业开放软件源代码、硬件设计和应用服务。

目前，我国尚缺乏关于大模型开源模式下合规问题的法律规定，关于开源许可协议的法律性质、成立时间、附加限制商业使用条款的效力等法律问题仍不明晰。同时，如果用户基于开源项目管理者公开的源代码进行修改产生新版本，司法实践中对开源项目开发者可否独立对合作作品提起侵权之诉、他人可否对演绎作品主张开源抗辩等问题也存在争议。故笔者在下文中将对上述大模型开源模式下相关合规问题展开讨论，以期维护良好的开源环境，推动大模型开源建设。

二、开源许可协议的法律问题

（一）违反开源许可协议的法律责任

1.问题

在开源模式下，用户可以使用开源项目者公开的源代码。如果用户未遵守该源代码适用的开源许可协议的约定，其是否应当承担法律责任以及应承担何种法律责任？对此问题，有些企业认为开源项目者选择公开源代码则可以任意使用该源代码无需承担法律责任。笔者认为要回答这个问题，首先应当明确开源许可协议的法律性质。

2.两种法律责任

（1）违约责任

目前，我国司法实践中基本已经就开源许可协议的法律性质达成一致意见：开源许可协议是一种知识产权许可协议。[ 徐美玲：《软件著作权侵权“开源抗辩”解析》，《知识产权》，2024年第6期。]而开源项目管理者公布源代码并不代表其作出了放弃其对源代码享有的知识产权的意思表示，也即开源并不意味着贡献者放弃了其享有的知识产权，而是通过开源许可协议授权他人复制、修改开源大模型的源代码、模型权重或数据等。因而，用户违反开源许可协议应承担违约责任。

同时，开源许可协议是一种格式合同。所谓格式合同，是指格式合同的提供者为了重复使用而预先拟定合同，在订立合同时未与对方协商的条款。开源许可协议符合格式条款的三个特征。因此代码贡献者，也即格式条款的提供者应当依法履行提示说明的义务。根据《中华人民共和国民法典》第四百九十六条规定，若开源许可协议提供方未履行提示或者说明义务，致使对方没有注意或者理解与其有重大利害关系的条款的，对方可以主张该条款不成为合同的内容。

（2）侵权责任

用户违反开源许可协议还可能构成侵权责任。在罗盒公司诉玩友公司一案中，广州知识产权法院指出，GPLV3协议属于附解除条件的著作权合同，以用户违反开源许可协议下义务为解除条款，如果用户违背条款规定则GPLV3协议终止适用，即用户对涉案软件源代码的复制、发布行为因失去权利来源而构成侵权。

3.完善建议

对于违反开源许可协议的法律责任的问题，笔者认为应通过立法方式明确开源许可协议的知识产权许可协议、格式条款的法律性质问题。同时，开源项目管理者在发布开源许可协议时应注意以下几点：第一，应当依法履行提示说明的义务，否则某些条款可能不构成合同内容。第二，应当在开源许可协议中对“解除合同”条款作出明确约定：若用户违反开源许可协议项下义务，则开源许可协议终止，用户丧失开源许可协议项下权利。那么，当用户违反开源许可协议时，开源项目管理者可主张用户丧失对源代码的复制、发布等权利，请求其承担违约责任。

（二）开源许可协议的成立时间

1.问题

如果开源项目管理者在公开源代码后更换了适用的开源许可协议甚至删除开源许可协议，则存在开源项目者与用户之间是否成立开源许可协议、成立何种版本开源许可协议的问题。例如，在罗盒公司诉玩友公司一案中，罗盒公司的股东之一罗迪开发完成初始版本，于2016年7月7日首次上传该软件开源项目至GitHub并适用LGPL V3许可协议开源，2017年1月24日更新声明任何人不得免费使用该源代码，2017年10月29日删除了GPL V3许可协议，并于2017年12月30日停止更新该项目，转为开发不开源的商业版本。如果认为因罗盒公司删除开源许可协议而双方之间不存在知识产权许可协议，则玩友公司便不能使用该源代码，需要为更换使用其他源代码而付出高昂成本。

关于开源许可协议成立时间的问题，广州知识产权法院认为，贡献者发布开源软件视为发出要约，用户使用该源代码时视为作出承诺，在用户使用开源软件时合同成立。[ 济宁市罗盒网络科技有限公司、广州市玩友网络科技有限公司等侵害计算机软件著作权纠纷民事一审民事判决书，（2019）粤73知民初207号。]但是，若以“用户使用源代码”的时间作为合同成立的时间固然可以解释协议成立的过程，却会产生用户使用该源代码的时间如何确定的问题，可能导致司法裁判中难以判断开源许可协议的成立时间。

2.完善建议

笔者认为，可以通过立法的方式明确当用户下载源代码时开源许可协议成立。贡献者发布开源代码以及开源许可协议时具有与他人订立合同的意思，此为要约。为了防止用户在该源代码的基础上进行研发时贡献者更改或者删除开源许可协议造成用户需要更换源代码的风险，应推定用户复制（下载）源代码时具有接受许可协议的意思表示，也即用户复制（下载）源代码视为承诺，开源许可协议成立。

（三）限制商业使用条款的效力

1.问题

开源管理者提供源代码时可能附加限制商业使用的条款，要求用户在出于商业目的使用源代码时应另行申请许可。但是OSI对开源软件的10个定义要求“不能歧视任何领域”，不得规定软件不能用于商业目的。该限制商业使用条款是否会因为违反开源精神而无效呢？

2.完善建议

上述OSI对开源的定义属于狭义的含义，在法律语境中开源软件事实上一种独特的知识产权许可。在一般的知识产权许可中，被许可方须和许可方进行磋商、签订合同，从而获得授权。而在开源模式下，项目管理者（许可方）将源代码公开发布，用户（被许可方）在下载源代码时两者之间成立开源许可协议。OSI对开源含义的规定并非法律、行政法规的强制性规定，限制商业使用条款并不当然无效。

通义千问开源许可协议第四条约定，若用户将模型用于商业使用应当另行申请许可，笔者认为该商业限制条款有效。原因在于，根据《中华人民共和国民法典》规定当合同存在以下三种情况时合同无效：行为人不具备相应行为能力、意思表示不真实或者违反法律、行政法规的强制性规定。显然，通义千问开源许可协议第四条约定并不存在上述情况，因而该限制商业使用条款有效。

在罗盒公司诉玩友公司一案中，项目管理者于2016年9月10日将授权许可协议更改为GPL3.0协议，于2017年7月3日作出声明“当您需要将VA用于商业途径时，需要进行授权”。然而根据GPL3.0协议第七条约定，“如果你接收到的程序或其部分，声称受本协议约束，并补充了这种进一步的限制条款，你可以删除这些条款。”因而，上述项目管理者作出的声明并不属于开源许可协议的合同内容。

三、关于合作作品和演绎作品的法律问题

（一）开源项目管理者是否有权单独提起诉讼

1.问题

在开源模式下，项目管理者在开源社区公开代码后，用户可以提出修改源代码的申请，项目管理者可以选择接受其修改申请，从而形成新的源代码版本。由于新版本的形成包含了项目管理者和众多用户的共同付出，因此在涉及开源软件的著作权侵权纠纷中常常涉及新版本是否构成合作作品、开源项目管理者是否须经其他合作作者授权方可提起诉讼的问题，例如福建风灵创景科技有限公司、北京风灵创景科技有限公司等侵害计算机软件著作权纠纷案（以下简称“罗盒诉风灵案”）。

新版本存在构成合作作品的可能性。合作作品是指经两个以上作者共同创作所形成的作品，其构成要件包括共同创作的合意以及对最终作品共同做出了独创性贡献，而开源模式下用户参与大模型的研发完全存在符合上述两个要件的可能性。在共同创作的合意方面，用户提交修改申请、开源项目管理者接受申请，将修改的源代码并入主分支时，两者之间便达成了共同创作的合意。而用户是否做出了独创性的贡献则需要根据具体案例进行分析。因此，新版本存在构成合作作品的可能性，用户可能成为合作作者。因而应讨论的问题是开源项目管理者是否可以不经其他合作作者许可单独提起诉讼。

2.完善建议

笔者认为，若开源贡献者协议中对著作权归属进行了约定应依照约定；若没有约定应采用最高人民法院的观点。原因在于：《中华人民共和国著作权法》第十四条规定，“不能协商一致，又无正当理由的，任何一方不得阻止他方行使除转让、许可他人专有使用、出质以外的其他权利，但是所得收益应当合理分配给所有合作作者。”由于开源大模型开发的著作权主体并不明确，应当允许开源项目管理者单独提起诉讼。

综上所述，关于开源项目管理者是否有权单独提起诉讼的问题，笔者认为开源项目管理者在开源贡献者协议中应当对著作权归属及诉权等问题作出约定；若没有进行约定，应当明确开源项目管理者有权单独提起诉讼。

（二）针对演绎作品提出的开源抗辩是否成立

1.问题

如果用户A基于开源项目管理者公布的源代码进行修改并形成演绎作品，但是未履行上述源代码适用的“传染性”开源许可协议项下的义务，未公开修改后的源代码，用户B未经许可使用该演绎作品是否对用户A成立侵权？我国司法实践中对于该问题存在不同的裁判观点，存在同案不同判的情况。例如，在南京未来高新技术有限公司（以下简称“未来公司”）诉江苏云蜻蜓信息科技有限公司等侵害计算机软件著作权纠纷一案中，南京市中级人民法院认为涉案软件主程序使用了开源源代码，该源代码适用GPLV2协议，因此未来公司应当履行GPLV2协议公开源代码。未来公司未公开主程序源代码构成违法，因而对其主张侵权责任不予支持。[ （2021）苏01民初3229号。]而在网经科技（苏州）有限公司诉浙江亿邦通信科技有限公司等侵害计算机软件著作权纠纷案一案中，最高人民法院指出，软件开发者自身是否违反GPL 2.0与是否享有软件著作权，是相对独立的两个法律问题，二者不宜混为一谈，因此对被告提出的开源抗辩不予支持。

2.完善建议

笔者认为，关于针对演绎作品提出开源抗辩能否成立的问题，应当以立法方式加以明确规定：基于开源源代码产生的演绎作品违反开源许可协议公开源代码义务的，使用演绎作品的用户主张不承担侵权责任的，人民法院不予支持。

原因在于，关于演绎作品的著作权和原始源代码作者的著作权是两个独立的法律问题。若用户在保持原始源代码的基础上增加符合独创性的新表达，则构成演绎作品，用户对该演绎作品享有著作权。[ 王迁：《知识产权法教程》，北京：中国人民大学出版社，2021年，第225-227页。]至于该用户违反原始源代码适用的开源许可协议，则该用户对原始源代码作者应承担违约责任或者侵权责任，但该责任并不影响其对演绎作品享有著作权。因此，他人侵犯该演绎作品著作权的应当承担侵权责任。对演绎作品著作权人违反公开源代码义务的问题，原始源代码作者可对其主张违约责任或者侵权责任，以维护源代码的公开和传播。如果认为演绎作品非法而不予保护，反而可能不利于技术创新发展。

四、小结

维护开源生态良好环境，推动开源创新，需要各方主体共同努力。首先，应建设开源生态相关法律，例如对开源许可协议的法律性质、成立时间、限制商业使用条款的效力，合作作品及演绎作品等相关问题作出明确规定。其次，应重视和加强开源社区自律管理，例如开源社区对提供的源代码进行审核并要求提供原创声明。最后，在市场主体层面包括开源项目管理者和用户两类主体。开源项目管理者在协议中应尽可能完善相关规定，例如对合作作品的著作权归属、违反开源许可协议即解除合同等问题作出明确约定，防止后续纠纷。用户在使用源代码时应注意阅读开源许可协议，履行开源许可协议项下义务。