开源合规机制研究——以生成式人工智能产业的软件开源许可证为例

一. 开源许可证概述

   符合开源定义的许可证，即开源许可证，也称为开源协议。开源的标准由开源促进会（Open Source Initiative, OSI）制定，主要包括以下要素1：（1）免费再分发；（2）程序包含源代码；（3）可以修改和二次开发；（4）确保源代码完整性；（5）不歧视个人或群体；（6）不歧视应用领域；（7）允许重新分发；（8）不基于特定产品；（9）不限制其他软件；（10）技术中立。

开源许可证适用的场景既包括软件、代码，也包括数据集、版权或者是硬件。最常见的是软件开源许可证，例如在选择开源许可证的网站（https://choosealicense.com/licenses/）上列示的GNU AGPLv3、GNU GPLv3、GNU LGPLv3、Mozilla Public License 2.0、Apache License 2.0、MIT License等，其他涉及数据集或版权适用的开源许可证则包括Creative Commons Zero v1.0 Universal（CC0-1.0）、Creative Commons Attribution 4.0 International（CC-BY-4.0）、Creative Commons Attribution Share Alike 4.0 International（ CC-BY-SA-4.0）等，硬件也有可适用的开源许可证，包括CERN Open Hardware Licence Version 2 – Permissive（CERN-OHL-P-2.0 ）、CERN Open Hardware Licence Version 2 – Weakly Reciprocal（CERN-OHL-W-2.0 ）、CERN Open Hardware Licence Version 2 – Strongly Reciprocal（CERN-OHL-S-2.0 ）2等；甚至于字体也有专门的开源许可证，例如SIL Open Font License 1.13。
根据中国信通院的定义，开源是一种分布式协作模式，并且逐渐成为新的软件开发模式4。开源的目的是为了促进技术创新、开放协同，其与商业模式有一定区别，但并不意味着开源的就是免费的，公开的就是开源的。以软件为例，开源软件并不等于免费软件（可以使用开源软件收费），也不等于公开软件（二次开发可以闭源，即不公开代码）。开源指向的是一种特定形态的产品5，通常体现为软件、算法、数据甚至硬件、字体等形态；该产品可以根据开发者的选择适用各种开源许可证，呈现出不同的开源模式。开发者既可以完全适用已有的开源许可证，也可以修订现存开源许可证，或者制定新的开源许可证；开发者也可以在一个开源产品上同时适用多个开源许可证，例如将开源产品中的代码、模型、数据等分别适用不同的开源许可证。根据开源许可证中限制分发的强弱程度，可将主要的开源许可证分为以下两种类型：

1. 宽松许可型（Permissive），即开发者只要按照开源要求分发，保留版权声明，即可不受限制的拥有开源软件的使用权限，包括使用、复制、修改、合并、发布、分发、再许可和/或销售等方式。换言之，宽松许可型的开源许可证，开发者可以直接商用、二次开发，并且后续可以选择继续开源或者闭源，开发者拥有较大的处置自由。例如MIT许可证6，Apache2.0许可证7等。
2. 强著佐权型（Copyleft），与著作权（Copyright）的法益相反，通常只要前序软件适用了该类型的开源许可证，后续开发的软件将被强制“传染”成为开源软件。即一旦开源，后续不能再闭源。这是为了促进开发者群体的技术合作和创新，促进代码之间的自由共享。典型的例子可参考GNU AGPL、GNU GPLv3许可证等8。
   但实务中，在软件领域仍存在其他多种类型的开源许可证，有些许可证并不适合按照上述原则做统一归类。例如在GNU AGPL以及 GNU GPL许可证这类强著佐权类型下，还存在一类弱著佐权类型，即LGPL（Lesser General Public License）许可证，这是GPL许可证下的附加许可证。在适用LGPL许可证情形下，开发者可以通过仅链接或组合的方式，避免后续开发不得闭源的情形。又如Meta公司就其开源的Llama模型专门设置的Llama2社区许可协议，虽然具备一定的开源因素，例如免费分发、可修改、含源代码等，但其在第2条中规定了月活量超7亿的用户必须获得Meta公司的单独授权才能使用，模型卡内规定Llama2开源模型不适用于除英语以外的语言中使用8，同时违反了开源要素中的第（5）条不限制用户或群体的内容；以及第1条第2款第5项中规定了不得使用Llama模型去提高其他语言模型的限制，违反了开源要素中第（9）条不限制其他软件的内容。显然，Llama2社区许可协议并非典型开源许可协议。近期，相关新闻爆出Yi万物疑似存在抄袭Llama2模型代码的行为，显然违反了开源许可协议中有关规定。虽未看到Meta的公开追责，但此行为必然存在极大的侵权风险10。所以在技术开发场景下，需根据业务实际使用的开源软件对应的开源许可证规则，做具体的开源合规设计与安排。

二. 常见开源许可证梳理

   根据开源许可证被适用的频率，常见的软件开源许可证及相关规则如下图，主要从商业使用、代码分发、网络调用也属于分发、复制及修改、版权声明、商标使用、责任限制、担保条款等方面进行规则梳理，由Choosealicense网站整理并制图，并作中文直译如下：11

在不同的社区或代码平台，其对开源许可证的偏好不同。例如， Apache平台以及Cloud Native Computing Foundation 平台外推荐使用Apache License 2.0， GNU平台则为大多数的项目推荐GNU GPLv3 ；Npm packages 强烈推荐适用 MIT 以及相类似的ISC 等。根据开源许可证中设置的条件数量排序，例如可商用、可分发、可修改及对应的局限性等，许可证规则数量由高到低（或根据宽松程度由低到高）分别为：GNU AGPLv3＞GNU GPLv3＞GNU LGPLv3＞Mozilla Public License 2.0＞Apache License 2.0＞MIT License＞Boost Software License 1.0＞The Unlicense12。

三. AIGC开源大模型中的开源许可证

在生成式人工智能发展的浪潮中，开源大模型遍地开花。本节主要对生成式人工智能行业目前已开源大模型适用的开源许可证情况做简要的规则梳理。其中值得注意的是，国外开源模型对开源内容并未做细致的许可证规则划分，而国内的开源大模型中，开源模型通常被拆分为代码（Model Code）、模型权重（Model Weights）以及数据等内容，并分别适用不同的开源许可证。

从上述内容可知，目前国内外生成式人工智能行业内的开源大模型适用的开源许可证各有千秋。根据开发者的需求，针对开源组件不同而适用开源程度不同的许可证，或者是新创开源规则等。整体而言，对于版权声明、免责声明、原样提供的要求基本保持一致，核心的差别主要在于后续的开源传染性特征、商业化路径、二次开发、限制用途范围等方面。所以在使用开源模型进行商业化设计时，应当尤其注意使用了GPL类许可证的开源模型，应用中应考虑对于具体代码使用、分发以及开源传染性的有关限制性规则条款，否则可能导致后续开发的源代码被强制披露、公开的后果。

四. 开源许可证境内法律规制

针对开源许可证的性质及其法律适用，目前国内并无明确的法律规定。国内涉及开源许可证类型的争议解决时，通常体现为《著作权法》中关于著作权许可、转让、侵权认定及处理等相关法规，以及《民法典》中涉及单方意思表示成立、合同成立、解除、终止等相关法规。
在开源许可证引发争议的有限几起司法判例中，各地法院并未达成一致意见。一些地方知识产权法院将该类开源许可证认为是著作权合同，而最高人民法院仅仅是引用了其中一类开源许可证的条款作为释明依据，并未明确其性质和适用范围。例如，在济宁市罗盒网络科技有限公司、广州市玩友网络科技有限公司等侵害计算机软件著作权纠纷一案24中，广州知识产权法院依据原《合同法》第45条（现《民法典》第158条）认定GNU GPLv3为附解除条件的著作权合同，且“许可条款是版权许可的条件，如果用户违背条款规定，那么许可的前提条件已不复存在，则GPLv3协议（GNU GPLv3）终止适用，用户获得的授权也将自动终止”25。在近期的深圳市君用科技有限公司等与山西梦多福科技有限公司不正当竞争纠纷一案26中，北京市西城区人民法院在论述Apache2.0开源协议的证据效力时，认为“开源协议本质上是许可协议，目的在于鼓励软件开发者共享自己的代码，向使用者开放一定权限，这种公开许可的内容主要针对的是软件代码的复制、修改，涉及的是软件著作权相关问题”27。而在北京闪亮时尚信息技术有限公司与不乱买电子商务（北京）有限公司侵害计算机软件著作权纠纷一案中28，最高人民法院在二审程序中则直接引用了GNU GPLv3第5条关于聚合体作品的认定方式的内容，并基于该内容对涉案软件做出是否属于开源软件的判断。但最高人民法院并未在该案中释明GNU GPLv3的性质，究竟是格式化合同还是权利声明文件，不得而知。且我国并非判例法国家，即使根据同案同判、类案类判的原则，在开源许可证种类繁多、规则差别较大的情况下，现有的案例裁判观点恐怕也无法实现普遍的适用，仅能起到非常有限的参考作用。例如GPL类许可证的核心特征即开源会传染，而MIT许可证通常是修改即可闭源，开源规则的重大区别将在个案中实质影响双方争议处理的走向。
在国家标准层面，近期由全国信息安全标准化技术委员会发布了一版《信息安全技术 软件产品开源代码安全评价方法》的征求意见稿，其中对软件产品包含的开源代码许可证的规范性做了具体评价要素的规定，评价范围包括许可证的授权范围、授权条件、违约与授权终止、免责声明等，以及履行开源许可证规定的相关条款、义务情况。同时开源许可证的互惠性、兼容性、其专利授予情况及适用范围，均被纳入到评价范围中29。

五. 开源风险概述

承前所述，在各类开源许可证的法律性质不明，适用范围不清的现状下，目前在使用开源软件中会存在以下风险：
其一，开发者选择开源许可证时，对于开源许可证的理解通常面临条款内容太复杂、考虑因素不确定这两项困难30。开源许可证主要由基本信息、序言、 定义、 授权范围、义务、违约与授权终止、 担保与责任限制、准据法、许可证版本与兼容性、许可证使用说明等部分组成31。常用的几类开源许可证多为外文许可证，实务中选择许可证或者使用这类许可证下的开源软件时，则可能出现规则内容理解困难、不同司法管辖权的法律适用不熟悉等问题。
其二，一个开源软件可能适用多类许可证，许可证之间规则可能不兼容。例如上述提到的AI开源大模型发布中，可能将模型权重、代码、数据分别适用不同开放程度的许可证。后续开发者在集成多个开源模型时，则需要考虑各模型之间适用的开源许可证兼容问题。
其三，开源软件本身可能存在的侵权问题，例如开源软件使用了未经授权的专利，导致后续使用者需承担专利侵权赔偿；或者使用者未经许可使用颁发者的商标信息，包括商号、商标、服务标记或产品名称等使用的限制等。
其四，如违反开源许可证，可能面临多重路径的救济维权。例如将开源许可证视为负解除条件的合同，如果违反其中规则，则相关开源软件授权视为自动终止。如将开源许可证认为是著作权许可合同，则可能涉及著作权侵权责任承担等。
其五，开源软件可能根据开发者需求针对不同版本或开发进程，对原开源许可证规则进行调整或变更，或直接加入商业使用限制条款。常见情形是开源软件孵化为商业公司，为了获得商业利益，从宽松的开源许可证变更为强著佐权开源许可证，抑或使用双许可的方式，在原先的开源许可协议上添加商业授权条款。

作者：
甘青锋（360集团高级法律顾问）
夏杰（实习生）

文章来源：网络法实务圈