软件著作权侵权“开源抗辩”解析

内容提要

开源是构筑新质生产力的有力支撑，开源软件的有效治理是知识产权强国建设的重点和关键举措之一。在软件著作权侵权纠纷中，开源软件“群智激发→群智汇聚→群智创新”的共创模式促发了“开源抗辩”这一新型侵权抗辩事由。广义的“开源抗辩”包括潜在侵权方基于涉案软件开源特性提出的抗辩，狭义的“开源抗辩”则是立足于开源许可证的不侵权抗辩。解析“开源抗辩”，应认识到开源软件具备构成合作作品的可能性，同时应基于开源贡献者协议为其著作权权属认定留出意定空间。开源软件与派生软件间“开源抗辩”的判断重点在于是否遵循开源许可证，基于开源软件开发的派生软件与再派生软件间“开源抗辩”的本质则属于非法演绎作品的可版权性争议，应秉持“违约－侵权”二分的基本原则，在认可非法派生软件可版权性的基础上，完善开源许可证条款，并设立软件著作权集体管理组织。

关 键 词

开源软件 合作作品 开源贡献者协议 开源许可证 开源抗辩 非法演绎作品

开源率先孕育于软件领域，如今已发展为构建数字技术和智能科技创新蓝图的重要基石，同时也新晋为国际贸易和国际竞争的关键场域。欧盟2020年通过的《开源软件战略2020－2023》基于“Think Open”的主旨拟定了开源软件服务欧洲数字战略的目标以及具体行动所遵循的六个原则；2021年发布的《开源软件和硬件对欧盟经济技术独立性、竞争力和创新影响》报告强调了开源对于推动欧盟经济和技术发展的重要性；2023年欧盟《网络弹性法案》关于数字产品网络安全的规定对开源软件以及社区运行机制具有重要影响。美国发布了全球首个将开源软件纳入国家关键基础设施的2023年《保护开源软件法案》，重点关注开源软件的安全风险和治理规范。我国在立法层面暂未出台专门的法律法规，但《中华人民共和国国民经济和社会发展第十四个五年规划和2035年远景目标纲要》《知识产权强国建设纲要（2021－2035年）》等均指出“完善开源知识产权和法律体系”，《工业和信息化部等七部门关于推动未来产业创新发展的实施意见》（工信部联科〔2024〕12号）进一步强调“推广开源技术，建设开源社区，构建开源生态体系”。在我国，开源经历了“初识开源—使用开源—贡献开源—自主开源—主导建设开源生态”的成长阶段，对开源的治理范式也相继提出了新的命题和规则供给需求，尤其是近年来陆续发生的软件著作权侵权纠纷中，在传统的如合理使用等侵权抗辩外，出现了“开源抗辩”这一新的抗辩事由。“开源抗辩”不仅包括潜在侵权方基于开源软件独特的群智化创作模式提出的作品类型及权利归属抗辩，还包括基于开源许可证的不侵权抗辩。目前，司法实践对此类新型抗辩的处理态度不一，学界和实务界也存在争议，实有必要予以研析并回应各方利益主体的核心关切。

一、开源软件的群智化创作模式

开源软件，也称为“开放源代码软件”，是以一种开放式、协作式创作模式完成的智力成果。与闭源软件的封闭式创作模式相较，开源软件颠覆了“大教堂式”自上而下的层级式创作架构，使得软件的生产场域由相对有限的集中疆域扩大到“集市”般的辽阔场地。开源软件平民化、网格式的生产方式打开了分布式协作创作的大门，大大降低了软件创作的门槛，激发了软件开发者的创作热情，同时也吸引大批志同道合的软件创作者汇集于同一开发项目，群策群力共建更为优质的代码和软件。开源软件创作的本质是一种大规模的“群智激发→群智汇聚→群智创新”创作过程，其避免了“重复造轮子”，极大地提高了软件创作的效率，迅速成为软件开发的优选模式。然而，此种分散式的群智化创作模式为软件作品的著作权归属认定设置了难题，成为软件著作权侵权纠纷中关键的交锋点。因此，有必要厘清开源软件的创作模式并适配相应的治理范式，以确保此种大规模且相对分散的群智化创新能够在有序和有效的轨道上进行。

开源软件的“群智汇聚”需要依托开放式的协作平台，其中尤为重要的是代码托管平台。作为全球最大的版本控制和协作的代码托管平台，GitHub汇集了全球超过1亿个开发者，在开源生态中扮演着关键的角色。本文以GitHub为例，剖析开源软件的共建流程。第一，创建仓库（repository）：在平台创建仓库之后，软件创始者（开源项目管理者）将其独立完成的初始源代码储存至仓库中，并可选择设置为公开或者私有，若为公开，则GitHub平台的所有用户皆可访问和获取该源代码。第二，新建分支（branch）：仓库在创建时会生成一个主分支（main branch），平台允许复制主分支并创建其他分支，分支上的任何代码更改不会影响主分支，若用户有意对该源代码进行修改，则可以在分支中进行操作。第三，提交（commit）文件：若用户修改并希望将修改内容反馈给项目管理者，则可以将修改的内容进行提交，但此时的提交仅存在于分支中，并不能对主分支产生影响。第四，拉取请求（pull request）：用户可以通过打开拉取请求的方式向项目管理者展示分支发生的修改内容，而项目管理者可以选择接受、拒绝或增加其他修改建议。第五，合并（merge）请求：若项目管理者接受和认可修改内容，则可以将拉取请求中的修改合并至主分支中，形成新的项目版本，此时拉取修改请求的用户即成为新版本项目的“贡献者”（contributor）。

开源的核心要义是开放、协作、共建、共享，激发“群智”、汇聚“群力”，以推动优质高效的创新成果出现。群智化的创作模式意味着，要实现这一美好目标，需要精细地平衡开源软件所涉相关主体的预期和权益，以确保创新和贡献可持续输入，并促进开源成果自由无忧地传播和使用。“回顾软件产业的发展历程，软件经历了从‘买硬件送软件’的免费开源阶段，到‘由知识产权保驾护航’的付费闭源阶段，再到如今‘需要循规蹈矩’的附条件开源阶段。”为了明晰各方主体的权利和义务边界，开源领域中包含许可证在内的若干“协议”发挥着利益分配和沟通的“桥梁”作用，使相关主体可以知悉自己在从事开源活动的过程中“应为”“可为”及“不应为”的事项，从而更好地维护开源生态的良好运作。基于开源许可证（open source license），若干使用者或者不特定义务主体，可以在遵循或满足许可证设定的不同条件的基础上，自由使用、修改或者共享权利人的软件。关于开源许可证的法律性质，理论和实践层面存在不同的观点，例如有的认为应视其为合同，有的则主张其本质是许可。近年来，全球以及中国的司法实践基本上已经认可了开源许可证的合同性质，并将之视为作者与使用者之间订立的一种非典型的、格式化的、附解除条件的著作权许可使用合同。随着开源形态日益多元化，开源许可证历经了从“无”到“有”、从“有”到“多”、从“多”到“繁”的演进。根据许可证条件的设定主体或管理主体，以及条件的宽严水平、适用频率等不同标准，可以将许可证划分为不同的类型。一般而言，自建开源平台在选择开源许可证类型时常常有其特定的偏好，选择余地相对较小；而开源托管平台更倾向将选择权交给用户，例如GitHub基本上接受所有类型的开源许可证，包括Copyleft型许可证（如AGPL、GPL、LGPL）和Permissive型许可证（如MIT、Apache、BSD）。项目管理者在GitHub上发布其初始源代码时，可以同步选择一份开源许可证，以规范受著作权保护的软件的使用或分发行为，同时保护原作者的权益。此外，在项目管理者接受贡献者提交的拉取请求之前，贡献者须签署一份贡献者许可协议（Contributor License Agreement, CLA），协议只须签署一次，对该贡献者的所有提交均生效。贡献者许可协议的目的是确保项目管理者能够控制和管理所贡献的内容，并保证项目的整体性和一致性。

二、开源软件合作作品认定的抗辩辨析

在司法实践中，可版权性、作品类型和权利主体认定是著作权人提起侵权之诉的前提和基础问题，潜在侵权方经常会就此进行挑战以支持其不侵权抗辩的主张。开源软件是特殊类型的作品，其群智化的创作模式决定了所涉客体的多版本性以及所涉主体的多元性。一方面，著作权侵权纠纷的当事人往往需要首先确认涉案软件的保护对象和范围，但开源软件的开放性使得全球用户能随时进行修改和优化，即开源软件始终处于变化和未定状态。尽管如此，在动态变化的状态下，开源软件仍然存在阶段性的静态固定属性。在项目管理者发布初始源代码时，以及每一次将用户拉取请求中的修改合并至主分支时，均会出现一个相对固定版本，当事人只需确认好涉案软件所对应的特定版本即可。另一方面，涉及开源软件的著作权侵权纠纷中，被告常常基于“开源软件系由多人合作开发的合作作品”来否定原告的权利基础，挑战原告的诉讼主体资格。因此，开源软件的作品类型认定成为此类纠纷的重要争议点。

两人或者两人以上合作创作的作品为合作作品，这里的“合作”通常须同时满足主观层面的“共同创作意图”和客观层面的“共同（实质性）创作行为”。在我国目前的司法实践中，对于潜在侵权方提出的“开源软件构成合作作品”的抗辩，法院均未予以支持，但在合作作品构成要件的具体分析上，存在不一致的认识（见表1）。首先，在主观要件方面：有法院认为，项目管理者在创建仓库以及发布初始源代码时，已体现出了开源软件的完整创作意图，贡献者拉取请求并被合并入主分支的修改行为，并不能被认定为具有创作的合意；然而，有法院认为“涉案软件源代码的提交者包括项目管理者和贡献者，而贡献者提交代码的流程是先由贡献者发起拉取申请，经项目管理者同意后才会并入主分支中，显然双方存在共同创作的合意”。其次，在客观要件方面：法院予以否定的理由，一方面在于证据不足以证明共同创作的事实或者直接否定共同创作行为的存在；另一方面则主要在于贡献者参与创作的行为不满足“实质性”贡献。例如，在济宁市罗盒网络科技有限公司诉福建风灵创景科技有限公司等侵害计算机软件著作权纠纷案（以下简称罗盒诉风灵案）中，一审法院认为项目管理人“对‘主分支’中VirtualApp源代码的形成起到了决定作用，贡献者的内容未对原告享有涉案软件著作权产生实质性影响”，而二审法院以证据不足为由驳回了被告的这一抗辩请求。由此可见，关于开源软件能否构成合作作品，当事人及法院均存在争议，有待厘清。

关于开源软件是否构成合作作品的争议，本文认为，应立足于开源软件的群智化创作特点，从以下三个维度进行剖析。

第一，项目管理者与贡献者之间是否存在共同的创作合意。在这一主观要件上，如前所述，有法院持否定观点，也有法院肯定了二者之间存在创作合意。本文赞同肯定论观点，理由如下：首先，合作作品这一特殊作品类型的设置，旨在鼓励合作创作，以弥补单一个体的创作局限，提高作品的创作质量和效率，并认可、保护及平衡合作者之间的利益。这在根本上与开源“群智群新”的本意是耦合的。其次，在项目管理者创建仓库、发布初始源代码并将之设置为公开时，其在主观上即已作出欢迎用户参与项目建设的意思表示；而用户在“创建分支－提交文件－拉取请求”阶段的行为，即为其有意参与项目建设的意思表示。在项目管理者决定接受用户的修改内容，并将之合并入主分支的那一刻，用户的身份转变为项目贡献者，二者共同创作的意图在这一刻交汇，合意致力于打造更加优质和完备的开源软件。最后，针对“项目管理者在初始源代码发布之时即已展现完整创作意图”以及“特定版本的开源软件是由项目管理者单方决定，贡献者对最终创作形态并无清楚认知”等观点，本文认为有待商榷。一方面，开源软件的动态变化性意味着初始源代码发布之时的版本并非开源软件的唯一形态，而项目管理者将初始源代码设置为开放可获取状态的行为也意味着其创作意图并非在这一刻已然完全呈现。另一方面，合作作品中“合意”的达成并不要求限定在初始源代码发布那一刻即已达成，在动态创作过程中寻找新的志同道合的合作者并达成创作合意，并不影响对特定版本开源软件合作创作意图的认定。

第二，项目管理者与贡献者是否存在共同创作的事实。在这一客观要件上，法院几乎均持否定态度，或基于证据不足，或基于事实认定。本文认为，这一处理方式有待商榷，理由如下：首先，贡献者的确实际作出了真实的创作行为，其对初始源代码及特定版本源代码的调整、修改、补充和优化等行为，均是其真实意思的表示，当项目管理者决定将贡献者的智力成果合并入主分支时，二者先后分别实施的创作行为在这一刻完成“共同”的交汇。其次，贡献者的共同创作努力和事实不应被简单“抹杀”或者“忽视”。贡献者在整个开源生态链中扮演着至关重要和不可或缺的角色，是尤为核心和关键的参与主体。开源项目乃至整个开源生态的成功和可持续发展，均依赖于贡献者的积极参与和协作开发，为了保证开源项目和开源生态的长久维持及可持续运转，对贡献者的激励保障是十分必要的。激励的工具包括但不限于情感激励、精神激励、物质激励及制度激励。其中，对贡献者共同创作行为和事实的认可，是制度激励的重要一环。

第三，贡献者对开源软件特定版本的贡献是否满足实质性贡献的标准。合作作品的认定，除了须具备主观上的共同创作意图，实施客观上的共同创作行为之外，还须满足实质性贡献的要件，若仅是如错别字、标点符号等非实质性内容的修订，则不满足此要件。在这一要件上，法院均持否定态度，但在理由阐释和论证方面却显不足。本文认为，针对开源软件特定版本的共同创作方所作的贡献是否满足“实质性”标准这一问题，应当具体案件具体分析，而非囿于“共同创作合意”和“共同创作事实”的影响，简单地将贡献者的努力排除在外。基于开源软件的群智化创作过程可知，项目管理者发布初始源代码之后，贡献者可以在此基础之上进行修改、补充、完善等操作。整个开源软件项目推进的各阶段和各环节，均有一定数量的贡献者参与，而每一位贡献者的参与程度以及对特定版本开源软件的贡献程度有所不同，不应仅关注项目管理者的功劳，而忽略其他贡献者的智力投入和付出。因此，应当结合具体案件情况来具体分析贡献者的创作对特定版本的开源软件而言是否满足实质性贡献标准。贡献者的“贡献”之于特定版本的开源软件是否构成“实质性”，应从“质”和“量”两个维度综合考察。

三、开源软件著作权归属与诉讼主体资格的抗辩判定

如前所述，开源软件具备构成合作作品的可能性。若基于前述三要件的评估，特定开源软件不构成合作作品，则其著作权归属于特定的单一主体；但若特定开源软件被认定为合作作品，则其著作权归属有所不同。根据《著作权法》第14条和《著作权法实施条例》第9条规定，合作作品的著作权由合作作者共同享有，合作作品可以分割使用的，作者对各自创作的部分可以单独享有著作权。但根据《计算机软件保护条例》第10条规定，合作开发的软件，其著作权的归属有约定从约定，无约定或者约定不明确的，基于合作开发的软件是否可分割来判断权属：若可分割，开发者对各自开发的部分可以单独享有著作权，但不得扩展到合作开发的软件整体的著作权；若不可分割，则著作权由各合作开发者共同享有，通过协商一致行使，不能协商一致又无正当理由的，任何一方不得阻止他方行使除转让权以外的其他权利，但是所得收益应当合理分配给所有合作开发者。与《著作权法》硬性规定合作作者共同享有著作权（共同共有或者按份共有）不同，《计算机软件保护条例》增设了“权属约定”的前置规则。相较作为新法、上位法和一般法的《著作权法》，《计算机软件保护条例》属于旧法、下位法和特别法，二者发生抵触时应当适用“高法优于低法”规则，因为“特别法优于一般法”和“新法优于旧法”规则只适用于“同一机关”制定的法之间，不适用于不同机关或不同法律位阶之间的法律冲突。本文认为，在计算机软件这一领域，《计算机软件保护条例》的规定更具针对性，符合软件领域的实际情况，有利于解决开源软件合作作品的著作权归属难题。因此，本文建议《著作权法》关于合作作品权属的规定应当为计算机软件留出意定的空间。

开源软件项目中，有诸多贡献者参与创作，尤其是大规模的优质项目，贡献者可能来自全球各个角落，数量会更多。这增加了确定开源软件著作权人的难度。司法实践中，为了解决这一难题，法院基于对开源许可证的解读以及对维权效率的考量，认定项目管理者有权单独提起诉讼，无须经过其他贡献者授权。本文认为，这一处理思路顾及了诉讼经济上的合理性，尽可能地维护了著作权人的诉权，却忽略了对贡献者权益的保护，缺少法律论证上的正当性。在认定开源软件构成合作作品之后，首先应确认参与共同创作的贡献者名单，其次根据《计算机软件保护条例》第10条的规定，考察项目管理者与贡献者之间是否存在关于著作权归属的约定，若有约定，应当遵从其意思自治。在开源实践中，双方的意定表达主要是通过开源贡献者协议实现的，而非法院在论证中援引的开源许可证。与开源许可证的制式化不同，开源贡献者协议可以由项目管理方自行定义，没有统一的标准，每一个项目均可以制定自己的开源贡献者协议。因此，法院应当重点查明开源贡献者协议中是否就贡献者享有相关著作权作出了特殊约定，若有约定，应当遵从其意思自治，而非绕开开源贡献者协议的约定内容，直接将贡献者排除在合作作品的著作权主体范围之外。同时，法院还应查明贡献者在协议中的授权是属于独占许可、排他许可还是普通许可，以确认原告是否具有以自己的名义独立提起诉讼的权利。

在贡献者没有签署开源贡献者协议，或者协议中没有明确约定合作作品的著作权归属问题时，法院方能依据合作创作的开源软件是否可以分割使用来判断权属：若可分割，则各开发者可以单独享有著作权，仅能对自己享有著作权的部分主张权利，而非整个合作作品；若不可分割，则著作权由所有开发者共同享有，项目管理者未经与其他贡献者协商一致而行使权利的，须证明其他贡献者无正当理由阻止其维权，且维权所得收益应当合理分配给其他贡献者。因此，当被告挑战原告的诉讼主体资格时，法院应当依法查明事实，以确定原告是否为涉案作品的适格权利人。当然，从维权和诉讼效率的角度，开源项目管理者作为合作作品的主导者，由其提起著作权侵权之诉，更具经济性和效率性。本文建议，相关利益主体应重视和完善开源贡献者协议，在协议中事先对各方的利益分配以及权利维护事项作出明确约定，以便对复杂的权属问题进行集约化处理。然而，需强调的是，这并不意味着可以单纯基于维护部分权利人的权益和诉讼效率方面的考量，而牺牲法律赋予贡献者的正当权利，例如绕过贡献者的权利主体认定问题，或者先处理本案，若后续有贡献者提出关于著作权归属或权益分配的争议，再“另案处理”，向项目管理人主张分割赔偿款。

四、基于“Copyleft型”开源许可证的不侵权抗辩研析

开源软件的著作权人基于开源许可证将其著作权附条件地授权许可给用户使用，降低了后续软件开发的成本和门槛，形成了软件开发和传播的自由环境。为了提高开发效率，用户钟爱在开源软件的基础上进一步设计和开发新的软件。若用户新创作的软件满足著作权法中作品的构成要件，则其可以被视为“派生作品”或者“演绎作品”。根据著作权法的规定，演绎作品的创作须经被演绎作品著作权人许可，且不得侵害被演绎作品的著作权；若在演绎作品的基础上创作新的作品，则须同时获得被演绎作品著作权人和演绎作品著作权人的双重授权。不同于一般作品的传统许可方式，开源软件作品与派生软件作品之间的许可是通过开源许可证实现的。不同的开源许可证所附条件的宽严不同，与Permissive型开源许可证相比，Copyleft型开源许可证附有较为严格的许可条件，要求最大限度地保证开源软件的自由流通，即派生软件在分发时仍须再次进行“开源”处理，以确保开源的基本精神和规则可以“传染”至所有后续的派生软件。根据再分发时是否要求必须基于同一许可证，Copyleft型开源许可证可进一步分为“强传染性”和“弱传染性”许可证。前者的典型代表为GPL，目前共有三个版本，是开源软件中较为流行的重要许可证，也是所涉著作权纠纷最多的许可证。

以GPL 3.0为例，该协议规定若原开源软件选择适用GPL 3.0，在此基础之上的后续派生软件也受该协议约束，若用户发布派生软件时未遵守该协议的再“开源”的要求，则其基于该协议获得的免费使用原开源软件的授权将自动终止，其使用行为会因为失去合法授权而构成著作权侵权。这不仅会引发开源软件与派生软件之间的侵权纠纷，也会导致再派生软件与派生软件之间产生法律纠纷。司法实践中，被告基于GPL的“传染性”主张涉案软件应受该协议约束，原告负有将涉案软件的源代码开源的义务，而被告亦可基于该协议获得涉案软件源代码的著作权授权，由此提出著作权不侵权抗辩。对于这一“开源抗辩”，我国司法实践的态度并不一致，据本文统计（见表2），截至目前的11例相关纠纷中，仅1例抗辩成功，2例部分抗辩成功，1例阶段性抗辩成功，7例均抗辩失败。

结合上述案例，以派生软件为标准，本文将我国司法实践中的“开源抗辩”大致分为两类（见图1）。

I类：派生软件A在开源软件的基础上开发完成，著作权纠纷产生于开源软件的著作权人与派生软件A的持有人之间。此时派生软件A的持有人抗辩开源软件受GPL约束，已作出开源承诺，无权再主张著作权侵权。对于此类开源抗辩，本文认为，首先，开源软件或许可以被视为公共产品，但需警惕开源软件本身具备可版权性，开源软件适用GPL协议并不意味着权利人不享有著作权，也不等同于权利人完全放弃其著作权，实际上其正是基于GPL中所附的条件向潜在使用者进行权利许可。其次，GPL协议并未剥夺开源软件著作权人的诉讼权利，GPL 3.0第10条第3款中的“不得提起诉讼”指向的是专利权，并未限制权利人对著作权的主张。最后，此类开源抗辩的判断重点在于派生软件A的持有人是否遵循GPL协议：（1）若遵循，则派生软件A对开源软件的使用具备意定的合法来源基础，派生软件A的持有人抗辩成功，但需特别留意区分开源软件作品上的人身权与财产权。例如，在卓卓诉某公司案和米拓诉潇湘周派案中，被告均以复制权抗辩成功，但法院仍然支持了原告关于署名权的请求。（2）若未遵循，如未按照GPL 3.0协议向公众无偿开放源代码，则派生软件A的持有人会因失去正当性权利来源而构成对开源软件著作权的侵权，例如罗盒诉风灵案、罗盒诉玩友案以及2024年2月法国最高法院终审判决的Entr'ouvert v. Orange案。未遵循GPL协议的派生软件持有人的行为，既可能构成违约，又可能构成侵权，根据《民法典》第186条规定，受损害方有权选择请求其承担违约责任或者侵权责任。通常，侵权责任的范围大于违约责任，相较而言，著作权人会更青睐侵权之诉而非违约之诉，因为前者在证明责任和损失赔偿等方面更具优势。

II类：派生软件B在派生软件A的基础上开发完成，或者派生软件B使用了派生软件A的部分源代码，著作权纠纷产生于派生软件A的著作权人与派生软件B的持有人之间。此时，派生软件B的持有人基于GPL的“传染性”作不侵权抗辩，即主张派生软件A源于适用GPL协议的开源软件，也应受GPL协议约束，因此派生软件B具备使用派生软件A的正当性基础。在查明派生软件A的著作权保护范围和权利主体的基础上，应判断派生软件A的持有人是否遵循GPL协议：（1）若遵循，则可参照I类开源抗辩进行处理。（2）若未遵循，则重点判断在派生软件A本身“非法”的情况下，派生软件B持有人提出的“开源抗辩”是否应当予以支持，司法实践对此态度不一。例如，在未来诉云蜻蜓案中，法院支持了涉案软件主程序部分的抗辩请求；而在网经科技诉亿邦通信案中，法院驳回了被告的不侵权抗辩请求。

针对II类（2）的“开源抗辩”，不仅司法实践未达成共识，实务界和学术界也存在争议。支持者主要基于公平和诚信原则、“毒树之果”理论以及对开源生态及软件产业发展的维护的理由，如未来诉云蜻蜓案；反对者主要认为，即便涉案软件存在违约的权利瑕疵，该瑕疵也不影响寻求侵权救济，如网经科技诉亿邦通信案。针对此类纠纷，本文认为应透过现象看本质，正如有观点所主张的，“我国不宜创设开源抗辩而应回归既有的非法演绎作品保护规则”。与I类（2）情形不同，II类（2）的本质问题并非侵权与违约的竞合，而是非法演绎的软件能否获得著作权保护，即因派生软件A未遵循开源软件GPL协议，导致派生软件A失去意定的权利来源基础，其可版权性受到挑战。

在我国司法实践中，关于非法演绎作品的著作权保护问题曾存在不同的判定，承认其可版权性的案例占多数，理论界的主流观点也倾向于此。从域外实践来看，美国对非法演绎作品可版权性的态度经历了从完全不认可到部分认可，再到有限保护的转变。起初，美国严格适用1976年《著作权法》第103条（a）款规定，认为任何未经作品权利人授权许可而使用他人作品进行演绎创作的行为皆是非法行为，因非法行为创作的作品为非法作品，不能享有著作权。1994年Campbell v. Acuff-Rose Music, Inc.案确立了“转换性使用原则”，美国著作权法开始逐步接纳非法演绎作品，学界也有观点指出即使是非法演绎的作品，其作者仍可能对其在创作过程中的新增独创性表达享有一定的著作权。但值得强调的是，美国的非法演绎作品并不享有与合法演绎作品相同的全面保护，保护范围和程度均受到限制。与美国不同，德国《著作权法》第23条对非法演绎作品作出了明确规定，区分著作权的产生与行使，并以独创性为标准判断是否享有著作权。由此可见，尽管保护的标准和方式存在差异，但是域内外对于非法演绎作品著作权保护的态度是积极的。随着短视频等新商业模式以及人工智能等新技术的发展，实践中关于非法演绎作品著作权保护的纠纷和规则供给需求日益增多。因此，本文建议，我国著作权法或者配套制度中应尽快明确相关规则，以更好地定分止争。

对于II类（2）“开源抗辩”，本文认为，应当秉持“违约－侵权”二分的基本原则，在非法演绎软件满足著作权保护标准的基础上，承认其可版权性。首先，非法演绎软件作品的著作权保护具备理论基础。演绎作品受保护的范围仅在于其独创性的增量部分，而非未经授权许可的存量部分。对非法演绎软件作品给予保护，契合我国著作权法平衡创新与竞争、赋权与限权、保护与传播、独占与共享的基本机理，避免因著作权对原作品“过度保护”而导致智力成果被“压箱底”、后续演绎创作的源头枯竭。其次，非法演绎软件作品的著作权保护具有现实价值。于个体而言，对其独创性部分智力劳动成果的法律认可，有利于激发社会公众的创作热情。于开源而言，这与开源的基本精神并不相悖。开源本身就源于对垄断性专有权的“反叛”，目的在于消减专有排他权的负外部性，甚至希望将具有潜在对立关系的竞争者聚集在一起以实现更大的利益而合作，避免因“碰瓷式维权”“钓鱼式维权”而损害开源的可持续发展。于国家而言，这是构筑国家开源竞争新优势的有力支撑。当前，开源已然成为国际竞争的新场域，为恰当平衡相关利益主体的核心关切提供适配的规则供给尤为关键。

针对“非法”演绎软件作品予以著作权保护，可能引发担忧，诸如对违反开源许可证的不法行为提供救济，不符合公平、诚信原则，反而会助长软件开发者免费利用开源软件却行闭源牟利的行径，破坏开源的基本精神和规则，有碍软件源代码的持续开源传播。对此，本文认为，这些问题确实值得关注，且也认可创新主体恪守许可证协议来使用开源软件是维护开源知识产权秩序和发展开源事业的基础，但这与承认非法演绎软件作品的著作权保护并不冲突。如图1所示，派生软件A因不遵循GPL的违约行为引发的法律关系产生于开源软件著作权人与派生软件A的持有人之间，而派生软件A因派生软件B的侵权行为引发的法律关系产生于派生软件A的著作权人与派生软件B的持有人之间，二者应视为相对独立的法律冲突，且对于派生软件B的著作权保护也应独立于其著作权的行使，派生软件B分发其源代码时，方会触发GPL约束，而对于派生软件A持有人违约行为的否定评价和责任承担，可以由开源软件著作权人另行提出。对于进一步可能引发的“累诉”以及救济迟缓等潜在担忧，本文建议可以完善此类纠纷中的第三人侵权诉讼制度，在必要的情况下追加开源软件的著作权人为原告，一同查明案件事实，既能实现维护原作者和演绎者共同的利益，又能实现统一裁量尺度，节约司法资源。此外，开源软件许可证条款的设计，也可以参照专利开放许可制度，明确授权许可“免费”和“付费”的条件与标准，当用户不满足“免费”使用条件时，则激活“付费”许可条款。而针对用户的海量和多元特性，可以发挥著作权集体管理组织的许可优势，在已有的“中国音乐著作权协会”“中国音像著作权集体管理协会”“中国文字著作权协会”“中国摄影著作权协会”“中国电影著作权协会”五大著作权管理组织的基础上，增设软件著作权集体管理组织，以降低开源软件著作权的交易成本，并提高此类纠纷解决的效率。2021年《工业和信息化部关于印发“十四五”软件和信息技术服务业发展规划的通知》明确指出“完善开源软件的知识产权托管……鼓励社会资本探索建立开源软件知识产权基金”。鉴于软件的专业性和开源的特殊运作模式，“软件著作权集体管理组织”的职能可以考虑授权给诸如开源平台、基金会或者开源社区等开源组织来执行，能更有针对性地发挥其管理优势。

结 语

作为一类新出现的著作权侵权抗辩事由，“开源抗辩”在司法实践和学术探讨层面均未达成共识。对其内涵与外延的认识，可立基于开源软件的群智化共创特性，作广义与狭义之理解，而对其构成要件的判定，则可进行类型化区分，并针对性识别利益交锋的法律本质。在认可和维护所有共创主体正当权利的基础上，基于公平和效率的综合考量，可有效利用若干开源协议来搭建利益分配的“桥梁”，并辅之以增设软件著作权集体管理组织以及完善民事侵权诉讼制度等方式来消减“开源抗辩”引发的潜在负外部性，进而推动整个开源生态的可持续性发展，赋能我国智能科技和数字经济的高质量发展。