人人为我,我为人人:软件源代码开源协议合规问题初探|实务探讨

作者｜崔军、张宗浩

（一）开源协议的性质

20世纪80年代，美国麻省理工大学教授Richard Stallman发现，在软件领域，尤其是软件代码领域过分强调著作权保护，不利于技术的推广与传播。为此，他成立了自由软件基金（Free Software Foundation,以下简称FSF），与多位律师共同起草了第一版自由软件协议，并开始致力推广自由软件运动。不同于对著作权（Copyright）的保护，自由软件运动倡导在软件开发领域“人人为我，我为人人”的技术共享精神。为此，他们还创造了“著佐权”（Copyleft）的概念，以示对传统著作权保护方法的叛逆。然而，由于英文Free同时存在“自由”和“免费”两重含义，公众对于自由软件（Free Software）的概念自始存在理解分歧。为避免歧义，部分自由软件精神的倡导者将“自由软件”更名为“开源软件”（Open Source Software）。另一部分则在相关网站或协议中声明，“自由的是精神，而非金钱”。由于上述“自由软件”和“开源软件”在概念与内涵较为接近，部分从业者也将“自由软件”与“开源软件”统称为“自由开源软件”（Free and Open Source Software）[3]。

基于不同的应用场景和起草者对于“自由”、“开源”等概念的不同理解，实务中产生了不同的开源协议。据FSF统计，现阶段相对较为常见的开源许可证已多达九十余种。在具体适用中，据信70%以上的开源项目均使用了GPL协议。对相对简单的项目，FSF建议使用以Apache协议为代表的，表述更为简洁的协议。此外，北京大学、中国电子技术标准化研究院起草了木兰开源协议，在国内也有一定的适用度。目前GPL协议、Apache协议与木兰协议的最新版本分别为GPL V3、Apache 2.0和Mulan 2.0。需要指出的是，即使在上述同种协议内部，在后版本也不必然兼容前序版本。如，GPL协议起草机构FSF在GNU项目官网答疑部分对常见版本GPL协议之间的兼容性问题以表格形式进行了比较与说明，参考下表一[4]。实务中，应当结合具体开源协议的类型、版本和内容，进行更为细致的比对分析、选取适用。

对于开源协议的性质，在国内外学术与实务界是存在争议的。一种观点认为，开源协议的性质为授权许可协议（License）而非合同（Contract）。持该种观点的主要为部分美国学者与法官。在美国的合同法中，合同的成立要件除要约和承诺之外，还需要包括“约因/对价”（Consideration）,用以证明合同本身确实是双方经充分协商，达成的一致意思表示。不可协商、不可修改的格式许可协议显然不满足“充分协商下一致意思表示”的定义。另一种观点认为，开源协议不仅具有授权许可协议的性质，也具有合同的属性。持该种观点的学者普遍认为，开源协议除授权许可协议的性质之外，亦可视为著作权人与后续使用者之间达成关于合同的“通用一般条款”。著作权人与后续使用者如另有约定的，可以另行补充约定。因此，除法定情形外，开源协议具有合同效力。

广州知识产权法院在罗盒案中认定，开源协议，至少是GPL V3协议，具备合同的特征，属于广义合同的范畴，是非典型合同、格式合同。使用者对协议的承诺是通过行为作出的，也因此应受合同条款的约束。此外，广州知识产权法院还从政策的角度进行了补充分析与论证，认为“开源许可协议已经成为国际行业内公认的有效契约文本，遵守协议文本规定也是信守诚实信用原则的体现。只有各方均信守开源授权许可协议中的条款，才能让软件源代码持续开源传播下去，繁荣软件市场，保证公众能享受到开源软件带来的成果。”深圳市中级人民法院在(2019)粤03民初3928号民事判决书中也进行了类似的认定和论述。

简言之，现阶段我国的司法实务中，认定开源协议具有合同的属性。

（二）开源≠免费

实务中，我们发现用户对“开源”与“免费”之间的关系存在误解，认为所有可以公开下载的作品都属于免费作品。这种理解是片面的。

首先，“可以经公开渠道下载”与“免费”之间并不存在必然的对应关系。虽然Apache协议，木兰协议等均在协议文本中载明涉该开源协议作品的免费性，但这并不代表所有的开源作品都是免费的。或言，这不代表从所有渠道获得的所有开源作品都是免费的。如，GPL协议在前言部分写明：

“When we speak of free software, we are referring to freedom, not price.”

同时，GPL协议在第四条第二款对适用该协议时可以收费的情形进行了进一步的说明和举例：

“You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.”

Apache协议也在第九条对收费与否问题进行了补充规定：

“While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License.”

简言之，在GPL、Apache等协议框架下，“开源与否”和“免费与否”是两个不同的概念。这些协议所规定的“开源”仅意味着用户可以选择向外继续传播收到的作品，不论收费与否。

以GPL协议为例，如图一所示，我们假设用户甲从其他途径获得受GPL协议约束项目、程序、代码[5]的行为为A，用户甲依GPL协议向特定或不特定用户乙提供该作品或衍生作品的行为为B，其他用户乙向更多主体提供其从用户甲处收到作品的行为为C。按照GPL 协议的规定，即使用户甲不是该作品的著作权人，用户甲依然可以向用户乙收取费用，也可以以免费的方式向其他用户乙提供作品。GPL协议本身对过程B收费与否不做任何要求。同理，在过程C中，用户乙可以向用户丙收取费用，也可以选择以免费的方式继续传播，不受B过程的限制。

然而，依然如图一所示，假设用户甲对B过程进行收费，用户乙对C过程免费公开传播，丙是否有理由绕过乙，以付费的方式从甲处获取该开源作品？答案是肯定的。实务中存在如下四种选择付费的观点：

其一认为，虽然自由软件的精神倡导人人为我，我为人人，但在实际操作过程中，各程序员的水平参差不齐，工作习惯也千差万别。同时，受到时代和技术的局限，具体的程序和代码往往是存在运行错误或冲突（bug）的。这种现象在部分公开编辑、公开贡献的开源作品中更为明显。因此，在多数开源协议的默认条款中，均要求所有用户在继续传播作品时添加“无质量担保条款”（no warranty clause），即要求接收到该作品的其他特定或不特定用户自行承担修正错误与运行冲突（debug）的风险，并自行承担程序崩溃、误操作带来的其他风险。与之相对，如果允许一些有能力的公司或程序员以收费方式对开源项目发布debug后的修正版，并对特定付费用户提供相应的质量担保、保修甚至后续功能拓展，可以在鼓励技术发展与传播的同时，方便中小型企业或技术水平、时间精力有限的个人客户。

第二种观点认为，作品的传播本身是需要成本的，如，在自设服务器发布开源软件的过程中，会产生服务器租赁与维护成本。如果是自建网站的，可能还涉及ICP审核、网络安全等级备案等行政程序。技术的传播固然值得鼓励，但如果强制要求他人“赔本赚吆喝”，难免过于理想化。因此，应当至少允许用户在继续向外传播时收取少量费用，用以覆盖其在传播、推广技术过程中产生的合理开支。

第三种观点认为，在企业和个人使用过程中，对软件更新和功能拓展往往存在一定的期待。这种期待与时效密切相关，往往关系着用户后续对其他作品的开发。在图一的举例中，假设甲选择收费，乙选择免费，并为了尽快获得该受GPL约束的作品，丙依然有可能选择付费从甲处取得该作品。

第四种观点则更为理想化，认为对开源软件传播行为的收费不应具有强制性，但是可以比照维基百科等网站，允许后续用户本着自愿的原则，以“鼓励创作、支持推广”为由，向传播者、修改版的提供者等进行捐款。

总之，从以GPL协议为代表的部分开源协议的条文看，“开源与否”和“免费与否”之间并没有直接关联。需要补充提醒注意的是，部分开源协议起草机构在其官方网站上提供了协议的“参考译本”，并在协议中、译本提供页说明“译本仅供参考”。我们注意到，部分协议的中文参考译本在“开源”与“免费”问题上的翻译存在可以斟酌讨论的空间。

（三）开源≠必须向不特定主体公开提供

我们在实务中接触到了一种观点，认为“开源协议”从文义解释的角度，应当包含“向不特定主体公开提供”的意思。我们认为这种理解从技术的角度是理想化的，但从法律与相关协议的文本角度看是片面的。

以GPL协议为例，GPL协议第九条对这个问题进行了如下规定：

“You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. ”

GPL协议起草机构FSF在相关答疑部分#CompanyGPLCostsMoney词条下对此作出了更为清晰且直接的回答：

“The GPL does not require anyone to use the Internet for distribution. It also does not require anyone in particular to redistribute the program. And (outside of one special case), even if someone does decide to redistribute the program sometimes, the GPL doesn't say he has to distribute a copy to you in particular, or any other person in particular.

What the GPL requires is that he must have the freedom to distribute a copy to you if he wishes to. Once the copyright holder does distribute a copy of the program to someone, that someone can then redistribute the program to you, or to anyone else, as he sees fit.”

简言之，以图二为例：当乙从甲处获取受GPL协议约束的作品后，其可以选择向丙一传播该作品或衍生作品，但不向丙二、丙三传播，也可以选择向不特定多数人，包括但不限于丙一、丙二、丙三和甲传播该作品或衍生作品。但是，如乙选择不继续传播该作品，包括该作品的衍生作品，甲或者不特定公众丙一、丙二、丙三没有权利基于GPL协议向乙索要该作品。

Apache协议和木兰协议本身并未给出如FSF在GPL协议相关答疑中作出的答复那样清晰、明确、直接的回答。但是，从相关文本的内容看，Apache协议和木兰协议的起草者与GPL协议的起草者对于“传播权”的理解是一致的。如，Apache协议第四条规定：

“You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions. . .”

木兰协议第一条规定：

“每个“贡献者”根据“本许可证”授予您永久性的、全球性的、免费的、非独占的、不可撤销的版权许可，您可以复制、使用、修改、“分发”其“贡献”或“衍生作品”，不论修改与否。”

第四条规定：“您可以将您接收到的“贡献”或您的“衍生作品”以源程序形式或可执行形式重新“分发”……”

从文义解释的角度，“may”和“可以”表明该条款是授权性的规范，意味着权利人被合同赋予某项权利去做某事。但是，权利是可以放弃的，被授权做某事的潜在含义也包括被授权人可以选择放弃该权利。在关于“传播权”的讨论中，即用户享有不分发“贡献”、“作品”或衍生作品的自由。

综上，虽然我们可以将“人人为我，我为人人”作为开源社区中的某种理想化的自律道德义务，但从GPL、Apache和木兰等主流协议的文本角度看，并没有规定用户必须无条件参与作品分发、传播。

（一）开源协议规定其他的义务的识别

不同的开源协议规定的权利和义务也不尽相同，如在作品内附许可证原文、在头文件添加版权标识、提供源代码、标注修改的内容、授权商业使用、授权修改、授权专利许可、明确无质量担保、明确不提供商标许可等。中国信息通信研究院联合北京三快在线科技有限公司、华为软件技术有限公司、中兴通讯股份有限公司、甲骨文中国公司等公司于2020年12月发布《开源许可证兼容性指南》，在讨论开源协议之间兼容性问题的同时对部分主流协议的特征进行了比对和分析。此外，FSF官网[6]、开放源码促进会（Open Source Initiative，简称“OSI”）[7]等网站均对各主流开源协议进行了比对和综述。在实务中应该结合个案具体归纳与识别。

（二）违反开源协议的后果

我们在接受咨询或对企业进行知识产权专项尽职调查的过程中发现，部分开发人员对违反开源协议一事抱着不以为然的态度，或对此有侥幸心理，认为从Github、CSDN或其他渠道扒取部分作品的行为不会被发现，即使被发现了也不会产生严重后果。这种认识是片面的。

诚然，在实务中，权利人往往不会选择对网上浩如烟海的作品进行分析、分解、拆包并比对代码，这在时间与经济两方面都是得不偿失的。但是，对于相对成功、规模较大的企业所研发的作品而言，不论是权利人还是“友商”，均有足够的动机对其进行分析、分解、拆包、比对。在罗盒案中，原告委托的司法鉴定所对送检作品源码及被控侵权作品反编译后得到的源码进行了比对，在424个可比代码中，认定其中165个可比代码具有高度相似性，17个可比代码具有一般相似性，239个可比代码具有实质相似性，有3个可比代码不具有相似性。法院据此，结合其他证据，认定了被控侵权产品使用原告作品代码的事实。

从技术与代码比对司法鉴定实务的角度看，因为各作品的开发环境、开发语言、具体功能不同，比对标准也因此具有灵活性。如，在一些鉴定机构或鉴定工具的比对过程中，将最小比对单元设定为“行”，认为在编程过程中使用特定结构，特别是少于特定行数，达到某种技术目的表述或表达可能属于行业内的惯常操作，本身因落入公共领域而不具有可保护性。但如果连续雷同超过一定的行数，可能涉嫌侵权。然而，在js、html、zml、xml等文件的开发过程中，换行并非开发中必备的操作。因此司法鉴定机构在对代码进行比对时，不仅会考虑“行”的比对，还会比对反编译得到的二进制机器码、开发环境与作品的对应关系，如.java和.jav-svn-base之间的对应关系，源代码中的时间戳、签名信息、注释信息、字符串信息等。此外，部分鉴定机构还会在实际比对之前，对检材进行重新划分、拆分、重组，防止潜在的侵权人通过简单的重命名、删注释等方法，规避检测、逃避责任。

关于违反开源协议的法律救济，主要存在违约和侵权两种救济途径。一般而言，主张违约责任的守约方的法律救济措施主要包括继续履行和损害赔偿，主张侵权责任的受害人的法律救济措施除包括停止侵害、损害赔偿、恢复原状等。此外，在侵权案件中，当事人还可以向法院申请临时禁令。二者竞合时，当事人有权决定使用哪种救济。在罗盒案中，原告提起了侵权之诉。法院判决被告停止通过互联网提供含有侵权功能源代码软件的下载、安装和运营服务，并向原告赔偿损失及合理开共50万元。

实务中，很多违反开源协议的纠纷中的侵权人为规模较大的公司，被控侵权产品通常是被告的核心产品。对于这些公司而言，如果爆发与该产品相关的负面舆情，或因各种原因导致产品下架，所造成的损失、产生的后果可能会对企业造成较为严重的打击。因此，在部分案件中，侵权主体最终被迫接受支付高额和解费用，以换取原告撤诉或权利人的授权。

（三）企业在开源协议合规内部审查中应注意的问题

1.对开源协议的审查应当回归文义

我们在实务中接触到一种现象，部分企业经营者，尤其是部分非技术出身、了解过罗盒案的企业经营者，对开源协议、开源项目畏之如虎，甚至要求研发部门“硬核100%原创”，不能接触、借鉴、使用任何来源于第三方的开发代码甚至开发思路。这种想法是理想化的。根据艾瑞咨询于2022年2月发布的《中国开源软件产业研究报告》，截至2021年，我国在Github上的注册用户已超过755万人，约92%的中国软件开发者使用过开源软件，且开源软件对我国企业的渗透率已超过88%。该报告还显示，从企业经营的角度看，企业使用开源软件可以从需求、设计、构建、测试、实施五个方面为企业节省约38%的直接开发成本。国内以阿里、腾讯、华为、中兴、美团等为代表的企业也都或多或少地参与了开源环境、开源软件和开源协议的使用与建设[9]。与之相对，部分技术出身的企业经营者、企业研发部门则在与我们的交流过程中，表示闭门造车不具有可行性，希望我们提供内审建议。

如上所述，不同类型的开源协议约定的权利义务并不相同，部分作者，尤其是部分厂商出于推广产品的商业考量，往往以不同的授权协议发布相同或极为类似的作品。用户在使用的过程中，应当仔细甄别，透过作品内的协议文本、头文件注释等信息，识别该作品所适用的开源协议，并仔细检索、比对其文本，查明与标准文本是否有出入。如有，应继续研究是否属于协议允许的增改事项、例外情形等。

对开源协议的解读，应以开源协议规定的作准文本为基础，以起草机构的官方答疑为参照，综合所属法域相关法律、相关判例进行具体分析。对于协议文本中不清晰、不明确的条款，可以考虑运用体系思维，参考同种协议的先前版本、后续版本，或类似但不同种协议中对于该条款的解释和说明。为方便阅读和理解，如果该协议的作准文本不是中文的，还可以参考相关协议官网上的公布的“非官方译本”，但应注意其翻译的准确性，及与作准文本之间可能存在的冲突。

举例而言，在GPL协议中，对于“传播”行为选用了多个不同的单词进行具体表达，如convey, distribute, redistribute, propagate, transfer等。然而，convey一词似乎在同类型的开源协议中出现不多，甚至在GPL协议的前序版本中也很少出现。从法律英语的文义解释角度看，该词多出现在财产交易权属流转过程中，意指财产转让，且在美国的法律英语环境下，多指不动产的转让。GPL协议本身在第0条定义部分对该词作如下解释：

“To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.”

GPL协议在相同条文中将convey与propagate作了区分，对propagate定义如下：

“To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.”

必须承认的是，不论convey还是propagate对于非法律专业的读者而言可能都比较陌生。在GPL V2协议中，起草者针对这类向外公开传播、分发的行为统一概括为distribute。GPL协议的起草机构FSF在答疑部分对此进行了进一步解释与说明：

“Q：Is “convey” in GPLv3 the same thing as what GPLv2 means by “distribute”? (#ConveyVsDistribute)

A: Yes, more or less. During the course of enforcing GPLv2, we learned that some jurisdictions used the word “distribute” in their own copyright laws, but gave it different meanings. We invented a new term to make our intent clear and avoid any problems that could be caused by these differences.”

可见，起草者在起草GPL协议时，并未完全按照英语或法律英语中的常见表述，而是为合同目的，对相关词汇进行了重新的定义。因此，对convey一词在GPL协议中的适用场景应基于GPL协议中的定义和解释，确有必要时，可以参考GPL V2协议中对distribute一词适用场景的描述，但绝不能脱离GPL协议文本本身，仅考虑该词的常见含义。

2.应健全日常合规机制

开源数据合规问题属于软件开发、运维过程中需要持续面对的问题。我们不能期待每一位开发者在作为技术专家的同时，也是法律专家、合规专家。同时，考虑到开发者的工作习惯和相关行业的文化，结合企业发展的实际，我们也不能期待所有的开发者在开发所有作品的过程中保持完全自研，或者说，闭门造车。因此，对开发者的合规培训、对作品的合规审查应该贯彻企业发展、作品开发的全过程。

首先，企业应当建立一套针对开源数据合规的管理机制，包括如何报告、如何评判、如何确定使用开源作品的条件，以及作出是否使用、如何使用的决策等。在此过程中，企业需要识别使用开源作品的具体种类，相关开源协议的具体要求等信息，从技术、法律和商业规划等角度进行综合权衡，选取最适合的许可类型，并按照实际需求对相关风险点进行规避。

同时，企业应定期对已经开发的代码、软件进行监控、审计，确定其中是否存在涉开源协议、尤其是不符合企业发展规划的开源协议等。需要特别注意的是，即使是针对同一开源作品的不同版本，著作权人也有可能在升级的同时更改授权协议的属性。一般而言，这种更改不具有溯及力。但是，一旦接受了升级，一般默认下游使用者接受了新的开源协议。而新的授权协议可能带来传染性、兼容性等方面的问题。因此，企业有必要建立对现有代码、数据、软件常态监控，定期审计的机制，防患于未然。

3.应建立纠纷应对与解决机制

我们在接受合规咨询的时候多次遇到这样的问题：“是不是建立了企业合规机制，或签订了规范的合同，就可以保证软件作品不被第三方平台下架，同时免除所有被诉风险？”我们认为，这些企业已经具有了初步的合规意识，但对于法律运行、法律与业务的衔接缺乏了解，对实务中的纠纷应对与解决缺乏预期。

对于商主体而言，是否起诉，是否被诉，是否可以胜诉，是否需要上诉和胜诉后如何执行、可以执行到什么程度，均属于不同的问题。所谓“合规不起诉”，仅指检察机关对于涉嫌实施犯罪并作出认罪认罚的企业，在其承诺实施有效合规管理体系的前提下，对其作出不起诉决定的制度，并非指企业可以因合规而免于所有刑事、行政和民事诉讼，免除所有刑事、民事和行政责任。

关于软件作品是否会被第三方平台下架问题，我国在网络平台第三方侵权连带责任的问题上适用通知删除规则。一般而言，如果权利人的通知构成有效通知，则平台方应履行删除义务，否则可能需就结果承担责任。相应的，如果网络用户、平台内经营者、平台服务对象认为不侵权的，可以向平台进行反通知，即通过声明和初步举证、提交律师《法律意见书》等方式，论证为何不构成侵权。实务中，由于通知-反通知之间间隔时间通常较短，网络用户、平台内经营者、平台服务对象经常难以系统地进行取证、事实分析和法律论证。因此，也常采用“不侵权申明”加保函或财产担保的方法向平台方进行反通知，承诺如果出现诉讼，承担全部责任。需要说明的是，对于平台接到反通知之后是否需要立即恢复上线，《民法典》、《电子商务法》和《信息网络传播权保护条例》中规定的表述并不完全一致。实践中，平台方也可能基于“商业考量”，从风险规避的角度出发，决定对某特定APP进行下架，并在收到反通知后决定不立即重新上架。

从解决实际问题的角度看，企业在开发-监控-审计及纠纷解决的全过程中，应建立健全技术部门和法律部门之间充分协调、协商的机制。由于知识产权纠纷普遍具有高度专业性，很多情况下企业法律部门，甚至外聘知产律师对具体的技术细节都不甚了了，一知半解。同时，受限于时间、精力、经历等因素，企业法律部门和外聘律师也不可能脱离技术人员，对技术人员的每一段代码、每一项工作进行穷举式的分析和识别。相应的，相关技术部门对法律问题的认识可能缺乏体系性或存在误区。因此，需要技术部门与法律部门紧密合作，对具体问题进行分析，确定使用了哪种协议，应当履行哪些义务等具体问题。企业法律部门和外聘律师也需要在明确事实的前提下，结合相关法域内的最新判例，充分利用法律武器，维护企业的合法权益。

我国“十四五”规划提到，要“完善开源知识产权和法律体系，鼓励企业开放软件源代码、硬件设计和应用服务”。从企业发展实际看，开源协议既不是阻碍企业正常发展的拦路虎，也不是鼓动企业进入蛮荒之地的通行证。企业和开发者应将开源协议视为与著作权人协议的一部分，在合法、合规的前提下，完善企业管理与争议解决流程，尊重开源协议中的开放、共享、平等、协作精神，让开源协议成为企业发展的推手和动力。