正文
最高人民法院在罗盒公司诉风灵公司、腾讯公司等侵害计算机软件著作权纠纷案判决中明确认定，用户在许可证下复制、修改或再发布源代码，通过行为对许可证作出承诺，同时许可证发生法律效力。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的合作作者。
