集慧智佳对开源知识产权问题一直进行持续的跟踪和研究，感谢开放原子开源基金会，高级咨询师付钦伟有幸能够借此发表我们的粗浅看法，特转发相关文章，以飨读者。
【编者按】在开源软件漫卷全球，开源商业蓬勃发展的今天，如何合法合规地使用、修改、发布、运营开源软件，已经成为不少企业和开发者拥抱开源前的核心顾虑。有鉴于此，小编特邀开源行业内专家撰稿，对开源相关一系列知识产权与合规问题进行法理剖析和实务指导，以尽可能消解大家对开源的迷惑、误读及非必要的担忧，推动开发者们携手共创开源天地。
【简介】开源软件取得的巨大成就不仅改变了软件产业格局和商业模式，其独特文化和运营机制也对IT产业甚至社会产生了深远影响。刚结束的第十届中国云计算标准和应用大会，笔者有幸参加了由北大周明辉教授主持的开源知识产权分论坛，与多位前辈、老师一起分享开源治理中的一些感悟。鉴于有些问题对于开源治理和开源司法实践都有很好的参考意义，笔者将自己的思考整理、撰写成文，希望对大家理解开源有所帮助。不妥之处，期待各位老师、朋友批评指正，共同推进国内开源软件的发展。- 贡献者贡献给开源项目的代码，其著作权是属于管理开源项目的组织吗？
- 许可证所授予使用者的权利来自于谁，或者说许可人是谁？
- 例外声明是如何实现，同一个软件双许可的逻辑是什么？
以上这些困惑，都源于对著作权归属与权利许可[1]的内在逻辑没有完全理解。而之所以难以理解，是因为开源软件与传统专有软件不同，专有软件有明确的开发者/组织，有明确的商业软件使用协议，有明确的权利义务说明等。开源软件这种共享、共建的开发模式，宽松、开放的授权模式，使得曾经商业软件中上述明确的问题变得晦涩。要搞清这些问题，我们只需要理解代码的原生作者、开源软件著作权归属，以及著作权授权的内在逻辑即可。开源软件著作权归属问题是一个“根本性”的问题，因为它是开源软件的“权利之源”，是整个开源运动上层建筑的基础。关注代码原生作者的目的，不在于区分谁写了哪些代码，而是理解基于代码原生作者，衍生出来的权利归属问题以及在代码共享中权利处置问题。在《许可证法律地位及司法实践》[2]中已经阐述，开源软件的作者或其雇主（以下统称著作权人）理所当然拥有软件作品的著作权，理论上每一段完整的代码都有其原生作者和著作权人。为表述方便，本文不区分职务作品，后续的讨论中原生作者包含以雇员为代表的单位[3]。以我国为例，根据《计算机软件保护条例（2013 年修订）》第9条，软件著作权属于软件开发者……。第10条，由两个以上的自然人、法人或者其他组织合作开发的软件，其著作权的归属由合作开发者签订书面合同约定。无书面合同或者合同未作明确约定，合作开发的软件可以分割使用的，开发者对各自开发的部分可以单独享有著作权；但是，行使著作权时，不得扩展到合作开发的软件整体的著作权。合作开发的软件不能分割使用的，其著作权由各合作开发者共同享有，通过协商一致行使；不能协商一致，又无正当理由的，任何一方不得阻止他方行使除转让权以外的其他权利，但是所得收益应当合理分配给所有合作开发者。《中华人民共和国著作权法（2020 修正）》第14第1款，两人以上合作创作的作品，著作权由合作作者共同享有。没有参加创作的人，不能成为合作作者。在不考虑软件领域特殊性和复杂性的前提下，从简处理著作权归属的问题：如果是单一的组织或个人开发的开源软件，其开发者就是著作权人；如果是多个组织或个人分别开发了各自的模块共同组成了一个完整的开源软件，每个模块的开发者就是该模块的著作权人；如果是多个组织或个人协作完成了某一开源软件，且又不属于上述模块的形式，属于“合作作品”（开源软件复杂的著作权构成，下一篇还会继续讨论）。针对特定开源软件，无论规模大小，若面向全球开发，除由单一组织或个人开发的模块外，法律上应当视为合作作品，且大部分此类作品不能分割使用。开源许可证以及下面讲的贡献者协议就是“合作开发者签订的书面合同约定”，且绝大部分许可证和贡献者协议都不涉及著作权转让。以Apache许可证为例，Apache 2.0对授予使用者的权利进行了明确规定，甚至允许闭源、允许变更许可证，但必须保留知识产权声明，很明显被许可人从来不曾取得过贡献者的知识产权。主流开源许可证没有例外，都不会剥夺贡献者的知识产权，即只有知识产权的授权，不存在知识产权的转让。实践中，宽松型（permissive）许可证由于授权范围很大，让被授权者产生拥有了软件的知识产权所有权的错觉。Copyleft许可证则不然，授权的同时明确保留一些权利，甚至附加一些条件。正是Copyleft许可证这种既全面又有保留的授权，使得Copyleft软件既能够实现共享、共建，又能实现对这种共享机制的控制。由于开源软件许可证对著作权授权的全面性和不可撤销性，著作权人基本上与一般用户没有什么不同，但在一些关键的问题上，如不兼容许可证的升级、终止授权、维权等，依然具有决定性作用（后续文章关于 license的选择还会进一步讨论）。Copyleft许可证不允许变更许可证，但特定情况下必须修改/升级许可证怎么办呢？这一问题在GPL2.0和EPL1.0升级时已经发生过。由于GPL2.0与GPL3.0不兼容，EPL1.0与EPL-2.0 with Secondary License也不兼容，一个开源软件要从GPL2.0变更为GPL3.0，或者从EPL1.0变更为EPL-2.0 with Secondary License，一般用户和部分权利人是没有这个权利的。除非你是该开源软件的唯一开发者或组织，否则你就必须获得该软件代码的全部著作权人的同意，这也是后续要讲的CLA（Contributor LicenseAgreement，包括个人版ICLA和企业版 CCLA）和SGA（Software Grant Agreement）存在的意义。开源项目的原始著作权人、基金会与开源项目，他们之间是怎么样的一种关系呢？若个人、组织或基金会作为原始开发者开发了某一软件，开发者便自然拥有了该软件的著作权。若原始开发者选择开源其作品，其便成为原始贡献者，且有权选择或者制定许可证。同时为了接受其他开发者贡献的代码，更好的对该开源软件进行管理和控制，原始贡献者可以让开发者签署贡献者协议，比如CLA和DCO（Developer Certificate of Origin）等。比如Apache基金会[4]、Google[5]、阿里巴巴[6]等多使用的是CLA，Linux基金会和Eclipse基金会使用的是DCO协议[7]。DCO主要是让贡献者对自己提交代码的行为做“原创声明”，确保自己可以且有权提交代码。CLA在此基础上更像一个授权协议，贡献者授权项目的主导者（原始贡献者/管理者/基金会等）为了项目发展的需要，管理、控制开源软件。当然，并非所有的公司或组织都会采用上述的CLA和DCO，有的企业或组织更倾向于通过知识产权转让取得更强的控制力。比如GNU针对自己主导的部分项目，为了方便对开源软件的管理和后期维权，要求贡献者“转让”知识产权所有权。如，在2011年7月之前，Canonical（Ubuntu）公司使用Canonical Contributor Agreement 2.5协议规定，贡献者要将现在或未来取得的著作权在世界范围内转让（assign）给Canonical公司[8]。2011年7月之后，变更为Harmony contributor agreements协议[9]，协议变化如下：2.1 Copyright License[10]
(a) You retain ownership of the Copyright in YourContribution and have the same rights to use or license the Contribution whichYou would have had without entering into the Agreement.
2.3 Outbound License
Based on the grant of rights in Sections 2.1 and 2.2, if We include YourContribution in a Material, We may license the Contribution under any license, includingcopyleft, permissive, commercial, or proprietary licenses. As a condition on theexercise of this right, We agree to also license the Contribution under theterms of the license or licenses which We are using for the Material on the SubmissionDate.
Canonical公司的旧协议和新协议的区别在于：旧协议是著作权转让协议，新协议是著作权许可协议。有些基金会接受捐赠的开源项目，即项目原始贡献者或当前管理者将开源项目控制权交给基金会，并按照基金会的管理制度进行管理。如Apache基金会开源软件孵化器（The Apache Incubator[11]），从孵化器毕业的项目可以成为顶级Apache项目(TLP)。开源软件这种宽松、开放的授权模式，协作式的开发模式，使得原始贡献者只能通过CLA、自身强大的技术实力或个人威望有限的控制、主导项目的发展。基金会管理这些捐赠来的项目，如果没有有效的控制力，出现狗血事件也并非不可能。因此，针对企业捐赠者，需要和Apache基金会签署正式的SGA或CCLA协议；针对个人捐赠者，需要签署ICLA或SGA协议[12]，便于基金会进行管理、控制和标准化。不过，上述CCLA、ICLA 和SGA依然属于著作权授权/许可协议，不涉及知识产权转让[13]。不过，捐献给Apache基金会的项目，虽然不存在知识产权转让，但Apache基金会通过SGA协议获得了使用、管理、控制捐赠项目所必须的法律支撑，保证了自身所有活动的正当性和合法性。CLA、SGA所追求的是项目本身的控制权，即项目不受任何人（包括原始贡献者）干扰，确保项目共建、共享有全面的法律保障。因为是授权/许可协议，也就意味着，著作权人自身并没有丧失原本拥有的权利。理论上，捐献者依然可以保留其独立的开发工作，作为两个项目并行，与孵化的项目竞争（当然，这样其捐献的意义也不存在了）。需要强调的是，将项目捐赠给Apache基金会，意味着捐献者放弃了对该项目及其商标（如果有）的控制权。捐献者除了可以成为该项目管理委员会（PMC）的成员之外，没有其他任何特殊地位。而且，为管理、运营项目的需要，捐赠项目的有关商标需要在项目毕业之前转让给Apache基金会。以上讲了很多，但没有涉及到开源许可证的制定者。以Apache 2.0为例，其制定者是Apache基金会，也是开源项目的潜在受捐赠方，同样也是部分开源项目的发起者。如果针对某个开源软件，排除了这三种角色，单纯作为许可证的制定者，其扮演什么角色呢？基本上什么角色都没有，唯一值得着重说明的是他们是其所制定的许可证本身的著作权人。如果制定者/组织有足够的影响力、能获得社区的认可，还能附带的具有解释其许可证，甚至充当协议纠纷仲裁者的角色，当然这建立在其自身的可信赖性基础上。比如FSF（Free Software Foundation）[14]，其自由软件理念鲜明的价值追求，获得了广泛的认可，包括Copyleft开源理念。不过，这种信赖是自愿的，理论上任何著作权人可以选择信赖某一个许可证及其组织，也意味着随时可以收回信赖。FSF作为自由软件运动的旗手，Copyleft理念的捍卫者，同时积极参与/支持涉GPL的诉讼、进行GPL执法，这是其他许可证制定者不曾拥有的信赖和地位。（1）贡献者协议的意义是什么？
或许你会疑惑，许可证本身包含贡献者的授权条款，为何还需要 CLA、SGA这类协议呢？这个问题也曾因Canonical修改其CLA有过讨论[15]，Linus也难得没有爆粗口，平静的发表过观点[16]，也有开源组织因要不要用DCO取代CLA有过激烈的讨论。对于一个松散的、完全协作方式开源的软件来说，DCO足够，若是采用Apache 2.0、MIT等主流许可证，甚至不需要CLA、DCO之类。但这种方式开源的项目也存在一个问题：过于复杂的著作权组成，没有任何个人/组织有足够的权利可以控制该软件，这是否是一件好事呢？按照开源理念，纯粹的开源软件本就不需要中心化的控制者，但当需要修改许可策略、更换许可证、给予例外声明等带有处分意义的行为时，这种完全松散权利模式就陷入尴尬。如果你想深入感受这一点，可以看看ZeroMQ征集贡献者的批准将libzmq库的许可证从LGPL 3.0变更为MPL 2.0的例子[17]，你可能会深刻理解“凡事都有两面性”。对于开源许可证，Apache 2.0和MIT许可证有明确的授权内容条款，而BSD虽然也属于宽松型许可证，但并没有对授权内容进行明确说明。而MPL和GPL许可证，虽然有关于授权内容的明确说明，但其本身不允许修改许可证。因此，CLA和 SGA对于类似Apache 2.0和MIT许可证的项目来说只是法律风控的需要，但对采用BSD及Copyleft许可证的项目就显得特别的重要，尤其是那些采取多许可策略的项目，项目的主导者需要获得明确的权利授权来实施其许可策略。与以松散协作方式开发软件不同，由基金会、商业组织、特定软件社区等主导的开源软件，CLA这类协议使得项目的主导者更够更好的管理软件的开发工作。对比CLA、SGA和许可证可以发现，授权协议的内容基本相同，以Apache基金会CLA中著作权授权条款为例：Grant of Copyright License. Subject to the terms and conditions of thisAgreement, You hereby grant to the Foundation and to recipients of softwaredistributed by the Foundation a perpetual, worldwide, non-exclusive, no-charge,royalty-free, irrevocable copyright license to reproduce, preparederivative works of, publicly display, publicly perform, sublicense, and distribute YourContributions and such derivative works.
上述条款其实就是宽松型许可证Apache 2.0中的著作权授权条款，也就是说，对项目主导者（基金会、商业组织、特定软件社区）来说，无论贡献的项目采用哪种许可证，贡献者授予他们的权利都是范围最大、最宽松的。贡献者保留了知识产权所有权，被授权者获得了支撑开源项目运营、管理所需要的“全部法律层面的支持”，包括有权再许可或变更许可证（sublicense/relicense）。所谓授予的权利范围最大、最宽松，体现在被授权人除了不具有署名权，获取的著作权不具有排他性，其他和权利人基本无异。
既然是授权，著作权人在著作权法范围内，依然可以行使自己的权利，只要不影响其原本已经授权给别人的那部分代码。著作权人基本上不能收回其授权，仅能在CLA、SGA及部分许可证授权协议本身的撤销授权条件成立时，撤销原本的授权，即被许可人违反了授权协议本身。即便是这种苛刻的撤销授权条款，还只针对违约者，而非全部被授权人。
正是由于开源授权的特点，不同于传统知识产权领域所谓的授权许可，很多人对开源软件和许可证的授权内在逻辑感到费解甚至闹出各种“翻车事故[18]”。正所谓，选择了开源就选择了奉献，毕竟共享、共建、共赢是开源的灵魂。但是，类似CLA、SGA等协议，他们并非开源的内核，而是随着开源项目的运营、管理需要产生的。签署CLA其实是把信任给了被授权者，信任他们是开源的捍卫者，他们不会违背开源精神。但信任嘛，你懂的。还有更多的社区是以企业为主导的，会因为各种原因偏离这种精神，如MongoDB许可证修改事件[19]、正在发生的Elasticsearch许可证变更事件（官网[20]和讨论[21]）。综上，开源许可证、典型CLA 、SGA和DCO无一例外，都不涉及知识产权权属的转移。这足以说明开源软件的知识产权从来只属于其原生作者或职务作品的雇主，而非仅仅是这个开源软件的原始贡献者，也非许可证制定组织，更不可能是纯粹的代码管理或平台托管方。开源软件可以认为是多个作品的组合作品或合作开发的作品，其著作权归属于特定作品的创作者或全体代码贡献者（包括职务作品的雇主）。因此，开源软件许可证就是贡献者之间、贡献者与使用者之间的书面协议，贡献者之间成立的是合作开发协议，贡献者与使用者之间成立的是许可/授权协议。CLA、SGA是贡献者/捐赠者与主导者/被捐赠者之间的书面协议，属于合作开发或委托协议。宽松型许可证使得代码共享有了法律上的缘由，Copyleft许可证则巧妙地利用了著作权法来保护贡献者和用户的权利，CLA、SGA则为项目的管理、控制提供的法律支撑。但作为著作权所有人的作者、雇主或其代理人仍然是能够维护和保护用户权利的唯一人选，也是能够行使权利的唯一人选。至此，本文开头的问题，答案就显而易见了：开源代码的贡献者或职务作品的雇主是著作权所有人，拥有处置其权利的最终决定权；而针对许可证违约者的诉讼，由且只能由这些人提出；同时，授予你权利的人也只能是这些人，无论你手里的作品副本来自于谁；最后，能够给软件添加例外声明或者进行多重许可的必须是著作权人或其授权的个人/组织。理解了开源软件中原生代码著作权人和许可证的本质，也就很容易理解另一个问题，许可证权利终止问题。由于每一个接受者，其所获得的授权都直接来源于该软件上的每一个权利人，无论中间经过多少个分发环节。用户享有的权利并不取决于上游提供者是否合规，因为用户的许可证是由版权持有人直接下发的。其次，一旦许可自动终止，即使从其他分发者处再次获取软件也无法恢复权利许可权限，只能由原许可人授予。如果原许可人自动终止了许可，则任何中间许可证持有人，都无法恢复这些已经终止了的权利[22]。【致谢】在此再次感谢大会、论坛组织者及与会的各位老师，特别感谢北京大学周明辉教授对本次论坛主题的思考和引导，这种思维的碰撞才得以让本系列文章得以成文、更加完善。【本文作者】付钦伟，集慧智佳高级咨询师、专利代理人，擅长专利布局、检索分析、专利预警&信息跟踪、FTO&风险分析，对企业开源软件法律风险管控、合规治理有深入研究和丰富经验。[1]不区分授权和许可的内在差异（法律专家手下留情）[2]https://mp.weixin.qq.com/s/_IAE7hmD_jpHv3SwlcvcFQ[4]https://www.apache.org/licenses/icla.pdf[5]https://cla.developers.google.com/clas/new?domain=DOMAIN_GOOGLE&kind=KIND_INDIVIDUAL[6]https://cla-assistant.io/alibaba/weex[7]https://www.eclipse.org/legal/DCO.php[8]https://assets.ubuntu.com/v1/ea46173e-Canonical_Contributor_Agreement_ver_2.5.pdf?_ga=2.224367646.407088395.1608374698-1871685793.1608374698[9]http://www.harmonyagreements.org/index.html[10]https://ubuntu.com/legal/contributors/agreement[11]https://incubator.apache.org/cookbook[12]https://www.apache.org/licenses/contributor-agreements.html[13]http://www.apache.org/legal/src-headers.html[14]SF (Free Software Foundation)，自由软件基金会[15]https://mjg59.dreamwidth.org/29160.html[16]https://news.softpedia.com/news/Linus-Torvalds-Says-All-Contributor-License-Agreements-Are-Broken-418978.shtml[17]https://github.com/zeromq/libzmq/issues/2376[18]https://linux.cn/article-12026-1.html[19]https://www.mongodb.com/licensing/server-side-public-license/faq[20]https://www.elastic.co/cn/pricing/faq/licensing[21]https://mp.weixin.qq.com/s/YIwCxkTCDS08ptVHPKqKyQ[22]来自Free Software Foundation【合作伙伴】开放原子开源基金会是国内首家致力于开源产业公益事业的的非营利性独立法人机构，本着“一切为了开发者 一切为了全世界”的宗旨，为开源项目做好服务，为开源开发者做好服务。
用知识产权的眼光看世界
欢迎原创投稿，稿件一经采用，支付稿费
投稿邮箱：iptree@iptalent.com
看都看了，点个“在看”再走鸭