行稳致远，以稳步前行为发展战略
跬步千里，以匠心传承铸品质服务
实务研究｜企业使用开源软件的常见法律问题及风险防控
企业在开发商业软件过程中，经常会大量使用开源软件（或开源技术）。在最终发布的整体软件中会结合很多的开源软件。开源软件一般都会携带开源协议，开源协议规定企业在使用、复制、修改、发布开源软件等时的权利和义务。企业使用开源软件时，常会遇到怎样发布二进制软件才能符合开源协议要求的问题，本文将对这些问题进行初步分析，以供企业参考。
一、什么是开源协议
1、开源协议的含义
软件著作权人可以将其享有著作权的软件进行发布，如果发布公开了软件的源代码，则一般可以称其为开源软件。与之相反的发布方式为商业软件，即仅发布二进制软件，一般不公开软件的源代码。因此，开源的含义为开放源代码，是软件进行发布的一种方式；开源软件一般而言是公开源代码的软件。
在介绍开源协议之前，先简要介绍一下软件著作权。计算机软件的知识产权保护包括著作权、专利权、商标权、商业秘密等方式。其中著作权保护为最主要的方式，一方面，由于计算机软件版本更新速度快，而著作权为自动取得，即软件开发完成之时便自动取得，不像专利和商标权需要申请或注册才能取得；另一方面，计算机软件可以进行登记，相对于商业秘密权属的证明难、取证难，著作权的维权相对容易。根据《中华人民共和国著作权法》（以下简称著作权法）第三条的规定，计算机软件属于著作权法所保护的作品。根据《计算机软件保护条例》第三条，计算机程序，是指为了得到某种结果而可以由计算机等具有信息处理能力的装置执行的代码化指令序列，或者可以被自动转换成代码化指令序列的符号化指令序列或者符号化语句序列。同一计算机程序的源程序和目标程序为同一作品。根据《计算机软件保护条例》第八条，软件著作权人享有的权利包括：发表权、署名权、修改权、复制权、发行权、出租权、信息网络传播权、翻译权等九项权利。
根据著作权法，软件著作权人对其以源代码方式发布的软件，享有发表权、署名权等人身权，以及复制权、发行权等财产权。为了促进自由软件的发展，使用户能够更加自由地使用软件，开源软件的著作权人在发布软件的源代码时，为用户提供了复制、修改、再发布等多项自由使用软件的权利，同时也设定了一些义务。规定这些权利和义务的书面文件和开源软件一起发布，这样的书面文件1就是开源协议。
2、企业应按照开源协议的要求使用开源软件
企业在使用开源软件开发自己的软件时，应当遵守开源协议的条款，尤其是再发布软件时，须符合开源协议的要求。表1列出了部分开源协议的常见要求。
表1：部分开源协议的常见要求
如果用户违反开源协议约定的内容，软件著作权人可以寻求违约责任或侵权责任的法律救济。例如，在Jacobsen诉Katzer案2中，美国联邦巡回上诉法院认为开源协议是一种著作权协议，如果违反开源协议不仅属于违约，也构成对著作权的侵权；在Artifex诉Hancom案3中美国加州联邦法院认为，违反开源协议，允许进行合同法和著作权法下可能的救济；在Haraly Welter 诉 Sitecom案中德国慕尼黑地区法院认为，开源协议属于著作权契约，用户违约时，软件著作权人可以主张违约责任或侵权责任。4目前在我国的司法实践中，一般认定开源协议是著作权人和用户之间附解除条件的许可合同。用户违反开源协议既是一种违约行为，也是一种侵权行为，根据我国《民法典》第一百八十六条规定，著作权人有权寻求违约救济或侵权救济。5 例如，在我国近期开源作者起诉被告违反开源协议、侵害著作权案的判决6中就明确指出，GPL3.0协议规定的使用条件（如开放源代码、标注著作权信息和修改信息等）系权利人许可用户自由使用的前提条件，亦即协议所附的解除条件。一旦用户违反了使用的前提条件，将导致GPL3.0协议在授权人与用户之间自动解除，用户基于协议获得的许可即时终止。用户实施的复制、修改、发布等行为，因失去权利来源而构成侵权。
二、开源协议之间的兼容性
1、开源协议的类型
自GNU发布GPL开源协议以来，随着开源软件的发展和广泛使用，出现了上百种的开源协议。按照开源协议要求发布软件的开源程度，可以将开源协议划分为强著佐权型、弱著佐权型、商业友好型。
强著佐权型的主要特点：要求对开源软件的再发布无论是否修改，只要发布的软件中包含开源软件则都需要将源代码以相同的开源协议或者其更新版本进行发布。该类代表的开源协议如GPL2.0，GPL3.0，AGPL3.0。
弱著佐权型的主要特点：如果对开源软件的任何部分有修改，需要对修改部分发布源代码。在满足一定条件下不需要发布软件全部的源代码，即包含开源软件的一个更大的软件的其他部分的源代码不要求以源代码方式发布。该类型代表的开源协议如LGPL2.1，MPL1.1。
商业友好型的主要特点：不要求用户以源代码的方式再发布修改或无修改的开源软件，用户可以在发布的二进制软件中使用开源软件而不必公开任何源代码。但是，一般要求在发布的二进制软件中包含软件著作权人的版权声明。该类代表的开源协议如MIT，BSD-2-Clause。
2、开源协议的共同特点
强著佐权型、弱著佐权型、商业友好型的开源协议虽然存在很大差异，但是也有很多共同之处。首先，它们均鼓励开源软件的传播，为此授权给用户自由使用、修改、复制、再发布等权利，并且都不收取费用；其次，需要用户保留软件著作权人的版权声明，以及向其下游用户提供这些版权声明；最后，由于参与开源软件创作的著作权人非常多，历经多次的修改和更新，并且开源软件不收取费用，因此软件著作权人都会声明不保证开源代码的质量，不承担由于开源代码的使用引起的赔偿责任，并且要求再发布时保留这些声明。
3、开源协议之间的兼容性
一个开源软件的项目一般是为了实现特定的功能而发布的源代码，企业在开发商用软件时为了开发出满足客户需求的完整软件产品，会结合使用多种类型的开源软件；而不同开源软件受到不同的开源协议条款的约束，因此是否能够在一个软件中结合使用这些开源软件，即开源软件的兼容性问题是企业面临的一个重要问题。7
不同的开源协议在概念定义、授予权利、负担义务、专利许可、商标使用、限制条件、版权声明等条款的设定方面存在很多差异，对相同问题的不同规定会引发冲突，因此发布的整体软件中不同开源软件之间是否能够不冲突地共存，即开源软件之间是否兼容是企业使用开源软件的一个疑难问题。
需要注意的是，开源协议对企业的内部使用并无特别限制，一般来说只有再次发布软件时兼容性才是应当考虑的问题。
表2：不同类型开源协议之间的兼容性8
强著佐权型的开源协议要求按照相同的开源协议再发布软件，并且设定的条件数量多、细致严格，加之不同的开源协议在具体条款设置上差异较大，因此强著佐权型开源协议之间通常是不兼容的。例如，GPL3.0的终止条款比GPL2.0要更为宽松，它们的终止条款不同，因此这两个许可证是不兼容的9。如果结合GPL2.0和GPL3.0项下发布的开源软件，则会违反了GPL2.0的第6条的规定10。
弱著佐权型的开源协议大多为了兼顾商业使用而对强著佐权型的开源协议改进演化而来的，并不要求包含开源软件的整体软件均需要按照相同的开源协议以源代码的方式再发布，仅对整个软件中开源软件的部分的再发布以及使用有一些特定的要求。因此，对于同一个组织或公司发布的弱著佐权型和强著佐权型的开源软件之间一般是兼容的，例如GNU发布的LGPL2.1与GPL2.0之间是兼容的9，并且LGPL2.1下的开源软件可以再以GPL2.0发布，但是该过程一般不可逆；但是对于不属于同一个组织和公司的弱著佐权型和强著佐权型的开源软件之间一般是不兼容的，例如Netscape公司发布的MPL1.1和GNU发布GPL2.0之间不兼容。11如上是常见的弱著佐权型和强著佐权型的开源协议兼容性的举例，而实践中具体的弱著佐权型和强著佐权型开源软件之间是否兼容需要查看具体协议条款，进行对比分析才可以确定。
不同弱著佐权型的开源协议之间的兼容性问题稍微复杂一些，需要分情况处理。由于弱著佐权型的开源协议并不要求结合了弱著佐权软件的整体软件都要按照相同开源协议进行发布，仅要求弱著佐权型开源协议下的这部分软件再发布要求按照该弱著佐权型开源协议发布，因此，可以将不同弱著佐权型开源协议分为两种情况；第一，不同弱著佐权型的开源软件被结合到一个整体软件的不同模块或者按照各自的库被整体软件引用，在此情况下，由于它们分属不同弱著佐权型开源协议的约束，而一般不会产生兼容性的问题，换言之，在此情形下，不同的弱著佐权型开源协议之间是兼容的；第二，不同弱著佐权型开源软件被结合在同一个模块（或同一个库）中被整体软件引用，在此种情况下，需要考虑两个弱著佐权型开源协议的兼容性问题，一般而言，由于不同的弱著佐权型开源协议对相同问题的规定一般有所区别，同一个模块（或库）很难同时满足不同的弱著佐权型开源协议的要求，因此，在此情形下，不同的弱著佐权型的开源软件之间是不兼容的。
商业友好型的开源协议大多都赋予了用户自由使用、修改、合并、再发布开源软件等权利，并且规定的限制条款非常少，甚至没有限制条款。例如，MIT和其它开源软件都是兼容的，BSD12开源软件也可以和其它开源软件很好地共存13。因此，商业友好型开源协议和商业友好型、弱著佐权型和强著佐权型的开源协议之间一般都是兼容的。
4、整体软件采用何种开源协议发布
结合了不同的开源软件形成完整软件产品，就会面临发布的问题，是以源代码的方式发布还是以二进制的方式发布。如果仅以二进制方式发布，需要特别注意整体软件中不能含有强著佐权型的开源软件，否则将会面临违约或侵权的风险，本文后面还会详细讨论以二进制发布整体软件应当注意的问题；如果选择以源代码方式发布完整软件，企业需要考虑如下两点：第一，所有结合的开源软件是否满足兼容性要求；第二，整体软件采用何种开源协议发布。
企业采用何种开源协议发布整体软件，需要基于企业的对软件的盈利模式、商业安排等因素进行综合考虑，本文仅从开源协议自身条款的要求进行分析。
图1：部分开源协议的兼容性关系图
图1列出了常见的开源协议之间的兼容性关系图。下面以LGPL2.1和GPL2.0之间的关系说明图1的含义。根据LGPL2.1第3条的规定，用户可以使用GPL2.0的条款来取代LGPL2.1上的条款，并且改变是不能撤销的，换言之，LGPL2.1项下的开源软件可以以GPL2.0发布，但是GPL2.0项下的开源软件不可以再以LGPL2.1发布。因此，它们的关系可以解释为：有连接的两个开源协议之间具有兼容性，再发布软件需要以箭头指向的开源协议进行发布，而不能以箭头左侧的开源协议发布。以此类推，例如结合了MIT，BSD-2-Clause，LGPL2.1，GPL2.0的整体软件，一方面由于自MIT至GPL2.0之前均有箭头连接，因此这些开源软件之间都是兼容的；另一方面，GPL2.0位于箭头的最右侧，因此整体软件可以以GPL2.0开源协议进行发布。需要注意的是，没有箭头连接开源协议之间是不兼容的，例如LGPL3.0和MPL1.1之间不兼容14，在整体软件中结合使用LGPL3.0和MPL1.1项下的开源软件会存在不兼容的风险。
对于企业开发的整体软件，应当将所有结合的开源软件进行梳理，整理出互相之间是否兼容的关系图；不兼容的开源软件不能够结合在一个整体软件中发布。
三、企业以二进制发布软件应注意问题
很多企业选择整体软件是以二进制进行发布，即不公开软件的源代码。在此情形下应当注意如下问题：
1、做好开源软件的管理
企业对于软件项目中使用到的所有开源软件要有详细记录，包括使用了哪些开源软件、在哪个模块中使用、使用了开源软件中的哪个具体的文件或库以及具体的文件路径；并保存好原始的开源软件包，以便查询，核实相关许可协议、版权声明文件、开源软件使用说明等，以便对使用到的开源代码进行管理。
2、保证开源软件的兼容性
首先，要保证开源软件包整体之间是相互兼容的。比如，有一些开源软件整个文件包都是按照单一的开源协议进行发布的，此时要保证这些软件包之间的开源协议兼容；其次，要保证使用到的开源软件中不同的子文件夹或子文件也是相同兼容的。比如，有一些开源软件包中含有多级目录，根目录下和子目录下均包含不同的开源协议副本以及不同的版权声明，在这种情况下，企业需要对开源软件的文件结构进行全面地了解，了解各级文件夹和文件之间的关系，不同的开源协议管辖的文件有哪些，以及它们之间是否兼容，是否可以结合使用等；最后，要保证整体软件使用到的所有开源软件之间是相互兼容的。企业应将整体软件中所使用到的每个开源软件包以及每个开源软件包中的子文件夹或子文件对应的开源协议进行统一整理，确保所有的开源代码对应的开源协议之间都互相兼容。
3、避免结合强著佐权型的开源软件
以二进制形式发布软件，强著佐权型的开源协议要求同时附随整体软件的全部的源代码。例如GPL3.0第6条规定，以目标代码形式发布包含GPL3.0开源协议的软件，需要满足如下条件之一：同时发布一份源代码，或者书面承诺三年之内提供相应的源代码；或者在指定的服务器上提供源代码。由于企业发布二进制形式的软件时，一般不希望同时提供相应的源代码，以便作为技术秘密保护，获取更多的商业价值。因此，企业如果仅发布二进制形式的软件不希望公开源代码时，需要特别注意不能在其中包含强著佐权型的开源软件，否则会构成违约或侵权。
4、弱著佐权型的开源软件需合规使用
发布含有弱著佐权型开源软件的二进制整体软件时，并不必然要求附随的整体软件的源代码。以LGPL2.1为例，根据其第6条的规定，如果企业的二进制的整体软件与LGPL2.1项下的开源软件采用共享库机制连接，则不需要再公开整体软件的源代码；但是，企业如果修改了LGPL2.1项下开源库，需要公开修改库的源代码，并需要对修改时间和内容进行声明。由此可知，对于含有弱著佐权型开源软件的整体软件进行发布时，应当注意两个问题：第一，整体软件和弱著佐权型的开源软件的连接方式要合规；第二，对于修改的弱著佐权型的开源软件要合规。
5、做好开源软件的版权声明和无保证声明
二进制形式发布软件，无论是包含弱著佐权型的开源软件还是商业友好型的开源软件均需要附带软件著作权人的版权声明和无保证声明，并且多数开源协议还需要附带一份开源协议副本。如果使用到了开源软件，而没有按照要求进行声明，会使企业面临侵犯著作权的风险。
结语
《中华人民共和国国民经济和社会发展第十四个五年规划和2035年远景目标纲要》中明确提出，要“支持数字技术开源社区等创新联合体发展，完善开源知识产权和法律体系，鼓励企业开放软件源代码、硬件设计和应用服务”。可以看出，当前我国为软件行业的发展营造了良好的政策和法律环境。鉴于开源软件对于企业创新发展的重要性，企业自身应加强对各类开源协议的理解和解读，积极进行开源软件的合规管理，以规避可能存在的法律风险。
注释：
[1] 开源协议的常见文件名为”LICENSE”,”COPYING”,”NOTICE”等，一般保存在开源软件包中。
[2] Jacobsen v. Katzer, 609 F.Supp.2d 925 (N.D.Cal.,2009).
[3] Artifex Software, Inc. v. Hancom, Inc., 2017 WL 4005508 (N.D.Cal., 2017).
[4] 李旭.开源软件的著作权保护研究[D].兰州大学.2019.
[5]潘亮.开源软件司法保护探析[J].电子知识产权.2022(6):50-56.
[6]参见广东省深圳市中级人民法院（2019）粤03民初3928号民事判决书、广州知识产权法院（2019）粤73知民初207号民事判决书。
[7]License Compatibility: Combining Open Source Licenses， https://www.mend.io/resources/blog/license-compatibility/，最后访问时间2022年9月25日.
[8]列出的均为一般情况，具体开源协议之间的兼容性需要根据协议具体条款确定。
[9]https://www.gnu.org/licenses/gpl-faq.html，最后访问时间2022年9月25日.
[10]GPL2.0的第6条规定再发布开源软件不能增加任何对于用户行使这些被授予权利的进一步限制。而GPL3.0的终止条款与GPL2.0的终止条款不同会被视为与GPL2.0第6条冲突。
[11]巫晓倩，夏芸.我国基础软件发展中的知识产权问题分析[J].电子知识产权，2009(7)：85-89.
[12]BSD共有三个版本的协议：BSD-4-Clause、BSD-3-Clause和BSD-2-Clause，此处指的是除BSD-4-Clause之外的BSD开源协议，由于BSD-4-Clause第3条的广告条款不符合GPL2.0的第6条，因此BSD-4-Clause和GPL2.0不兼容。
[13]关军.合理使用BSD许可的版权规则[J].中国版权，2012(6)：35-38+57.
[14]此处指它们在一个整体软件的同一个模块（同一个库）的情形，如果它们分属不同的模块（或库）则它们之间是兼容的。
