编者按 

《中共中央关于进一步全面深化改革、推进中国式现代化的决定》明确，要加强新领域新赛道制度供给，建立未来产业投入增长机制，完善推动新一代信息技术、人工智能等战略性产业发展政策和治理体系。最高人民法院《关于以高质量审判服务保障科技创新的意见》指出，要加强对新一代信息技术等产业科技成果的司法保护，引导新兴产业健康有序发展。

近期，我国自主研发的大模型DeepSeek异军突起，人们为这款开源产品欢欣鼓舞的同时，也开始关注开源所面临的知识产权风险和法律问题。目前，我国在开源软件发展进程中已经出现了重要的司法案件，并提出了行之有效的裁判规则，且裁判思路契合国际司法实践。明确开源软件类案件的裁判规则，为开源软件产业发展提供司法保障，是完善我国知识产权司法保护制度、参与知识产权国际治理的具体体现。

本期刊发的3篇文章，基于近年来我国法院的司法实践并具有国际视野，聚焦于开源许可协议的性质、效力、作者身份、权利归属、损害赔偿的特殊考量因素等，在这些问题上，开源软件案件与普通著作权案件存在诸多不同之处。作者们敏锐地发现问题、凝聚共识，并尝试构建解决争议问题的一般框架，以期引起学界和实务界的进一步关注和思考。

2025年1月20日，中国自主研发的人工智能模型DeepSeek发布，引发国际广泛关注，为众多行业带来了前所未有的发展机遇。其显著优势在于其开源性，打破了当下国际上一些较为流行人工智能大模型闭源的模式，向世界贡献、共享创新成果。开源软件是开放源代码软件的简称，通常指授权人遵循某种开源许可证协议，将其源代码向公众公开，并允许用户在许可证约定的条件内自由使用、修改和分发。软件开源已经成为国际软件产业创新与发展的重要特性与创新生态，其倡导自由共享、平等参与、开放协作等精神，有利于减少开发成本、加速创新进程、推P4广创新成果。《欧盟人工智能法》虽对技术安全严格监管，但确立了开源例外规则。我国高度重视计算机软件开源创新事业的发展，《中华人民共和国国民经济和社会发展第十四个五年规划和2035年远景目标纲要》首次在国家战略规划文件中明确提出支持数字技术“开源”发展。工信部《“十四五”软件和信息技术服务业发展规划》也明确指出“繁荣国内开源生态，大力发展国内开源基金会等开源组织，完善开源软件治理规则，普及开源文化”。开源软件战略的实施和开源创新体系建设是我国实现科技自立自强的重要途径。本文拟结合国内外涉开源软件典型案例，探讨相关知识产权法律问题中的共识、争点和难点，明确规则，积极推动我国开源创新生态健康发展。

一、已有共识

国内涉开源软件知识产权司法案例并不多，且大多为近年来发生，美国以及欧盟一些国家法院较早即有相关案件裁判。笔者经分析研究国内外司法裁判以及学术成果发现，就开源软件知识产权法律问题以下方面的认识基本趋于一致：

（一）开源许可协议对初始授权人和后续接收者（用户、贡献者）具有约束力

当初始权利人创建项目仓库，将其源代码公开，并发布与之匹配的许可证协议，即创建了一个开源社区。许可协议为初始授权人和后续接收者设定了相关权利义务。对开源项目、软件主题感兴趣，有意参与分享、修改、分发源代码、进一步完善开源软件的用户在遵守协议设定义务的前提下享有合法获取、复制、分发和修改该软件源代码的权利，包括公开源代码、醒目地声明你的修改及标注修改日期等。初始授权人根据软件的功能、价值以及需要等确定不同的许可证模式，具体模式有GPL、LGPL、APACHE、MIT、BSD等。在所有模式中，GPL许可证目前适用最多，约束也最为严格，具有高传染性，著作权许可最为充分，其要求对开源软件的任何修改及衍生品应用，都必须发布源代码，并且不得收取任何许可使用费。MIT、BSD许可证较为宽松，一般只要求用户公开原作者的许可证声明以确认原作者的著作权，对开源软件的修改及衍生品应用没有发布源代码的要求。LGPL许可证介于前二者之间，其一般要求对开源软件的任何修改都应当将源代码发布，但对开源软件衍生品的应用则没有发布源代码的要求。本文主要探讨最常见的GPL协议下相关规则的适用，相关内容如无特别说明即针对GPL协议。在GPL协议下，接收者的义务，主要有公开其源代码以及GPL文本，标明初始权利人署名信息以尊重其作者身份等。如2015年德国莱比锡地区法院在一案中明确接收者在根据GPL许可证免费使用开放源代码并进一步开发时，特别有必要提及GPL协议，附上GPL许可证文本，并提供源代码。否则，可能会侵犯版权。在卓卓公司与摩尔口腔医院侵害计算机软件著作权纠纷案中，法院认定，涉案权利软件的许可协议中都要求用户在使用涉案软件建立的网站主页上保留权利人卓卓公司的署名信息标识。摩尔口腔医院使用涉案软件DedeCMS建成了网站，但未在主页标注卓卓公司创作印记或官网链接，违反了该附加条款，侵害了卓卓公司的署名权，损害了其身份权益。故卓卓公司请求摩尔口腔医院赔礼道歉等请求，具有事实和法律依据。

因此，初始权利人公开源代码，并非放弃其知识产权，而是以特定许可方式授权他人复制、修改、分布其源代码。开源许可证是维系开源创新生态的重要基石，在相关当事方之间具有强制执行力。最高人民法院在罗盒公司诉风灵公司、腾讯公司等侵害计算机软件著作权纠纷案判决中明确，开源许可证已经成为国际行业内共同认可和遵守的契约文本，履行相关义务也是诚实信用原则的体现。只有信守开源软件所附的许可证条款，才能保证将开源软件不断散播出去，让社会公众能够享有开源软件带来的便利与发展成果，不至于被私人占有导致公共利益受到损害。2011年，德国波鸿地区法院曾认定，即使程序被当作测试软件来利用，LGPL3.0 的义务仍然必须被遵守。只要原告的程序确实被结合到被告的程序中，成为了被告整体程序的一部份，原告程序仅具有测试功用、而不执行软件功能，对于判断是否必须遵守 LGPL3.0 的授权义务并不相关。因此，开源许可协议不仅为创新主体参与开源生态所应当遵P5守，也是法院审理案件时用以确定当事方权利义务、侵权与否以及法律责任等争议的准据标准。

（二）GPL许可证是附解除条件的合同

开源许可证是开源社区规范、开源创新参与者的行为准则，也是行业惯例。从法律角度分析，一般认为GPL协议是一种具有强制执行力的附解除条件的格式合同。项目管理人或初始授权人发布开源代码和GPL协议文本视为要约，后续接收者（用户、贡献者）复制、修改或分发源代码视为以其行为接受或承诺该协议内容。同样性质的情形在互联网服务领域较为常见，对于一方事先拟定好，内嵌于网络中的互联网络服务、消费协议同样是按格式合同来确定当事各方权利义务的。开源许可协议与一般格式合同的适用规则根本不同在于：（1）该协议对初始授权人与后续接收者具有强制执行力。其中相当部分条款对后续接收者设定了条件或义务，有的限制了其权利，但并不如一般格式条款那样若未向接收者提示与说明则不发生法律效力，主要原因在于此类条款已成为社区规范、行业惯例，默认开源生态参与者均知晓该限制内容，而且初始权利人无偿开放其源代码供他人使用，其已就著作权等作出极大让步。（2）对许可协议设定义务的违反将导致著作权许可授权自动终止。（3）初始权利人或衍生作品权利人对违反许可协议义务的用户既可以提起违约之诉，也可以提起著作权侵权之诉。因为用户一旦违反许可协议，权利人的授权自动终止，用户的复制、修改、分发等行为将缺乏法律依据。GPL2.0文本第4条明确，除非本协议明确规定，你不能复制、修改、再授权或分发本程序。任何用其他方法复制、修改、再授权或分发本程序的企图都是无效的，并使你从本协议获得的权利自动终止。然而按本协议从你那获得副本和许可的人，只要继续遵守协议，他们获得的许可并不会终止。第5条规定，你并非要接受它不可。但是，此外没什么可授权你去修改或分发本程序或其派生作品。此种行为为法律所不容，除非你接受本协议。因此，修改或发布本程序（或本程序的任何派生作品），就表明你已经接受本协议，即接受它的所有关于复制、分发和修改本程序及其派生作品的条款。

最高人民法院在罗盒公司诉风灵公司、腾讯公司等侵害计算机软件著作权纠纷案判决中明确认定，用户在许可证下复制、修改或再发布源代码，通过行为对许可证作出承诺，同时许可证发生法律效力。GPL3.0协议规定的使用条件（如开放源代码、标注著作权信息和修改信息等）系授权人许可用户自由使用的前提条件，亦即协议所附的解除条件。一旦用户违反了使用的前提条件，将导致GPL3.0协议在授权人与用户之间自动解除，用户基于协议获得的许可即时终止。用户实施的复制、修改、发布等行为，因失去权利来源而构成侵权。广州知识产权法院在罗盒公司诉玩友公司等侵害计算机软件著作权纠纷案判决中也明确，GPL3.0协议属于附解除条件的著作权合同，许可条款是版权许可的条件。玩友公司违反GPL3.0协议的约定，其依据GPL3.0协议获得的授权自动终止，玩友公司再使用涉案软件已没有法律和合同依据，故其构成对涉案软件著作权的侵权。江苏省南京市中级人民法院在未来公司诉云蜻蜓公司等侵害计算机软件著作权纠纷案判决中明确，GPL2.0协议是针对某一特定的项目，并预先设定好格式化条款的协议，只要授权方选定了该协议，使用该项目的用户就必须遵守该协议，是授权方和用户之间形成的以开源软件源代码为目的的一种民事法律行为。授权方选择适用GPL2.0协议传播其源代码，用户复制、修改、发行该源代码时默认承诺承继适用GPL2.0协议从而保持协议的传递性，该行为是双方真实意思的表示。因此，在用户复制、修改、发行该源代码时协议成立并生效。江苏省无锡市中级人民法院在卓卓公司诉摩尔口腔医院侵害计算机软件著作权纠纷案的判决中认定，开源协议实质是权利人将其复制权、发行权、修改权等附条件地许可给不特定公众的著作权许可合同。早在2004年，德国慕尼黑地方法院在Welte v. Sitecom Deutschland GmbH案中就已明确，不遵守开源许可证的使用行为同时构成违约和版权侵权。德国法兰克福地区法院在Welte v. D-Link案中进一步将开源许可证认定为附解除条件的合同和《德国民法典》规定的“格式合同”，开发者在许可证中设定的使用条件应当被认定为“解除条件”。此外，柏林、汉堡等地方法院也都有过类似P6判决，均支持开源许可证的效力。在2009年裁决的EDU 4 v. AFPA案中，法国巴黎上诉法院认定设备提供商删除开源软件文档的版权信息和许可证并替换成自己版权信息的行为，违反了开源许可证，构成对技术合同的违约。法国学者也认为，开源许可证可以适用《法国知识产权法典》有关知识产权许可的规定。除此之外，意大利、比利时、荷兰、西班牙的司法机关也作出了相关的司法裁判，确认了开源软件许可证具有法律效力。2018年，美国法院在Artifex Software, Inc. v. Hancom, Inc.案中开创性认定GPL协议为具有强制执行力的合同，被告未按要求提供源代码即违反了合同。联邦巡回上诉法院2010年在 Jacobsen v. Katzer, No. 08-1001 (Fed. Cir. 2008) 中认定，如果被许可使用者超出该范围使用，就构成侵权。

（三）GPL协议具有高传染性

根据GPL协议内容，只要用户的后续软件版本中使用了先前开源版本中的源代码，并且先前版本使用了GPL协议，则后续版本也必然受GPL协议的约束，后续用户也应遵守GPL协议设定的义务，如开放源代码等。但如果用户的软件作品（或部分）并非派生自开源软件作品的独立作品，并与开源作品分开发布时，则不受GPL协议约束。这就是GPL协议的传染性规则。国内外诸多案例均按此规则裁判，实践中的主要争议在于受传染作品还是独立作品如何认定、被告不侵权抗辩能否成立（下文将详细阐述）。最高人民法院在罗盒公司诉风灵公司、腾讯公司等侵害计算机软件著作权纠纷案判决中认定，福建风灵公司使用了附带GPL3.0协议的开源代码，却拒不履行GPL3.0协议约定的使用条件，其通过该协议获得的授权已因解除条件成就而自动终止，其对VirtualApp实施的复制、修改、发布等行为，因失去权利来源而构成侵权。

（四）用户遵守许可证协议获得的授权不受限制

GPL协议明确，为保障用户的权益，协议禁止任何人否认、限制用户的权利及其行使，或者要求用户放弃这些权利。这就是开源社区创建的根本宗旨，即保障社区内用户复制、分享、修改、发布某程序的权利。主要限制有：（1）软件专利威胁。实践中，开源软件的使用可能会受到与该软件相关联专利的威胁。有关主体包括开源软件权利人、后续贡献者或其他第三人，可能会将软件结合硬件以个人名义申请获得专利，以试图将软件占为己有。这将制约软件的自由使用，与开源精神相冲突。对此，GPL2.0文本明确，要避免此类情况发生，相关专利必须为保障开源软件的自由使用而申请，否则视为不应该存在。在XimpleWare, Inc. v. Versata Software, Inc. et al案中，原告基于涉案开源软件拥有3项专利，其指控被告使用涉案开源软件的行为构成专利侵权。美国加州北部地区法院圣何塞分院认定，被告在不违反GPL2.0的情况下，使用涉案开源软件的行为不会受到限制，不构成专利侵权。（2）商业使用的限制。一些软件持有人在开源许可协议中还可能会添加限制用户商业使用的声明，例如宣称后续使用者一旦将开源软件用于商业用途时，需要购买商业授权。该声明与开源软件开放、共享、免费获得许可等自由理念相悖，与GPL协议不兼容，应属无效。如在前述最高人民法院（2021）最高法知民终2063号案中，法院认为，GPL3.0协议并未限制用户进行商用，只是必须遵守开源的规定。罗盒公司虽在GitHub网站上声明禁止用户对VirtualApp开源代码进行商用，但根据GPL3.0协议第7条、第10条的约定，附加条款适用的情形和内容是明确的，限制商用不在其列；授权人亦不可以对GPL3.0协议所授或确认权利的行使施以进一步的限制。故在GPL3.0协议允许用户进行商用的情况下，授权人不得对此作出限制。在前述无锡中院（2023）苏02民初482号案中，法院认定，涉案权利软件许可协议中的“商业用途需获得授权”的条款与GPL协议相抵触，卓卓公司无权在适用GPL协议的涉案软件中添加涉案商业使用限制条款。（3）收取许可费限制。需要说明的是，初始权利人就开放源代码不能收取许可使用费。GPL协议文P7本明确对于开源软件强调的是对源代码复制、修改、分发等方面的自由，权利人不得收取任何许可使用费、版税或其他与授权相关的其他费用。但这并意味着相关主体就软件发生的任何事项不能收取任何费用，即价格免费。究竟权利人可以收取哪些费用，需要根据GPL协议文本内容来判断。GPL2.0版本序言中明确，You have the freedom to distribute copies of free software (and charge for this service if you wish)，即相关主体可以就分发开源软件的复制件收取服务费。协议第1条第2款规定：“You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.”这里的“physical act of transferring a copy”指的是区别于数字传输如网络下载复制件。由此可知，可以收取的费用包括技术服务费以及与数字传输相区别的硬件复制件（如用光盘、U盘拷贝）等费用。在卓卓公司与摩尔口腔医院侵害计算机软件著作权纠纷案中，法院认定，GPL2.0、3.0均在序言中谈到可以就软件收取费用，但根据协议的其他条款及问答，允许收取的是软件拷贝费、技术支持费等，授权费是排除在GPL协议允许收取的费用之外的。在罗盒公司诉玩友公司等侵害计算机软件著作权纠纷案中，法院认定，罗盒公司无权在适用GPL3.0协议的涉案项目中添加商业使用限制保留条款。作为软件源代码是不收费的，而对开源软件提供专业技术服务及由此派生的增值业务则可以收费。

（五）开源不影响商业秘密保护

实践中发生将他人闭源软件源代码作为开源代码公开，或者使用软件中非开源部分的源代码的情形。在相关源代码符合商业秘密构成要件,且被他人擅自披露、使用等受到损害时，权利人可以请求商业秘密保护。2013年，浙江省杭州市中级人民法院在天骄文韵软件公司与恒生电子公司等侵害商业秘密纠纷案中，认定如果软件中既包含开源软件，也包含自己开发的代码，则自己独立开发的部分在符合商业秘密认定三要件的情况下能够作为商业秘密得到保护。美国IBM公司曾在犹他州地区法院受到SCO公司指控其擅自向Linux开源社区披露了SCO公司专有的 UNIX素材，并创建了UNIX操作系统AIX，构成对SCO公司的侵权性干扰。后双方达成和解。

二、原告主体适格性

在开源环境下，项目管理者或初始授权人将其软件源代码在代码托管平台（如全球最大平台GitHub网站）建立的仓库公开并创建主分支后，用户可以对源代码进行复制、修改、分发等。若用户希望将修改内容提交给项目人，则上传“提交”（commit）并向项目人发出“拉请求”（pullrequest）。项目管理人可以接受、拒绝其修改内容或增加其他修改建议。若项目管理者认可用户的修改内容，则可以将修改内容“合并（merge）”至项目软件的主分支中并形成新的项目软件版本。此时该用户即成为该项目的贡献者。此时，用户（贡献者）可以按初始源代码开源许可证条款或重新与项目管理人签署一份单独的贡献者许可协议来许可其贡献。“贡献者许可协议的目的是确保项目管理者能够控制和管理所贡献的内容，并保证项目的整体性和一致性”。

在涉开源软件著作权纠纷中，项目管理人能否作为原告单独起诉，贡献者应否作为共同原告以及项目管理人是否需要征得贡献者同意才能起诉等问题，理论与实务界有不同的认识，主要在于开源软件源代码历经多位贡献者参与修改与贡献。相关案件中被告一般抗辩认为，涉案软件作品为合作作品，项目管理人不能以独立的原告身份起诉，需经其他贡献者授权或法院应当通知其他贡献者作为共同原告参与诉讼。我国法院裁判以及国外绝大多数裁判支持项目管理人单独起诉，认为涉案作品因项目管理人与贡献者之间没有共同的创作意愿以及共同的创作行为而不构成合作作品，或被告主张合作作品证据不足。同时，项目管理人对源代码的形成起到了决定性作用，尚无证据证明案涉贡献者的修改对案涉软件著作权产生实质性影响，经全体贡献者同意授权才能起诉将阻碍维权救济。如在前述罗盒公司诉风灵公司、腾讯公司等侵害计算机软件著作权纠纷案中，最高人民法院在二审判决中认定，本案共计34名贡献P8者对涉案源代码作出了修改。计算机软件在发布与开源之时已体现出创作者完整的创作意图。由贡献者发起拉取申请、经项目管理者同意后并入主分支的过程，反映了软件源代码开源的本意，即通过互联网媒介，集合全球开发者的智慧，尽可能使软件最优化，从而促进知识的传播。这一目的是开源软件作者、贡献者与使用者的前提共识，贡献者对开源软件的修改只是为了这一目的更好地实现，并不能就此认为开源软件的贡献者与作者具有创作合意，亦不能认为贡献者针对开源软件提出修改意见的行为是共同创作行为。本案中项目管理者罗盒公司对涉案软件源代码的形成起到了决定性作用，贡献者提交的内容是否对涉案软件产生实质性影响尚不明确，根据在案证据难以得出贡献者系涉案软件合作作者的结论。退一步而言，即便贡献者对作品的创作产生实质影响，即贡献者创作的代码具备独创性、可以单独使用、享有独立的软件著作权，基于GPL3.0协议，项目管理人对此类代码也享有普通许可使用权。同时，对于开源软件而言，往往难以界定全部著作权人，只要该项目保持开源，则贡献者数量会持续动态增加，这将对权利人范围的确定造成极大的阻碍。若要求必须经过所有贡献者的授权才能提起诉讼，将导致开源软件维权无从谈起。贡献者针对开源软件提交代码并发起拉取申请应视为其默示同意作为普通被许可人的项目管理人提起侵权之诉，针对有关的被诉侵权行为可以一并认定并判赔。贡献者乃至在先代码著作权人若对涉案软件的著作权归属或权益分配存在争议，可另行向项目管理人主张。最终法院认定，罗盒公司作为提交了涉案软件绝大部分源代码的项目管理人，其提起本案诉讼无需经过其他贡献者的授权。在卓卓公司诉摩尔口腔医院侵害计算机软件著作权纠纷案中，法院同样认定，“落梦天蝎”并无共同参与DedeCMS研发的创作意愿，也未实际参加共同创作活动，因此不能认定为DedeCMS的合作作者。

部分学者持相反观点。有学者认为，开源软件的动态变化性意味着初始源代码发布之时的版本并非开源软件的唯一形态，开源也意味着其创作意图并非在这一刻已然完全呈现，在动态创作过程中寻找新的志同道合的合作者并达成创作合意，并不影响对特定版本开源软件合作意图的认定。项目管理人和贡献者先后分别实施的创作行为在修改内容并入主分支时完成“共同”的交汇，贡献者的共同创作努力和事实不应被简单“抹杀”或“忽视”。也有学者认为，贡献者与项目管理者间的贡献许可协议并不排除贡献者以自己的名义维权；合作作者身份是平等一致的，并未区分贡献程度大小；并认为在这些情形下，开源项目是贡献者独立完成的小作品集合而成，因此存在开源项目被认定为汇编作品而据此确定维权主体的情形。在罗盒公司诉玩友公司等侵害计算机软件著作权纠纷案中，被告抗辩提出，通过认定超过百分之90的代码由项目管理人提供，否定贡献者对开源软件独创性的贡献，将项目管理人作为单一著作权人，将大大打击贡献者的创新积极性，不利于开源社区生态的发展。

笔者认为，涉开源软件著作权侵权案件中，在有贡献者参与的情形下，涉案作品的性质与适格原告是两个不同的概念范畴，两者既相联系又有区别，即便认定涉案作品为合作作品，项目管理人也可以单独提起诉讼。

（一）关于权利人作品性质的认定

根据我国著作权法、《计算机软件保护条例》等法律法规规定，包括源代码的计算机软件属于作品，计算机软件是指计算机程序及其有关文档。计算机程序是指为了得到某种结果而可以由计算机等具有信息处理能力的装置执行的代码化指令序列（即目标代码），或者可被自动转换成代码化指令的符号化指令序列或者符号化语句序列（即源程序）。文档是指用来描述程序的内容、组成、设计、功能规格、开发情况、测试结果及使用方法的文字资料和图表等。从贡献者将对开放源代码的修改内容并入项目管理人建立的仓库中的主分支这一过程来看，涉案软件作品存在着初始源代码与贡献者修改内容的结合。在此情况下，涉案软件作品最有可能存在合作作品或演绎作品之分（至于是否存在着汇编作品的可能性则要根据实际案情确定）。两种作品形态的区分，除了需要判断项目管理者与贡献者是否存在创作的合意、是否存在共同创作的行为之外，还应当注意：一是合作作品是合作作者围绕同一个主题和总体思想而从无到有创作的一个具P9有统一功能的软件作品。自始至终，合作者们都在共同创作一个作品。“两个以上作者在创作时应当意识到自己是在与他人共同创作一部作品。如果有分工、协作，则每个参与创作者都应当知道分工创作的最终目的是将各自创作的部分整合为一个整体。”而演绎作品，又称派生作品，是在保持已有作品基本表达的基础上，对原表达加以发展，并使新表达与原表达融为一体而形成新作品。对作品进行改编和翻译是最为典型的演绎方式。这里存在着原有作品与新作品，二者既相联系又有区别。一般情况下，项目管理人将源代码在主分支开放之时，其对一个软件作品的创作意愿、创作行为与创作内容已经完成。后续用户、贡献者是对一个具有特定主题、思想已经完成的软件作品源代码进行的修改。但这并非绝对和包罗万象。二是贡献者对初始源代码的修改内容是否具有实质性、独创性，即包含经修改的源代码的计算机软件作品与包含初始源代码的计算机软件作品相比，源代码的修改内容是否具有独创性，相比修改前的源代码是否具有实质性变化，在原作品基础上是否形成了新作品，如改编作品、翻译作品等。通常来说，贡献者对源代码的修改，“把计算机程序从一种计算机语言转换成另一种计算机语言，改变软件的某些处理步骤，更换变量名或者插入某些注释语句，都属于对软件的演绎。鉴于软件的实用性的特点，增加、减少或者改变软件的功能、性能也是一种演绎。”有些情形下，贡献者在开放源代码基础上进行修改或二次开发可能形成一个新的独立的派生作品。有学者强调，“若用户新创作的软件满足著作权法中作品的构成要件，则其可以被视为派生作品或者演绎作品”。关于这个问题，2021年，德国卡尔斯鲁厄高级地区法院在一典型案件判决中也作了这样的认定：当一款现有的程序得到独创性的后续开发时，根据具体情况，原始程序员和后续开发的程序员可能会共同拥有对修改程序的著作权，这个程序被视为一个完整的作品；或者，在原始程序员对原始程序享有著作权的同时，后续开发的程序员可能会对其创作的后续开发内容享有自己的著作权。合作作者身份的前提是有统一的创作，这需要创作者有相应的自然行动意愿。诚然，在本案所讨论的分阶段贡献的情况下（由其原始作者创建WordPress，再由原告的程序员改编），不排除合作作者的可能性；但是，前提是每个参与者都在遵从共同的总体思想的情况下作出了（独创性的）贡献。如果因为后续的补充和改进并未包含在原始程序员的行动意愿中，那么必须否认所有参与的创作者的合作作者身份。在此，需要考虑的是程序员进行补充和改进时的自然行动意愿。如果程序员的后续开发仅仅是改编，与WordPress原始程序员并没有共同创作的意愿，那么修改程序上就不会产生两个程序员团队的共同著作权。

（二）原告适格性

（1）涉案作品属于合作作品的，项目管理人单独作为原告的主体资格适格。依据著作权法实施条例第九条规定，合作作品不可以分割使用的，其著作权由各合作作者共同享有，通过协商一致行使；不能协商一致，又无正当理由的，任何一方不得阻止他方行使除转让以外的其他权利，但是所得收益应当合理分配给所有合作作者。贡献者虽为合作作者，但依前述规定，其不能阻止项目管理者起诉维权。在前述德国案例中，法院同样认定，依据《德国著作权法》第8条第2款规定，每个合作作者均有权不受其他合作作者的影响行使禁令请求权。至于单个合作作者是否可以向第三方授予其合作著作权的（专有）使用权，在此并不重要。（2）涉案作品属于改编作品的，项目管理人依协议文本可以单独作为原告起诉。在此情形下，项目管理人或初始授权人有权依照开源许可协议或者与贡献者签订的单独贡献者许可协议享有控制或管理贡献者修改的内容，包括单独起诉维权。（3）承认项目管理人适格的原告资格，便于积极有效维权，降低维权成本，打击侵权行为，维护开源生态安全，促进软件产业健康发展，增进社会福祉，因而具有法律、价值理念上的合理性、正当性，特别是在贡献者人数众多或无法确定的情形下。（4）对贡献者权益的保障。笔者认为，从理论逻辑、制度设计和操作层面上说，无论是合作作品抑或演绎作品，允许项目管理P10人作为原告单独起诉，并不排斥贡献者基于自己的独创性贡献部分对他人侵权行为行使禁令请求权等救济，尤其是贡献者在开放源代码基础上进行二次开发或作较大实质性修改而形成新的独立作品的情形。同时，在确定赔偿数额时，需要考虑项目管理人与贡献者对涉案软件作品形成及其价值的贡献程度。如果贡献者是具体确定的，且项目管理人与贡献者的贡献程度也能够确定，则可以按照确定的贡献度认定侵权人对原告项目管理人的赔偿数额。如果不能确定各自的贡献程度，可以在判决书中明确，判定侵权人先行向原告项目管理人赔付，贡献者乃至在先代码著作权人若对涉案软件的著作权归属或权益分配存在争议，可另行向项目管理人主张。

三、相对性原理的适用

开源许可证对项目管理人及后续用户、贡献者等均有约束力。若项目管理人或在开放源代码基础上进行修改、二次开发形成派生作品的用户违反GPL等许可证协议设定的义务，如未开放源代码等，其对第三人未经其许可复制、修改、发行、信息网络传播其二次开发的软件作品，侵害其软件著作权的行为是否有权起诉维权？已有判决曾反映出两种不同思路。一种观点是适用“不洁之手”或“毒树之果”原则，认为原告起诉主张被告擅自使用其作品的行为构成侵权，但其自身首先应当规范使用开源代码，遵守开源协议，并证明自身权利的正当和合法。原告违反GPL协议要求其提供相应源代码的义务，构成违约，导致原告基于GPL协议获得的许可自动终止，原告无权对原GPL开源代码继续使用，其无权再起诉第三人侵权。如果认定其他行为人构成软件著作权侵权，即会保护原告的不当行为带来的利益，势必赋于其特殊法律地位和特别商事利益，不符合公平、诚信原则。对原告违反GPL协议的行为给予侵权法上的保护，势必虚置GPL协议关于源代码持续开源的相关规定，对于通过GPL协议让源代码持续开源传播产生不利影响。“不洁之手”原则系学理上的一个概念，并非法律规范明确规定的一项原则，是英美普通法领域中的一项古老规则，它强调对清白正直、诚信善良主体进行保护，对双方行为予以限制，意曰进入法庭之人需双手洁净，不洁之手入法庭者不得救济。意即向法庭提起诉请的人不仅需要证明自己有正当合理的诉讼理由，而且需保证自身清白可信。另一种观点适用相对性原理，如在网经公司诉亿邦公司、刘某等侵害计算机软件著作权纠纷案中，一、二审法院认定，即便假定涉案权利人因违反GPL2.0协议导致涉案软件存在权利瑕疵，该假定瑕疵亦不影响其在本案中针对被诉行为寻求侵权救济。在软件尚未被开源、该软件著作权人认为其软件不受GPL2.0协议约束、被诉侵权人则依据GPL2.0协议提出不侵权抗辩的侵权纠纷中，软件开发者自身是否违反GPL2.0协议和是否享有软件著作权，是相对独立的两个法律问题，二者不宜混为一谈，以免不合理地剥夺或限制软件开发者基于其独创性贡献依法享有的著作权。法院特别指出，本案最终认定被诉行为构成侵权并支持涉案权利人的部分诉请，并不表明该涉案权利人将来在潜在的违约和/或侵权之诉中可免予承担其依法应当承担的违约和/或侵权责任。

从域外司法实践来看，德国卡尔斯鲁厄高级地区法院在前述二审案件中明确适用相对性原理，支持了原告的请求。法院认定，原告违反GPL许可协议导致其丧失使用、修改原始开源软件的权利，但不论其二次开发的程序依据德国著作权法是构成合作作品还是改编作品，其均有权进行维权，且原告自身侵权行为并不能使得第三方可以未经其同意披露二次开发程序的源代码。在这里，法院将原告二次开发程序构成对原始开源程序的侵权和被他人侵权视为两个独立的法律问题分别审查评判，在二次开发者诉他人侵权时未考虑其是否违反了GPL协议规定的义务，同时法院也未评判原告作品是否构成原始GPL开源软件的衍生作品或构成独立作品。

该问题的核心是非法演绎作品能否产生受保护的著作权并有权针对第三人的侵权行为请求法律救济。长期以来，学术及实务领域对此虽有争议，但大多持肯定态度。“关于非法演绎作品的著作权保护问题曾存在不同的判定，承认其可版权性的案例占多数，理论界的主流观点也倾向于此。……域内外对于非法演绎作品著作权保护的态度是积极的。”“对非法演绎作品给予保护，契合我国著作权法平衡创新与竞争、赋权与限权、保护与传播、独占与共享的基本机理，避免因著作权对原作品过度保护而导致智力成P11果被压箱底，后续演绎创作的源头枯竭。……有利于激发社会公众的创新热情。”有观点在指出只要演绎者付出了创作性劳动，演绎者就能主张著作权的同时，进一步认为应当对其著作权予以限制，即演绎者不能许可他人使用。在设易公司与望拓公司侵害著作权及不正当竞争纠纷案中，原告未经案外2D作品著作权人许可，将2D作品改编成3D作品，现其针对擅自使用其3D作品的侵权人提起诉讼。法院认为，未经原作品权利人许可而对在先原作品进行演绎改编，侵犯了原作品权利人的著作权。但创作人仍享有该演绎作品的相关著作权，有权禁止他人未经授权使用其演绎作品，并请求赔偿损失。在确定具体赔偿数额时，法院应当区分原作品与演绎作品之间不同作者的独创性贡献，并根据演绎作品独创部分及其对市场价值和公众欣赏体验等方面的贡献程度，合理确定演绎作品作者所能获得的赔偿数额。

笔者完全赞同在开源软件著作权侵权纠纷案件审理中适用相对性原理，因为从本质上说开源创新生态倡导自由、开放、共享的精神理念，并不意味着权利人已放弃权利，也不意味着权利人不能对他人的侵权行为进行维权救济，这只是一种特定情形下的著作权许可合同方式。而且，如前所述，项目管理人与后续用户、贡献者之间是在遵守开源许可证条件下的合同法律关系，二次开发者是否违反GPL协议，带来何种法律后果，自然应当依据合同相对性规则，通过另案审理确定其是否应当向合同相对方原始开源软件著作权人承担违约或侵权责任。二次开发者与涉案侵权的第三人之间是另一法律关系，侵权人对二次开发者承担侵权责任并不免除二次开发者因违反GPL协议所应负的责任。从这个意义上说，这里适用的相对性原理是GPL协议在合同法上的相对性规则在涉案侵权法律关系中的延伸。特别是在被诉侵权后，侵权人不仅不深刻反省与检视其行为违法、非正当性，愧疚其行为给二次开发者带来的不便与损害，并立即停止侵权行为，给予赔偿或协商解决争议，反而极力辩驳指责权利人或受害人的违规或瑕疵，这本身就是不诚信、缺乏正义观的，不应当被提倡。裁判者应当主持公道，不应当受其干扰与牵引，去审查权利人未经许可、非法演绎等方面的瑕疵，而应当将重点放在打击侵权，及时制止侵权行为持续，以免给二次开发者造成难以弥补的损害，这才是积极向善向上的、妥当的、正义的，也是经济的。这样处理也有利于激发创新活力，严厉打击侵权，净化创新生态，推动社会诚信体系建设。法院在网经公司诉亿邦公司、刘某等侵害计算机软件著作权纠纷案中的判决思路，给软件开发者吃下了“定心丸”，较好地促进了开源软件产业的创新发展。同时，在计算侵权损害赔偿额时，还应当根据比例原则，着重考虑二次开发的有独创性表达部分在整体软件作品中的所占比例，合理剥离软件中已开源部分对软件价值产生的贡献。此外，如何准确看待非法演绎作品、权利瑕疵以及“不洁之手”原则的适用等问题，笔者认为，应当本着激励创新、诚实守信、公平效率等原则，区分不同情形作相应对待：一是区分程序性瑕疵与实体上整体不应当保护情形。一般而言，程序性瑕疵涉及相关主体或其财产未经行政审批、登记等手续。这并不影响当事人享有的民事权益保障。如锅炉生产企业未取得安全生产许可证等行政审批、许可手续，但并不能因此否定其付出对价与努力、正当开发的客户信息作为商业秘密受保护等民事权益。在符合商业秘密构成要件的前提下，企业有权对侵权行为请求救济。对于当事人基于其恶意申请获得的专利、抢注取得的商标或字号等知识产权，具有先天缺陷，其本不应当获得、也不应当给予保护，在相关客体被第三人擅自使用时，所谓的权利人自然不能通过维权获得保护。二是区分成果是通过自身诚实创新产生还是不劳而获取得。对于在他人成果基础上自己开发完成的技术成果，包括计算机软件，即便存在未经原始权利人许可的瑕疵，也宜承认其就独立开发部分的成果享有知识产权并获得保护，以激励技术创新、产业创新，推动社会发展。对于通过抄袭、偷窃、掠夺他人成果而产生的对象，坚决不予保护并对行为人予以制裁。

四、GPL协议传染性的认定

GPL许可协议具有高传染性。在具体案件中涉案作品间是否受到传染、是否属于不受传染的独立作品等是实践中的争点难点。个别情况下，不同法院针对相同事实、相P12同作品认定是否受到传染的结论截然相反。GPL3.0版本第5条第2款明确，一个受保护程序和其他独立程序的聚合体，在既不是该程序的自然扩展，也不是为了生成更大的程序，且聚合体和产生的版权未用于限制聚合体用户的访问或超出单个程序允许的合法权利时，被称为聚合体。包含受保护程序的聚合体并不会使本许可应用于该聚合体的其他部分。据此理解，GPL协议允许在聚合体中受GPL协议约束的程序与不受GPL协议传染的其他独立程序并存。GPL许可证官方网站对此作了解释：究竟怎么区分是两个独立的程序，还是一个程序的两个部分呢？这是一个法律命题，最终会由法官来决定。合理的标准既依赖于通信的机制（exec、pipes、rpc、共享地址空间的函数调用等），也依赖于通信的语义（交换了什么样的信息）。由于传染与否的认定涉及计算机程序间的通信等内容，具有较强的技术性、专业性，前述解释仍显得抽象、模糊。笔者认为，法院在具体案件审理中，应当依据GPL协议文本内容及其官方解释关于传染性标准的认定思路来查清事实，并借助技术调查官或技术专家来帮助解决这一难题。结合GPL协议文本内容以及相关案例进行分析，可以综合考虑以下因素来考量相关作品是否受到GPL协议的传染：

（一）派生因素。对在逻辑上与开源代码有关联性且整体发布的派生作品，只要其中一部分采用GPL协议发布，则整个派生作品都必须受到GPL协议约束。开源代码的修改版、扩展版自然受GPL协议约束。

（二）模块间的连接关系。如果两个模块都包含在同一个可执行文件里，则它们一定是同一程序的组件。如果两个模块运行时是在共享地址空间连接在一起，那么它们几乎也构成一个组合软件。如果两个程序组合在一起实际变成了一个程序的两个部分，就不应当被视为两个独立程序，GPL必须涵盖到整个系统。

（三）整体发布。GPL2.0文本第2条第2款明确，如果该作品中某些可区分的部分并非派生自本开源软件程序，并可以被合理地看作是从中分离的独立作品，则当你将它们分开发布时，这种独立部分可以不受本协议约束。但是，在你将这些部分和你基于开源代码修改后的作品一起发布时，整个套件将受本协议约束，本协议对其他许可获得者的授权将延伸至整个作品，即套件的每一部分，不管是谁写的。

（四）隔离与通信机制。如果两个程序隔离得很好，可以视其为两个独立程序，正如编译器和内核，也如编辑器和Shell。根据GNU官方网站发布的解释，pipes、sockets和命令行参数通常是两个不同程序通信的机制，如果使用它们来通信，这些模块正常应该是独立的程序。但是如果通信的语义非常密切，交换复杂的内部数据结构，那么它们也会被认为是一个大程序的两个组合部分。关于主程序与插件的关系，如果主程序使用fork和exec调用插件，它们之间通过共享或来回传输复杂数据结构而建立了密切的通信，它们就是一个单一的组合程序。如果主程序使用的是简单的fork和exec调用插件，二者并没有建立密切的通信，那么插件就是一个单独的程序。如果主程序动态连接了插件，而且它们之间互相调用函数并共享数据结构，可以认为它们构成了一个单一的组合程序，必须将其视为主程序和插件的扩展。如果主程序动态连接了插件，但是它们之间的通信限于使用某些选项来调用插件的“主”函数并等待其返回，那么这可以算单一组合程序也可以算两个独立程序的临界情况。在未来公司与云蜻蜓公司、刘某侵害计算机软件著作权纠纷案中，涉案软件包括主程序和预览程序，法院分别分析了二者与开源程序间的通信机制，最终确定主程序受到传染，而预览程序不受传染。法院认为，判断GPL协议所能传染的衍生软件或修订版本，区分开源代码与自有代码，即确定自有代码是如何与开源代码结合或交互是前提。另外，应结合代码的使用场景，即结合代码的功能及其在软件中所起的作用进行判断。被传染的部分应当是与原开源软件形成密切通信使得二者高度牵连融合成一体的程序，而非只要有数据交换就会构成传染。涉案开源代码存放于源代码中的FutureZR目录下多个文件中。虽然主程序中的主文件RibbonMainForm.cs仅调用1次FutureZR.cs中的CompressZip()函数，主程序与CompressZip()函数之间数据结构传递关系亦较为简单，但在主程序与涉案GPL开源代码存在函数调用关系的情况，涉案GPL开源代码实现的压缩功能系投标文件上传前不可或缺的功能。因此，主程序系涉案GPL开源代码的衍生作品，受GPL协议的约束。而预览程序与主程序相互独立，预览程序在脱离主程序后，预览程序、主程序都能够独立运行，故预览程序不是涉案GPL开源代码的衍生作品，未被GPL开源代码传染。P13

（五）程序的功能与作用。考察两个程序在功能上的相关性，验证终止执行某个程序对另一程序的功能、作用、运行是否产生实际影响。在不乱买公司与闪亮时尚公司侵害计算机软件著作权纠纷案中，涉案软件包括前端代码与后端代码。法院认为，前端代码一般是用户可见部分的编码，用以实现操作界面如页面布局、交互效果等页面设计；而后端代码一般是用户不可见部分的编码，用以实现服务端的相关逻辑功能。前端代码与后端代码是可以分别独立打包、部署的。前端代码与后端代码在展示方式、所用技术、功能分工等方面均存在明显不同，不能因前端代码与后端代码之间存在交互配合就认定二者属于一体，原审法院认定前端代码与后端代码相互独立并无不当。在2007年法国首例开源案中，法院认为，尽管被诉侵权软件Baghera并非衍生自开源软件JATLite，但前者依赖后者才能发挥作用，因而不能被认为是独立软件而不受传染。被告将开源软件纳入商业软件中但未遵守GNU/GPL许可证进行分发，构成对许可证的违反。

结语

开源软件创新生态对于汇聚群贤、攻克技术难关、降低软件开发成本、激励创新活力、推动成果共享、造福人类起到极为重要的作用，但其伴生的风险需引起我们高度警惕。最大的风险为安全漏洞风险，如项目管理人有意在其仓库中添加有毒有害代码，用户或不法之徒对AI开源大模型恶意“投毒”，以及可能存在数据泄漏、数据滥用等问题。“一旦开源软件产生安全漏洞，相较于专有软件，其危害范围、程度和速度更甚。”据媒体报道，股市“黑嘴”们及幕后的不法之徒，用虚假语料误导大模型做出错误回答，再将这些“AI答案”传播扩散坑骗散户，以干扰甚至操纵个股的市场交易。近期已有慈星股份、华胜天成、并行科技、诚迈科技以及三六零在内的5家上市公司被“黑嘴”盯上，成为AI问答截图中的主角。我国开源软件创新产业以及开源社区建设起步晚，存在着开源合规及风险管理意识弱、安全防范水平低、开源人才严重短缺、开源制度供给不足、知识产权法治保障研究不够等问题。为此，开源软件行业协会、开源软件基金组织以及自主创新企业应当强化企业的安全风险意识，加强安全防护措施，提升“防火”能力。企业应当根据项目需求、特别需要保密的源代码以及开源未来前景的战略性考量等因素慎重选择采用宽松式（如MIT）许可证模式还是强传染性协议（如GPL），并隔离核心代码以避免开源义务。建立健全严格的数据管理、代码审查、模型验证、社区协作和侵权举报机制。政府有关部门应当平衡开放、创新与安全三者的关系，高度重视开源软件创新生态建设与社区治理，尤其是安全隐患的防范，加强知识产权法治保障，借鉴欧盟“漏洞赏金”计划，对发现缺陷的工程师提供奖励，以及时识别、清理开源软件的漏洞，通过多管齐下，各方共同推动创新企业建立全生命周期的合规体系，努力让开源模型做到既开放又安全，以实现开源生态健康、可持续发展。P14