开源软件二次开发者权利边界的探讨

摘要

根据《2023中国开源发展蓝皮书》，中国开源软件开发者突破800万，居全球第二；在日常的开发过程中，96%的开发者正在使用开源软件[1]。但是，与开源软件有关的法律制度却在很长时间里一直处于“缺位”状态，导致在相当一部分软件开发者的认知中，开源协议仅仅是乌托邦式的“君子协议”。在与开源软件有关的法律争议中，二次开发者的“权利边界”究竟应当如何界定，是一个成熟的开源社区应当确立的核心规则之一。本文结合我国法院的最新判例，以这一问题为圆心充分展开，对与之关联的若干问题进行论述，并结合开源模式的特点，进一步提出对我国开源社区规则建立的设想与展望。

关键词

开源软件 二次开发 衍生作品 GPL 开放许可

近年来在我国科技界，“开源”一词被提及的频率越来越高，作为当今涉及软件的科技型企业主流的研发模式，开源模式能够有效减少企业无谓的投入。相较于传统的闭源模式，程序员在编写程序前，通常会先在开源社区检索可以实现相应功能的软件模块，若有合适的模块，则可直接取用，避免了重复劳动带来的社会总生产力的浪费。在2017年《国务院关于深化“互联网+先进制造业”发展工业互联网的指导意见》中，国务院明确要求：“面向关键技术和平台需求，支持建设一批能够融入国际化发展的开源社区，提供良好开发环境，共享开源技术、代码和开发工具”、“构建应用生态。支持平台企业面向不同行业智能化转型需求，通过开放平台功能与数据、提供开发环境与工具等方式，广泛汇聚第三方应用开发者，形成集体开发、合作创新、对等评估的研发机制。支持通过举办开发者大会、应用创新竞赛、专业培训及参与国际开源项目等方式，不断提升开发者的应用创新能力，形成良性互动的发展模式”[2]，由此可见，开源软件与当前新质生产力的发展息息相关，特别是人工智能等一系列基于算法的、能够对制造业起到重大革新作用的技术领域，更加离不开开源软件以及围绕开源软件所形成的开源社区、开源生态链。

但是，天下没有免费的午餐，不同的开源软件，对应了不同类型的开源许可证。在当前主流的开源许可证中，总体又可分为Strong Copyleft（强著佐权）、Weak Copyleft（弱著佐权）、Permissive（宽松）三种类型[3]。Permissive型许可证对于使用者的约束相对较少，因此法律上的争议并不多；而对于Strong Copyleft与Weak Copyleft型许可证而言，二次开发者在自由使用、复制、分发时，都负有强制开源的义务，只不过是不同许可证之间，强制开源条款触发的严苛程度不同，但无论怎样，这势必会与很多二次开发者的最终利益相冲突，各方对于开源协议的理解又存在较大分歧，因此产生了较多争议。

在Copyleft型许可证中，又以GPL（General Public License）凭借其极强的“传染性”最为知名。所谓“传染性”，是指开源许可证中强制开源条款的严苛程度，条款越严苛，“传染性”越强。以GPL 2.0版本协议（以下简称“GPLv2”）为例，其在第2条中明确规定，若在受到GPLv2约束的源代码基础上进行修改，除非修改部分可以被合理地看作“独立（independent）作品”和“分离（separate）作品”（以下合并简称为“独立且分离”），否则修改后的整体作品都应当受到本许可证的约束，即应当被强制开源[4]。换言之，若要在受到GPLv2约束的开源代码基础上进行二次开发，二次开发者除非能够证明其独立开发的部分符合“独立且分离”的条件，否则就应当开源；在无法达到上述条件的情况下，二次开发的部分就像受到“传染”一样，成了“应开源”的源代码。据此，若有其他主体在二次开发后的源代码基础上进一步开发，那么进一步开发的内容同样存在被“传染”的可能。在这样的规则之下，部分二次开发者为了避免自己开发的源代码公开或为了阻断“传染”，选择直接闭源，进而引发一系列法律纠纷。近年来，我国法院以判例的形式，逐渐形成了初步的开源规则，但即便如此，这些已经生效的判决反而激发了法律界、技术界更加热烈的争论，这也从侧面反映了这一问题的敏感性。

一、针锋相对：“用而不说”的权利人，责任几何？

近年来，我国涉及GPL相关争议的判例数量并不多，特别是如果把争议焦点限定为“二次开发者在闭源的情况下，被控侵权人主张‘开源抗辩’能否获得支持”，至本文完成时，在公开渠道能够查询到、且判决说理部分正面进行系统性回应的生效案例仅有两件，分别为南京中院一审判决并生效的（2021）苏01民初3299号案（以下简称“3299号案”或“3299号判决”），以及苏州中院一审、最高法院二审的（2021）最高法知民终51号案（以下简称“51号案”或“51号判决”）。这两件案例的基本事实存在部分相似之处，都是权利人在他人基于GPLv2发布代码基础上进行了一定程度的二次开发，形成了新的衍生作品，但并未将二次开发后形成的整体作品进行开源，被控侵权人据此主张权利人存在不当行为，认为不应当对权利人的权利基础给予保护。

（一）价值争议：维护规则vs严格保护

对上述争议焦点，3299号判决认为，原告自身首先应当规范使用开源代码，遵守开源协议，并证明自身权利的正当和合法，否则即会导致一个不当、不法的行为人指责另一个实施相同行为的不当、不法行为人的逻辑怪圏；法院如果基于原告的该权利认定其他行为人构成计算机软件侵权，即会保护权利人的不当行为带来的利益，势必赋于其特殊法律地位和特别商事利益，不符合公平、诚信原则。而51号判决则认为，即便假定权利人因违反GPLv2协议导致涉案软件存在权利瑕疵，该假定瑕疵亦不影响其针对被诉行为寻求侵权救济；在软件尚未被开源、该软件著作权人认为其软件不受GPLv2协议约束、被诉侵权人则依据GPLv2协议提出不侵权抗辩的侵权纠纷中，软件开发者自身是否违反GPLv2协议和是否享有软件著作权，是相对独立的两个法律问题，二者不宜混为一谈，以免不合理地剥夺或限制软件开发者基于其独创性贡献依法享有的著作权。

从两案法院说理的逻辑来看，二者均考虑到了对开源生态的保护以及利益平衡，差异主要体现在价值层面。3299号判决侧重于尊重并维护开源规则，强调权利人首先应当确保自身行为的合规，特别是在我国，相当一部分软件从业者对开源规则仍然处于较为粗浅的认知，应当通过一剂“猛药”唤醒从业者对规则的敬畏。51号判决则侧重于知识产权的保护以及开源相关方利益的平衡，在多个价值之间可能发生冲突的情况下，“保护知识产权”仍然处于更高的位阶。但由于51号判决是由最高人民法院作出，并且已经入选了人民法院案例库，而直到本文完成之日，3299号判决尚未入选人民法院案例库。因此可以预见的是，至少在今后很长一段时间内，51号判决的裁判要旨将会被更多法院所采用。

（二）质疑之声：“传染情况”究竟能否查明

然而，在51号判决作出后，业内仍有一些质疑，主要是针对该案的权利人“究竟是否违反了GPLv2协议”这一事实，最高法院以开源代码权利人并非本案当事人、相关事实无法查清为由，没有进行相关事实的查明，仅仅记载了权利人单方声称“在底层系统软件与上层功能软件之间采用套接字（socket）与命令行（command line）等技术手段建立了隔离层，且二者之间通信内容不涉及内部数据结构信息，由此使得上层功能软件构成GPLv2协议项下‘独立且分离的’的程序”。而作为对比，法院在3299号案中深入调查后，认定权利人实际是将包含GPL开源代码的文件与二次开发的源代码文件共同编译成一个dll文件，并最终认定权利人二次开发的源代码受到了GPL协议的传染。二者相比之下，若开源代码原始权利人并非案件当事人，对于查明二次开发的源代码是否构成“独立软件”这件事，似乎并不是“无从下手”[5]；部分业内人士也提出，如果51号案所涉二次开发的源代码并不能构成独立软件，也即受到了GPL的“传染”，那么本案查明的事实就存在瑕疵[6]。

笔者本人作为51号案一审、二审阶段权利人的代理人，从接受委托之初，就深知这一问题很可能成为重大争议焦点，因此在代理过程中，始终都为法院调查“权利人二次开发的源代码究竟是否属于独立软件”这件事做好了准备。事实上，针对该争议，GNU官方网站以Q&A的方式进行过有如下回复：“……究竟怎么区分是两个独立的程序，还是一个程序的两个部分呢？这是一个法律命题，最终会由法官来决定。我们相信合理的标准既依赖于通信的机制（exec、pipes、rpc、共享地址空间的函数调用，等等），也依赖于通信的语义（交换了什么样的信息）。如果两个模块都包含在同一个可执行文件里，那么它们一定是一个程序的组件。如果两个模块运行时是在共享地址空间连接在一起的，那么它们几乎也构成一个组合软件。反过来，pipes、sockets和命令行参数通常都是两个不同程序通信的机制。因此，如果使用它们来通信，这些模块正常应该是独立的程序。但是如果通信的语义非常密切，交换复杂的内部数据结构，那么它们也被会认为是一个大程序的两个组合部分”[7]。从这一官方回答可以看出，若二次开发的部分采用pipes、sockets（即51号判决中的“套接字”）和命令行参数（即51号判决中的“command line”）、且通信的语义达不到“密切、复杂”的程度时，应当认为该部分符合GPLv2协议中“独立且分离”的要求，可以不进行开源。由此可见，关于“独立软件”的争议，是存在一定的判断标准的，只不过从上述官方文字的表述来看，通信语义是否达到“密切、复杂”的标准，存在一定的主观性；同时，也有业内人士认为，上述标准也不宜作为唯一的判断标准，更不应当简单地将其与整个软件行业惯例画上等号，因为部分开源社区权威技术专家的观点很明显存在倾向性[8]。

（三）分发对象：被忽略的角落

51号案的具体案情，是离职员工将原单位的源代码带至新单位复制、使用的“传统桥段”，而且在被诉侵权的源代码中还发现了权利人特有的标记，这一事实已经坐实了被控侵权人获取权利人源代码的手段是不正当的，同时，被控侵权人自己的类似产品推向市场后，同样没有进行开源。这和“被控侵权人通过开源社区合法获取权利人源代码，并在二次开发后闭源”的情况是不同的，这也延伸出另一个值得探讨的话题：GPL代码的“分发（distribute）对象”，究竟是不特定社会公众、还是通过合法途径取得产品的购买者？按照GPLv2的原文，其第3条b项使用了“to give any third party”的措辞。笔者曾就这一问题询问了不同背景的相关人士，发现一个有意思的现象：法律界人士更有概率倾向于将分发对象理解为不特定社会公众，也即应当以公开发布的方式进行公开；而软件从业者则更有概率倾向于将分发对象理解为产品的购买者，也即只有购买者才有权获得一份源代码副本。

笔者认为，对此类案件中“分发对象”进行界定的意义在于，如果被控侵权人并非权利人的分发对象，那么其自然不享有基于GPL协议所带来的豁免可能。事实上，在51号案的代理过程中，笔者将这一意见向最高法院明确提出，并举了一个例子：慈善机构派发物资，领取者需要进行登记、排队后，才能领取到物资；而如果有人绕开这些程序，直接以撬开慈善机构仓库大门的方式获取物资，该行为很显然不能给予正面评价，更不能因为物资本身具有公益性质，就对这种不正当获取的方式予以豁免。不过最高法院在51号案的说理部分并未对此进行回应，可能是因为51号案既然已经决定对权利人是否违反开源协议的问题不予考虑，那么在此情形下讨论“分发对象”的问题，实无必要。但笔者仍然期待在今后的其他类似案件中，能够有法院对这一问题进行说理回应。

（四）小结

总体而言，51号案回避查明“独立软件”的做法虽引发了一些争议，但无论是法律界还是软件界，对于该案实体上的处理结果，基本都是持肯定态度。在有确凿证据证明被控侵权人采用不正当手段获取了权利人的源代码的情况下，如果在实体判决上不支持权利人，则将造成明显不公，并且会纵容类似的侵权行为。也正因为此，3329号案仅保护了权利人未受GPL传染的预览程序的做法，同样也引发了不小的争议。由此可见，无论是51号案还是3329号案，都注定了无法让所有人满意，最终仍会回归价值位阶高低的判断上。

二、雏形初显：三块重要的“判例拼图”

对于法律界、软件界从业者而言，无论是认同3329号案“维护规则”的理念，还是支持51号案“严格保护”的做法，“在中国建立科学、合理的开源规则”应当是所有人追求的目标，这也高度契合新质生产力发展的要求。笔者认为，与其沉迷于争论3329号案与51号案哪个的价值位阶更高，不如去思考“中国究竟需要怎样的开源规则”。虽然目前尚无政策法规层面的官方文件对我国的开源社区规则进行细化，但通过近年来由最高法院判决或认可的若干案例，能够窥得一些基本规则，如同数学中的“公理”一样，已经被悄然布局。除了前述51号案以外，还包括广州知识产权法院一审判决并生效的（2019）粤73知民初207号案（以下简称“207号案”或“207号判决”），以及深圳中院一审、最高法院二审的（2021）最高法知民终2063号案（以下简称“2063号案”或“2063号判决”），这三块“判例拼图”，基本可以组合出当前我国开源规则的雏形。

（一）全面认可GPL协议的合同性质——207号案

在我国涉及开源软件的诉讼史上，207号案有着举足轻重的地位，因为这是我国法院首次正面对GPL协议进行详细解析，为其“正名”。虽然在207号案之前，还有“数字天堂v.柚子”案[9]、“不乱买v.闪亮时尚”案[10]也涉及对GPL协议的相关说理，但都是浅尝辄止；207号案则是在说理部分详细阐述了开源运动诞生的历史、发展历程、域外实践经验及判例，并对该案涉及的GPL3.0（以下简称“GPLv3”）协议在中国法律框架下的性质进行了分析，最终认为GPL协议属于广义的合同范畴，是一种“授权方和用户订立的格式化著作权协议”。该案认定，权利人软件和被控侵权软件中涉被诉部分源代码、即“沙盒分身功能”部分源代码构成相似，而权利人软件是基于GPLv3协议发布并履行了开源义务，被控侵权人并未将自己的软件开源，构成对GPLv3协议的违反。此时，被控侵权人不再享有权利人的许可，在权利人可以在“侵权责任”与“违约责任”中二选一的情况下，经法院释明，权利人明确主张被控侵权人构成无权使用，应承担侵权责任。

207号案对GPL协议中所述的开源规则的全面认可，确立了我国开源规则的最重要的一条“公理”，即从法律上认可GPL协议属于合同，受我国法律调整。该案虽未经历二审，不过其随后入选了2021年中国十大知识产权典型案例，意味着该案得到了最高法院的认可。在此之后，“开源合规”应当逐渐成为软件开发企业必须要重视的法律风险。不过，207号案的被控侵权人曾经提出，涉案开源项目的贡献者多达32人，因此权利人的软件作品属于不可分割的合作作品，权利人无权单独以自己名义提起诉讼；法院最终是以“项目管理人（即该案权利人）提交的代码量占整个涉案软件代码量的绝大部分，因此其他贡献者提交的代码并未对涉案软件著作权产生实质影响”为由，对被控侵权人的这一观点不予支持。但是，实践中大量的开源项目里，除项目管理人以外的其他贡献者提交的代码对最终的软件作品产生实质影响的例子并不在少数，因此207案对这一问题的观点并不具有普适性，有待其他“判例拼图”予以完善。

（二）全面认可开源项目管理人的独立诉权——2063号案

2063号案与207号案的权利人相同，但被控侵权人是其他主体；而207号案中法院未能解决的问题，在2063号案中得到了系统性解决。2063号案中，被控侵权人同样提出，除了权利人（即项目管理人）以外，涉案软件还有多达34个贡献者，而没有任何证据证明这34个贡献者都将著作权转让给权利人行使，因此权利人无权提起诉讼。针对这一观点，最高法院在二审判决书中首先承接了207号案的裁判意见，即没有证据证明其他贡献者提交的代码对最终软件作品产生实质影响，但随后又作了非常重要的“退一步而言”说理：“对于开源软件而言，往往难以界定全部著作权人，只要该项目保持开源，则贡献者数量会持续动态增加，这意味着开源程序始终处于动态的未完成状态，而这将对权利人范围的确定造成极大的阻碍，若要求必须经过所有贡献者的授权才能提起诉讼，将导致开源软件维权无从谈起”，在此基础上，最高法院进一步指出：“根据开源软件项目管理人的上传开源代码并创建主分支，贡献者针对开源软件提交代码的发起拉取申请并经项目管理者同意后并入主分支等一系列约定内容及行为表现来看，贡献者针对开源软件提交代码并发起拉取申请应视为其默示同意作为普通被许可人的项目管理人提起侵权之诉，针对有关的被诉侵权行为可以一并认定并判赔。贡献者乃至在先代码著作权人若对涉案软件的著作权归属或权益分配存在争议，可另行向项目管理人主张”。至此，开源项目管理人的独立诉权问题得到了最高法院的系统性回应，2063号案后续亦入选了人民法院案例库，成为正式的裁判标准。

2063号案的积极意义在于，法院降低了开源软件著作权人维权的门槛，“激活”了开源软件著作权人维权的可行性，调动了权利人针对违反开源协议行为维权的积极性。不过，也有业内学者认为，贡献者在完成分支创作后向项目管理人发起“拉取申请”的行为，是否真的可以视为“默示同意作为普通被许可人的项目管理人提起侵权之诉”，关于这一点值得商榷，特别这种做法是否会导致其他主要贡献者丧失了依据自己具有独创性的表达部分起诉的权利，是否会构成权利人滥用权利的情形[11]，目前仍然存疑。不过笔者认为，这仍然是一个价值取舍的问题，在中国目前仍在探索构建科学、合理的开源规则的时候，2063号案作为另一块重要的“判例拼图”，填补了207号案的空白，其积极意义是大于上述担忧的。

（三）明确二次开发者的权利边界——51号案

承前所述，51号案目前已经被收录于人民法院案例库，其裁判要旨在案例库中被上位化概括为：“在侵害计算机软件著作权案件中，涉案软件开发者是否未尽开源义务和是否基于其独创性贡献享有涉案软件著作权并不必然相关。被诉侵权人仅以涉案软件开发者并未依据开源协议开源为由，抗辩其不侵害涉案软件著作权的，人民法院一般不予支持”。而该案引发业内争议，主要是法院的这种做法似乎存在“纵容”二次开发者不遵守开源规则的嫌疑，但如果将51号案与2063号案结合起来看，可以看出，二者存在“互补”的关系，即：二次开发者虽然在向“后手”侵权人主张侵权责任时，法院可以不用考虑二次开发者是否违反了开源协议，但是其“前手”权利人的维权门槛同样被降低，此时二次开发者将会面临“螳螂捕蝉、黄雀在后”的境况。更进一步讲，51号案与2063号案合力作用下，会使二次开发者面临一种博弈：究竟是否要用自己的违约/侵权风险，来换取源代码闭源带来的商业价值以及未来针对侵权人的维权机会？从目前的情况来看，前者的风险与后者的利益似乎有所失衡，但是2063号案已经开了一个头，后续应当会有更多的案例，为前者的风险“加码”，最终实现平衡。

至此，51号案成为了我国开源规则雏形中又一块重要的“判例拼图”，其与207号案、2063号案相互补充，使得开源生态中权利人（包括项目管理人与贡献者）、二次开发者、社会公众之间错综复杂的利益关系存在平衡的可能性。从更深层次的意义上说，开源协议本身并不是“纯白无瑕”的，其也会受到政治、资本的干扰，进而背离“开放、共享、自由”的初衷（本文第三章节详述）。企业违反开源协议，有时也并不必然等同于传统民事纠纷中行为人违反诚实信用原则、导致与社会传统道德观念相悖的行为，更多地只是一种冷冰冰的、商业上的博弈与决策，难以用简单的“对”与“错”来评价。因此，二次开发者究竟如何在博弈中取舍，开源也好、闭源也罢，最终都是站在自身利益最大化的角度作出的商业决定，而对于商业决定，是否适合由法院代企业作出？也许，这才是51号案与3299号案在价值层面最大的区别。

三、远方的乌云：自由外衣之下的阴影

笔者在代理51号案的过程中，始终有一点难以释怀，那就是该案权利人之所以最初选择GPL开源代码，是因为彼时受限于我国相关技术领域的能力不足，使得权利人对硬件、软件框架的选择范围极窄，而终端产品的特性又决定了不可能开源，一旦开源，将会给终端使用者带来重大安全隐患。在此情形下，权利人选择采用“隔离+闭源”的方式来开发产品，采用GNU官方认可的套接字（socket）与命令行（command line）等技术手段，在GPL开源代码与二次开发代码之间建立隔离层，并在此基础上闭源。即使这样，权利人在维权过程中，仍然需要随时做好“自证清白”的准备。在意识到这一点时，笔者已经隐隐感觉到，“开源”实际是一把双刃剑，虽然有着“开放、共享、自由”的美好愿景，但极易被规则制定者所利用，实现对使用者的控制。

（一）被架空的“自由”：垄断与地缘政治的裹挟

当前，已经有学者撰文指出，传统开源领域“知识共享”的理念因许可证中知识产权政策要求逐渐转变为“知识控制”的资本思维，将源代码开放至公共领域的做法业已成为资本控制的另一种方式[12]。举例而言，中美贸易战爆发后，美国HashiCorp公司宣布，因出口管制的原因，禁止在中国使用其开源软件VAULT企业版[13]；俄乌冲突爆发后，全球最大的开源代码托管平台Github更是封禁、屏蔽了大量受美国制裁的俄罗斯开发者账户[14]。可以预见的是，在当前波云诡谲的国际形势下，若中国的软件企业过于依赖国外的开源资源与平台，未来完全可能在一夜之间失去所有权利基础，甚至可能被要求将二次开发的全部成果强制开源。

另一方面，开源协议所形成的“知识控制”势必会导致强势企业进一步掌握绝对的话语权。以本文第一章节述及的“独立软件”的判断标准为例，即使是GNU在官网的答复，依旧是将最终的判断“踢”给了法院，而法院却大概率又会以GNU官方的答复作为重要依据，例如51号判决的说理部分就有“关于涉案软件是否受GPLv2协议约束，该问题涉及底层系统软件是否受GPLv2协议约束、上层功能软件是否构成GPLv2协议项下‘独立且分离的程序’、二者间采用的隔离技术手段、通信方式、通信内容等如何界定以及软件领域对GPLv2协议传导性的通常理解与行业惯例等因素”一类的表述，实际仍然是主要参照了上述GNU的官方答复，而且特别提到了“通常理解”与“行业惯例”这两个因素。而根据笔者本人对一定数量的软件从业人员走访的结果看，大部分从业者对于业内“大厂”单方提出的判断标准通常有较高的接受度，甚至不自觉地将“大厂”的标准看作默认标准。但对于业内“大厂”而言，其自行制定的标准是否客观、公允，亦难以有定论。若这样的趋势不加以控制，此消彼长之下，“开源运动”完全可能被少数寡头把持话语权，最终形成垄断；而这种垄断若结合前文提及的政治因素，势必引发更大的危机。

（二）批量维权：“钓鱼”造就虚假的“百花齐放”

近年来，由于开源模式的普及，使得软件开发的成本明显降低，因此出现了一些公司通过开源模式快速形成权利基础，并以此维权获利的情况，从表面上看，相关诉讼案件的数量大幅增加，似乎表明开源模式正在我国“百花齐放”。然而拨开现象看本质，却并非如此。在维权过程中，这些公司采用的一些手段引发了争议。

例如，据报道[15]，在涉及Qt开源软件的维权过程中，维权代理机构声称如果不遵循开源协议，又不购买商业版，可能导致使用开源软件开发的软件丧失相关知识产权权利；此种表述主要是基于3299号案的裁判观点，企业在收到相关侵权警告函时，势必会陷入焦虑。再如，某公司宣称其自助建网软件可免费下载使用，然而近年来，该公司却在全国范围内对使用他们自助建网软件的用户，提起了近万起知识产权维权诉讼，最高法院明确将其定性为“钓鱼式维权”，给予否定评价[16]。

总体而言，开源模式带来的批量维权风险基本属于可控范畴，特别是在51号判决明确了“权利人违反开源义务”与“向侵权者主张侵权责任”是相对独立的两个法律问题后，相当于“没收”了这些批量维权的公司用以“挟持”其他公司的重要武器。而最高法院以媒体曝光的方式向社会公众公布此类批量维权，更进一步地表明了中国法院对这种牟利行为的态度，对树立我国开源生态圈的正确价值观有着重要意义。

四、择善而从：发挥制度优势，守序兼容开放

承前所述，开源制度诞生于国外，在“舶来”与本土化的过程中，引发了一系列的兼容问题，但这些问题最终都可以通过制度的顶层设计得以妥善解决，事实上，我国已经在其他领域进行了有益探索。在2021年6月1日实施的《专利法》中，新增了“开放许可”制度，即专利权人可以在自愿的前提下，许可任何单位或者个人实施其专利，并明确许可使用费的支付方式与计算标准，由国务院专利行政部门予以公告，这一制度已经属于“专利开源”的范畴。而我国软件领域的开源规则完全可以充分参考专利开放许可制度实施的经验，择善而从，形成更加科学、合理的软件开源规则。

例如，专利的开放许可制度是由国务院专利行政部门进行统一管理，通过建立专利开放许可的平台，为有“专利开源”意向的专利权人与实施专利意向的经营主体搭建桥梁。由于开放许可有“明码标价”的特点，能够使有意向合作的双方第一时间进入到“报价”环节，大大节省了流程。而开源规则在制定时，同样也可参照这一思路，甚至可以考虑在部分开源许可证协议中明确，若二次开发者违反开源协议，对源代码进行闭源，则自动转为付费许可模式，并附上许可费计算方式，这样会使开源生态链中每一环节参与者，都会对自己行为的后果有更强的可预见性。同时，若二次开发者经过计算，发现付费许可模式将会支付其难以承受的经济支出，则自然会知难而退，这也呼应了本文第二章节末尾“商业决定应由企业自行作出”的观点；同时，开源软件权利人在针对违反开源协议的二次开发者进行维权时，也有比较明确的许可费计算依据，同样降低了维权的难度。

综上所述，在我国尽快建立、完善、推广中国自己的开源社区，制定属于中国自己的开源规则，对新质生产力的发展有着不可估量的推进作用，这也更加凸显当前现有的涉开源协议生效判例、特别是“判例拼图”对开源规则制定所带来的价值。对照国外的开源运动发展，由于发起方组织松散，导致相关重要问题的判断标准并没有以制度化的方式明确，在资本强势介入后，已经难以回到初心。而中国完全可以发挥制度优势，在吸纳国外开源运动的经验和教训后，结合“专利开源”的宝贵实践经验，制定出具有可操作性的软件开源规则，使原始权利人与二次开发者都能够通过规则预见到自己行为可能带来的后果，最终形成稳定而不失开放的秩序，将开源制度的优势最大程度地展现。

注释：

[1]参见《2023中国开源发展蓝皮书》，链接https://gitcode.net/COPU/copu/-/blob/master/static/images/开源蓝皮书-2023.pdf，最后访问时间：2024年7月25日。

[2]参见中国政府网，链接https://www.gov.cn/zhengce/zhengceku/2017-11/27/content_5242582.htm，最后访问时间：2024年7月16日。

[3]参见GNU官方网站《GPLv3 快速指导》，链接https://www.gnu.org/licenses/quick-guide-gplv3.html，最后访问时间：2024年7月19日。

[4]参见张平、徐美玲：《开源规则——案例、许可证及开源组织》，知识产权出版社2022年11月第1版，第279页。

[5]参见张韬略：《我国创设软件版权侵权“开源抗辩”之质疑——兼评“未来案”和“亿邦案”》，载《环球法律评论》2024年第2期，第84-85页。

[6]参见游云庭：《最高院不认可开源协议的传染性了？》，链接https://mp.weixin.qq.com/s/x_PtzobcCEM39atNZMpi_w，最后访问时间：2024年7月16日。

[7]参见GNU官方网站《GNU 许可证常见问题》，链接https://www.gnu.org/licenses/gpl-faq.zh-cn.html#MereAggregation，最后访问时间：2024年7月16日。

[8]参见张韬略：《我国创设软件版权侵权“开源抗辩”之质疑——兼评“未来案”和“亿邦案”》，载《环球法律评论》2024年第2期，第86页。

[9]参见北京市高级人民法院（2018）京民终471号民事判决书。

[10]参见最高人民法院（2019）最高法知民终663号民事判决书。

[11]参见黄菁茹：《开源项目中贡献者请求权研究》，载《知识产权》2024年第6期，第38页。

[12]参见张平：《开放创新的知识产权应用机制》，载《知识产权》2024年第6期，第14页。

[13]参见《突发！HashiCorp禁止在中国使用企业版VAULT软件》，链接：https://blog.csdn.net/superfjj/article/details/106436528，最后访问时间：2024年7月17日。

[14]参见《GitHub封禁俄罗斯开发者账号，与美国制裁有直接关系》，链接：https://m.thepaper.cn/baijiahao_17690640，最后访问时间：2024年7月17日。

[15]参见周丹丹、曹阳：《企业如何应对Qt开源软件权利人的维权警告》，链接https://mp.weixin.qq.com/s/iNCLXtJXOxdQHzKywgclDw，最后访问时间：2024年7月19日。

[16]参见《宣称软件免费使用实为诱发大批量“侵权”牟利 最高法：不予支持》，链接https://mp.weixin.qq.com/s/SZtJBTiltH7AzYpB9cKs-w，最后访问时间：2024年7月19日。

本文作者：

吕成伟，德恒苏州办公室合伙人；主要执业领域为知识产权领域的诉讼与知识产权法律顾问服务，尤其擅长技术类及疑难复杂知识产权诉讼的代理。

声明：

本文由德恒律师事务所律师原创，仅代表作者本人观点，不得视为德恒律师事务所或其律师出具的正式法律意见或建议。如需转载或引用本文的任何内容，请注明出处。