Open Source
版权向左，开源向右。
RedHat 公司现在由 IBM 拥有，他们的企业发行版附带了许多非自由软件，并且积极地告诉客户如何获得更多收益。他们没有采取任何措施来推广自由软件，而只是将其视为他们可以随意使用的东西。他们最近还杀死了社区支持的 CentOS。这看起来像一家在乎自由软件的公司吗？
– Leah Rowe，评论 RedHat 因为斯托曼重新进入自由软件基金会（FSF）的董事会，而停止向 FSF 捐款。
Why
开发者为什么放弃自己的开源项目？
大部分的开源软件，是个人开发者创建的。其中能够长期维护的少之又少，绝大部分项目最终都会被放弃。
下面是一个不完全列表，列出了开发者放弃自己的开源项目的主要原因。从中你就可以知道，个人维护一个长期项目有多难。
1）该项目是免费的，因此没有金钱激励来让开发者继续工作。
2）使项目跟上最新的技术进展，非常困难和耗时。
3）开发者对这个项目感到厌烦，不想继续做了，因为最早只是出于好玩，或为了学校作业而开发的。
4）项目已经失控，变得太大了，很难维护。
5）该项目的主要用户是不太懂计算机的人，每天有大量的、愚蠢的、缺乏耐心的支持请求。
6）出现了更好的替代方案。
7）开发者之间的摩擦，导致主要贡献者离开。
8）开发者的优先事项，从项目转移到其它事情上面，比如结婚有了小孩。
9）项目的代码质量很差，导致维护和重构困难。
10）开发者决定把项目卖给其他人。
11）一种新技术出现了，使得该项目过时了。
开源软件：保护的智慧
软件开源作为一种经营模式日益盛行，越来越多的企业（特别是平台型的企业经营者）、软件开发者选择将自己的软件通过开源的方式贡献给社区。然而，如同笔者在此前发表的《开源软件：未必免费的盛宴》一文中所述，软件开源常常是一种商业经营模式，而并非免费的盛宴，开源软件的开源方（以下称“开源方”）依然可以结合自己的商业目标，在将软件开源的同时保护自己的知识产权。
一、选择一份合适的开源协议
目前主流的开源协议主要有以下几种：GPL协议、LGPL协议、BSD协议、MIT协议、Mozilla协议以及Apache协议等，笔者在《开源软件：未必免费的盛宴》一文中已经对上述开源协议进行了细致的横向比较，在此不再赘述。了解这些协议设定的不同法律权利和义务，对于企业选择合适的开源协议非常重要。我们总结了如下几个较为常见的考虑因素供读者参考。
商业用途
商业用途是指使开源软件的使用方（以下称“使用方”）是否可以将开源软件及其衍生软件用于商业用途。目前，绝大多数的开源软件都允许开源软件及其衍生软件被用于商业用途。但是，有些开源协议（例如GPL v2.0协议）会规定如果开源方是免费提供开源软件的话，那么使用方在此基础上修改的衍生软件也必须免费提供给公众使用。因此，开源方可以利用这样的条款来限制使用方利用开源方的软件来为自身获取利益。
修改
修改是指使用方是否可以在开源软件的基础上进行修改。目前，大多数的开源软件都允许使用方修改开源软件。但是，开源方同意使用方对开源软件进行修改并不意味着开源方同意将该修改后的软件视为其开源软件的后续版本。例如，谷歌公司的安卓系统是开源的原件，世界上有成千上万的软件爱好者、企业可以对其进行修正并发布为自己的版本，但是谷歌公司安卓系统的版本序列依然是根据谷歌公司自己发布的正式版本来确定的。如果谷歌公司想采纳使用方对安卓系统的修改，则谷歌公司会与使用方另行签署相关协议。
专利授权
专利授权是指开源方是否将与开源软件相关的专利授权给使用方。根据开源协议的不同，专利授权的内容也不一致，有些开源协议（例如GPL v2.0协议）并没有提及专利授权，有些开源协议（例如BSD 3.0 Clause Clear License）明确禁止专利授权，有协议开源协议（例如Apache License 2.0）明确同意专利授权。也有一些公司会根据实际情况，在引用没有提及专利授权的开源协议时，另外增加一个文件专门阐述专利问题。
这对于已经注意通过专利方式保护计算机软件的公司非常重要。因为，开源软件所授予的许可常常超越了某一特定地域。而专利权则具有绝对的地域性保护，仅在被授权的地域内有效。对于希望保留专利权利的公司在选择开源协议是要特别注意两种不同知识产权权利之间的协调。
公开源码
公开源代码是指开源方在分发开源软件时是否必须提供源代码。关于这一点，GPL协议和LGPL协议有明确的规定，要求开源方必须提供源代码。但是，在一些宽松的开源协议中，并没有这样严格的要求，宽松的开源协议仅仅是鼓励开源方对源代码进行开源。
使用相同协议
使用相同协议是指修改后的软件如果继续开源的话是否必须按照相同的协议进行发布，在GPL协议及LGPL协议中包含这样的条款。该条款可以限制开源软件的修改者继续开源时随意选择其他宽松的或严格的开源协议，从而可以保证开源软件的后续修改版本依然可以秉承原始开源方的保护思想。
声明变更
声明变更是指使用方对开源软件的代码进行修改后是否需要对修改的部分进行声明，许多开源方都会选择这样的条款来告知公众原始的部分和修改的部分，以便明确自己的权利范围。在主流的开源协议中，GPL协议、LGPL协议和Apache协议都有要求进行声明变更。
综上，如何选择一份合适自己的开源协议，需要根据自身的实际情况和商业需求。除了由软件爱好者提供之外，有相当一部分的开源软件是由企业提供的。从企业的角度来说，开源软件协议的选择应当从企业的商业目的角度进行考虑。
二、开源软件的知识产权保护
许多开源方可能会有这样的疑问：“既然我已经选择了将软件开源，且已经选择了一份合适的开源协议，那么我是否还有必要或有可能去通过传统的知识产权（软件著作权、专利、商标、商业秘密等）来保护我的开源软件？”笔者看来，既有必要，也完全可行，并从版权、专利、商标、商业秘密等几个方面提出建议。
著作权保护
在上述主流的开源协议中，几乎所有的开源协议都明示或暗示地提及了软件著作权的授权，这和开源软件本身的性质是一致的。但是，开源方依然有必要去申请登记软件著作权，以及通过恰当的技术手段进行软件的版本管理和代码保全。一方面，软件著作权明确了开源方软件的权利范围，即开源协议中所授予的软件著作权就是开源方申请登记的转件著作权；另一方面，也便于厘清开源方原始版本的内容及与后续使用者使用修改后生成作品的区别。在发生如责任承担、侵权纠纷、违反开源协议纠纷等情况下能够提供扎实有力的证据支持。
专利保护
如上所述，不同的开源协议关于专利授权的内容并不统一。然而软件被开源之后，任何人都有可能接触到开源软件的源代码，包括市场上的竞争对手。因此对于开源方而言，积极、合理、有效地进行专利申请与专利布局可谓是与有效的开源协议并举的智慧的保护方式。如果这样，在决定开源的时间点方面就需要考虑与专利申请的时间进程不构成冲突。
商标保护
除了Apache License 2.0明确禁止使用方使用开源方的商标之外，市场上的主流开源协议并没有对商标授权进行过约定。开源方需要充分考虑其整个商业模式的需要以及开源在整个模式中的作用，来考虑恰当的商标授权许可策略。从扩大影响力、强化品牌的角度，要求被许可方使用自身的品牌可以促进开源方的品牌影响力。但同时，如果使用方的后续开发发生负面事件，也会产生对开源方品牌的不利影响。这时，事先考虑周全的商标授权协议安排就显得非常必要。
此外，开源方还有必要将开源软件使用的一些特定标识或名称在正确的商品或服务类别上申请商标，并充分考虑商标申请的地域覆盖，以便搭建完善的品牌资产组合。
商业秘密保护
在开源软件的源代码中，可能会对于一部分核心代码开源方并不希望公开给公众，同时开源方也不希望通过将其内容公开来换取软件著作权或专利权的保护。这时开源方仍然可以对这些部分的核心代码以商业秘密的方式来进行保护。
需要说明的是，各大开源协议是开源行业内已经约定俗成的规则。开源方可以根据自身的需求和商业目的另行添加开源协议中没有规定的内容，例如商标的使用，协议更新等等。具体如何添加，如何起草相关的条款建议咨询有经验的律师或相关法律人士进行处理，以便可以全面地保护自身的合法权益。
结语
综上所述，从开源方的角度来说，尽管选择了软件开源，但并不表示不需要保护自身的合法权益。恰恰相反，为了既可以实现贡献大众或培养生态，又可以防止他人非法、肆意地获取开源方的智慧成果的目的，开源方不仅需要注重开源协议的选取，还需要为开源软件配套一套知识产权保护体系。
开源问题系列探讨之一：许可证的核心诉求是什么？
【本文作者】
付钦伟，集慧智佳高级咨询师、专利代理人，擅长专利布局、检索分析、专利预警&信息跟踪、FTO&风险分析，对企业开源软件法律风险管控、合规治理有深入研究和丰富经验。欢迎对开源感兴趣的朋友扫码加我微信，多多交流
【编者按】在开源软件漫卷全球，开源商业蓬勃发展的今天，如何合法合规地使用、修改、发布、运营开源软件，已经成为不少企业和开发者拥抱开源前的核心顾虑。有鉴于此，小编特邀开源行业内专家撰稿，对开源相关一系列知识产权与合规问题进行法理剖析和实务指导，以尽可能消解大家对开源的迷惑、误读及非必要的担忧，推动开发者们携手共创开源天地。
【简介】
开源软件取得的巨大成就不仅改变了软件产业格局和商业模式，其独特文化和运营机制也对IT产业甚至社会产生了深远影响。在第十届中国云计算标准和应用大会上，笔者有幸参加由北京大学周明辉教授主持的开源知识产权分论坛，和多位前辈、老师一起分享了自己这几年开源实践中的一些感悟。鉴于会议讨论的问题对于开源治理和开源司法实践都有很好的参考意义，恰逢元旦假期，笔者将自己对这些问题的思考重新整理、撰写成文分享给大家，希望能对大家理解开源起到一点帮助。有不妥的地方，也希望学术、法律、企业界的老师、朋友们批评指正，一起讨论、学习，共同推进国内开源软件的发展。
1、为什么需要许可证？
开源许可证要解决的开源知识产权问题，就是知识产权的专有权和代码共享之间的矛盾。主要是著作权，其次也包括商标、专利、商业秘密等。不管是著作权的默认取得，还是专利权、商标权的申请取得，一旦取得即具有专有权，除法律有明确规定外，只要无授权，任何形式的使用都是非法的。在这一法律背景下，开源软件该如何实现其众人皆平等的共享、共建呢？这个问题如果结合自由软件的起源来看，更容易理解。
2、著作权条款是开源运行的基本保证
自由软件之父理查德·斯托曼（Richard Stallman）最初是反著作权制度的，主张代码应该是全人类的智慧，反对软件专有化。但否定著作权无法保障其软件自由理念的实施，后来其转变立场以著作权推进自由软件运动（认识到反对著作权将无助于其理念的实施）。利用著作权制度来反制著作权专有所导致的软件专有化问题，构建其自由软件理想国。
所以，Copyleft许可证本身不反著作权，相反，著作权制度是整个Copyleft软件的法律基础，其将著作权用到了极致，依靠著作权制度保障自由软件的哲学理念。宽松型许可证本质上就是权利人给予使用者的明确授权，使得代码共享有了法律上的缘由。与宽松许可证不同的是，Copyleft的精髓在于防止自由软件的私有化改进，而不仅仅是授权使用而已。如 GPL许可证，利用著作权法制度，实现自由分享的同时，保障这种自由分享状态的延续，这构成了Copyleft许可证的核心法律原则。因此，Copyleft是捍卫、维持和推广软件自由思想的法律策略和机制（注1）。
3、专利条款是一种有限的防御机制
但是，理查德毕竟是自由的斗士，其毫不掩饰对专利权的厌恶。可见，如果著作权制度不是开源许可证的基础，其对著作权制度的厌恶可能与专利制度一样。
开源许可证关于专利权的规定，我认为纯粹是一种无奈，就像GPL 2.0里写的那样：
Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone’s free use or not licensed at all.（注2）
同样是国际通行的知识产权制度，专利制度之于开源软件的影响完全不同于著作权制度。著作权保护的是作品的表达方式本身，代码的创作者就是代码的权利人（注3），可以控制代码的开源与否。但专利制度保护的是作品内在的技术逻辑，代码的创作者和代码对应的专利权利完全是可以分离的。因此，开源社区无法像利用著作权制度来保护开源一样利用专利制度。
最开始，很多开源许可证并没有专利条款，但随着软件专利被大多数国家所认可，且专利纠纷的增多，许可证的制定者不得不思考如何应对专利问题。但是，基于代码的创作者与代码所涉及专利权的可分离性，开源许可证只能以惩罚的方式约束社区内的人，即“背叛者”，而对社区外的第三人一筹莫展。好在开源软件已经无处不在，当大家都在这个圈子里，其实也就可以相安无事了。另外，主流许可证也包括专利防御和惩罚条款，开源社区逐渐学会了抱团取暖、相互支持，以社区的力量来抵御第三人的攻击，也包括在某一领域的抱团组织，如OIN（注4）。
但专利制度，毕竟是世界通行的知识产权制度，特别是大公司在专利的确权与维护上往往花费了巨资，许可证的专利条款不能无限制的放大对专利的许可范围。因此，开源软件的专利条款的制定也考验着每一个开源许可证的制定者。
4、许可证专利条款“有限许可”的理解
目前，主流许可证的专利条款，更倾向于取得一种平衡，即便如Richard 这样的自由斗士，也不得不接受这种妥协，即“有限的许可”。这种平衡，一方面让贡献者让渡了部分权利，另一方面也避免了许可范围的无限扩大，维护了的贡献者自身的权益。从这一点上看，关于专利的规定，所谓自由软件和开源软件理念又走向一致，少了些激进、多了些实用主义。以 EPL 2.0 为例：
1.3：“Licensed Patents” mean patent claims licensable by a Contributor which are necessarily infringed by the use or sale of its Contribution alone or when combined with the Program.
“许可的专利”是指贡献者可许可的专利权利要求，这些权利要求会因使用或销售该贡献者的贡献本身或其与本程序的结合而必然会侵犯的权利要求。
2.2：b) Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive, worldwide, royalty-free patent license under Licensed Patents to make, use, sell, offer to sell, import and otherwise transfer the Contribution of such Contributor, if any, in Source Code or other form.
This patent license shall apply to the combination of the Contribution and the Program if, at the time the Contribution is added by the Contributor, such addition of the Contribution causes such combination to be covered by the Licensed Patents.
本专利许可应当适用于贡献和该程序的结合，如果在贡献者添加贡献时，该贡献的添加导致该组合作品被许可专利覆盖。
The patent license shall not apply to any other combinations which include the Contribution.
本专利许可不适用于任何其他包含贡献的组合。
图中绿色圆柱代表某具体的开源软件，A、B代表贡献者，AP1是A的某件专利，Contribution代表贡献者为开源软件贡献的代码，箭头代码对应的代码被专利权利要求所覆盖，绿色笑脸代表需要许可，红色叉代表不需要许可，“ContributionA-B修”代表B将A的贡献修改后被专利所覆盖。第一种情况是，A的贡献Contribution A与作品（开源软件）结合被A的专利AP1所覆盖，那么 A有义务将其专利AP1给予该开源软件及其使用者相应的专利许可。其它情况类推，具体如上图。
以上之所以以EPL 2.0为例，是因为EPL 2.0的条款写的相对还比较好理解，Apache 2.0以及GPL 3.0的专利条款，要么晦涩难懂，要么繁琐冗长，但基本的涵义大抵相同。可以看出，主流成熟的许可证的专利条款，更多的采取的是实用主义思路，既要保护开源要义，又要考虑贡献者，特别是商业公司贡献者的可接受性。
5、核心诉求还是共享、共建、共赢
综上，开源许可证要解决的开源知识产权问题，就是知识产权的专有权和代码共享之间的矛盾问题。许可证就是一张写满使用者（包括下游贡献者、开发者和最终用户，下游贡献者本身就是最典型、最重要的使用者）权利的声明书，包括著作权、商标权、专利权等。涉及的也是最基本的问题，能不能用、如何用、以及使用的条件和限制。可以说，开源许可证为“开放源代码理念”从无序走向规范、从稚嫩逐步成熟提供了法律保障。也让开发者对共享、共建、共赢的追求有了保障和信心，激发了社区活力。
另外，开源软件的开发也会引起其他知识产权问题，比如贡献者可以是以自己的名义开发，或作为雇员以雇主的名义开发以及由此引发的职务作品问题、商业秘密问题。这些其实都不是许可证要解决的问题，而是公司管理问题。
题外说明：本文，包括后续系列文章都不重点讨论职务作品的问题，如无特别说明，文章提到的贡献者/创作者/开发者代表其个人，符合职务作品的话以雇员的身份代表其单位。
致谢：本系列文章源自第十届中国云计算标准和应用大会—开源知识产权分论坛所讨论的主题，感谢大会、论坛组织者及与会的各位老师，特别感谢北京大学周明辉教授对本次论坛主题的思考和引导，这种思维的碰撞才得以让本系列文章得以成文、更加完善。
【作者注】
1 FSF (Free Software Foundation)，自由软件基金会
2 https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
3 这里不区分职务作品，若符合职务作品的概念，所谓创作者就代表其单位
4 https://www.openinventionnetwork.cn
开源问题系列探讨之二：许可证法律地位及司法实践
【编者按】在开源软件漫卷全球，开源商业蓬勃发展的今天，如何合法合规地使用、修改、发布、运营开源软件，已经成为不少企业和开发者拥抱开源前的核心顾虑。有鉴于此，小编特邀开源行业内专家撰稿，对开源相关一系列知识产权与合规问题进行法理剖析和实务指导，以尽可能消解大家对开源的迷惑、误读及非必要的担忧，推动开发者们携手共创开源天地。
【简介】开源软件取得的巨大成就不仅改变了软件产业格局和商业模式，其独特文化和运营机制也对IT产业甚至社会产生了深远影响。刚结束的第十届中国云计算标准和应用大会，笔者有幸参加了由北大周明辉教授主持的开源知识产权分论坛，与多位前辈、老师一起分享开源治理中的一些感悟。鉴于有些问题对于开源治理和开源司法实践都有很好的参考意义，笔者将自己的思考整理、撰写成文，希望对大家理解开源有所帮助。不妥之处，期待各位老师、朋友批评指正，共同推进国内开源软件的发展。
在上一篇《许可证的核心诉求是什么？》已经讲到：开源的核心诉求是共享、共建、共赢，而开源许可证的核心诉求是支撑前者，即开源许可证为“开放源代码理念”从无序走向规范、从稚嫩逐步成熟提供了法律保障。
本文将讨论开源司法实践中一个重要问题：法律上，许可证的性质是什么？法院是否认可许可证的约束力？开源许可证的法律地位问题的澄清是讨论开源许可证，特别是GPL“传染性”的必要前提。
1、法律上如何看待许可证
从法理层面看，许可证的法律地位问题可以拆分为三个小问题：
（1）开源软件著作权的保护问题
计算机程序（包括开源软件）可以作为著作权保护的客体是毋庸置疑的，《伯尔尼公约》、《与贸易有关的知识产权协议》（TRIPS）、《世界知识产权组织版权条约》等条约为国际间计算机软件版权保护提供了统一的标准和依据，开源软件的作者或其雇主理所当然的拥有开源软件作品的著作权[1]。
（2）开源软件许可证的性质问题
开源软件的作者或其雇主（以下统称“著作权人”）在拥有著作权的同时，也有依法处置的权利[2]，包括以许可协议的方式进行普遍授权，开源软件的许可证是开源软件著作权人采用的格式化的著作权许可或授权协议。
在中国的法律环境下，平等主体之间口头的约定在符合法定条件时尚且可以得到法律认可，更何况白纸黑字写下来的、世界范围内普遍接受的书面许可证协议。
（3）开源许可证的约束力问题
即便上述认定都成立，这样一份书面法律协议，对贡献者和使用者双方是否必然具有约束力呢？笔者在企业开源治理实践中，常有客户问类似的问题：他用了GPL软件，他能不能说自己根本没用明确签署过GPL协议，所以即便法院认可GPL是双方协议，但对他没有约束力。
笔者对此的回答是明确且是否定的。试想一下，你在大街上的自助售货机、无人售货超市里买东西也没有明确签署买卖合同。从更本质上说，你实际使用了开源软件，如果拒绝了许可证，等同于拒绝了使用权的来源基础。这时根本不需要讨论许可证及传染性了，你的使用行为本身就已经侵犯别人著作权。
美国法律环境下应该是区分许可（不需要对方明确的承诺）与合同关系（笔者不太了解美国法律，这里仅介绍Free Software Foundation[3]的诉求，帮助理解该问题），FSF在解释GPL的适用时反复强调，GPL是权利人给予licensee的许可，这种许可是单向的，不需要licensee接受。
在国内，无论是许可还是授权，都是合同的范畴，民法上承认默认的或事实的合同义务，许可证这种授权性质的协议，不需要相对人明确接受，即使是Copyleft这种附条件的授权。不管如何，在国内，许可证作为对许可人和被许可人双方具有约束力的法律协议都不存在法律障碍。所以，不管你形式上是否认可，只要你不是来自原始社会（对开源一无所知，可构成重大误解），从你决定用软件的那一刻（以实际行为默示或事实的承诺），你就是许可协议的相对人。
综合以上三个问题，在权利人具有排他性处分权的前提下，其以明确的书面协议–许可证，行使自己的合法权利，无论如何都应该得到法律的支持。
2、司法实践上如何看待许可证
司法实践中，协议法律效力的认定，是法官的权力。鉴于国内尚没有明确的司法意见，仅有的公开可查的两个司法判决中也没有明确说明。开源许可协议的效力作为一个普遍性的法律问题，以下从惯例和相关判例两方面分析。
（1）国际惯例认可许可证
根据国际惯例，虽然自由/开源软件运动的理念和几乎全部的开源协议都源于国外，但在软件领域和全球的开源社区都默认接受了这样的约定。因此，行业、开源社区及国际惯例应该成为法官在认定许可证效力时考虑的因素。
（2）国内外现有判例同样认可许可证法律效力
在这个问题上，国内外已经或多或少有相应的案例可参考。国内法院虽然没有明确认定或论述许可协议法律效力问题，但在实际判例中已经默认了其具有约束力的事实。
在柚子北京移动技术有限公司等与数字天堂北京网络技术有限公司的民事诉讼案件中，一审、二审法院虽未明确认定GPL许可证的法律效力，但在论述涉案三个插件是否受GPL协议限制时，事实上默认了GPL许可证具有法律约束力，即类似于协议或合同的法律效果。虽然两审法院并未就开源软件以及GPL协议的关键问题进行阐述，也未进一步将GPL协议条款基于我国著作权法进行解释，但确认了开源协议有约束力[4]。判决书可见：（2015）京知民初字第631号，(2018)京民终471号。
不乱买电子商务北京有限公司与北京闪亮时尚信息技术有限公司侵害计算机软件著作权纠纷案件中，一审、二审法院同样确认了GPL许可证的法律约束力。在二审中，最高人民法院结合案件本身对GPL协议的传染性进行了分析。最高人民法院指出，网站前端代码与后端代码在展示方式、所用技术、功能分工等方面均存在明显不同，属于既相互独立又互相联合的独立程序，即便前端代码使用了GPL协议项下的开源代码，后端代码也不受GPL协议约束，未经许可复制后端代码仍构成侵害软件著作权。上述论述给出的明确信息是，最高院认可开源协议的约束力，且根据协议条款进行了适当解释。最高院的解释，基本和开源社区的认识是一致的，这也为国内后续的相关诉讼提供了参考。判决书可见：（2016）京73民初1111号，（2019）最高法知民终663号。
美国相关案例更早，且讨论的也更多一些。2008年，美国联邦巡回上诉法院首次在判决中确认了开源许可证可作为著作权协议。原告Bob Jacobsen 采用Artistic许可证，发布了自己的开源软件，被告Matthew Katzer使用了该软件，但是却未履行许可证中规定的著作权声明义务。最终，被告被认定违反Artistic许可证的行为是侵犯了原告的著作权。Jacobsen v. Katzer[5]案的裁决同时也表明，著作权权利人可以寻求著作权和合同救济，以执行旨在维护软件自由的许可证。
综上，无论是按照法理分析，还是依据国际惯例和现有案例，开源软件许可证都符合民法上平等主体间约束性协议的范畴，理应得到法律的认可和保护。
【致谢】在此再次感谢大会、论坛组织者及与会的各位老师，特别感谢北京大学周明辉教授对本次论坛主题的思考和引导，这种思维的碰撞才得以让本系列文章得以成文、更加完善。
【本文作者】
付钦伟，集慧智佳高级咨询师、专利代理人，擅长专利布局、检索分析、专利预警&信息跟踪、FTO&风险分析，对企业开源软件法律风险管控、合规治理有深入研究和丰富经验。
【作者注】
[1]具体内容在本系列第三篇文章《代码的原生作者及其权利归属》里再做介绍
[2]见《代码的原生作者及其权利归属》
[3]FSF (Free Software Foundation)，自由软件基金会
[4]案件的分析可见：https://linux.cn/article-11683-1.html
[5]535 F.3d 1373, 1380 (Fed.Cir.2008)
开源问题系列探讨之三：著作权归属与授权的内在逻辑
【编者按】在开源软件漫卷全球，开源商业蓬勃发展的今天，如何合法合规地使用、修改、发布、运营开源软件，已经成为不少企业和开发者拥抱开源前的核心顾虑。有鉴于此，小编特邀开源行业内专家撰稿，对开源相关一系列知识产权与合规问题进行法理剖析和实务指导，以尽可能消解大家对开源的迷惑、误读及非必要的担忧，推动开发者们携手共创开源天地。
【简介】开源软件取得的巨大成就不仅改变了软件产业格局和商业模式，其独特文化和运营机制也对IT产业甚至社会产生了深远影响。刚结束的第十届中国云计算标准和应用大会，笔者有幸参加了由北大周明辉教授主持的开源知识产权分论坛，与多位前辈、老师一起分享开源治理中的一些感悟。鉴于有些问题对于开源治理和开源司法实践都有很好的参考意义，笔者将自己的思考整理、撰写成文，希望对大家理解开源有所帮助。不妥之处，期待各位老师、朋友批评指正，共同推进国内开源软件的发展。
1、开源软件的开发和授权模式造成的困惑
笔者在企业开源合规治理实践中，经常碰到以下问题：
贡献者贡献给开源项目的代码，其著作权是属于管理开源项目的组织吗？
如果使用者违反了许可证条款，谁会来起诉该使用者？
许可证所授予使用者的权利来自于谁，或者说许可人是谁？
例外声明是如何实现，同一个软件双许可的逻辑是什么？
……
以上这些困惑，都源于对著作权归属与权利许可[1]的内在逻辑没有完全理解。而之所以难以理解，是因为开源软件与传统专有软件不同，专有软件有明确的开发者/组织，有明确的商业软件使用协议，有明确的权利义务说明等。开源软件这种共享、共建的开发模式，宽松、开放的授权模式，使得曾经商业软件中上述明确的问题变得晦涩。要搞清这些问题，我们只需要理解代码的原生作者、开源软件著作权归属，以及著作权授权的内在逻辑即可。
2、著作权归属是开源运动的根基
开源软件著作权归属问题是一个“根本性”的问题，因为它是开源软件的“权利之源”，是整个开源运动上层建筑的基础。关注代码原生作者的目的，不在于区分谁写了哪些代码，而是理解基于代码原生作者，衍生出来的权利归属问题以及在代码共享中权利处置问题。
（1）谁是开源软件的著作权人
在《许可证法律地位及司法实践》[2]中已经阐述，开源软件的作者或其雇主（以下统称著作权人）理所当然拥有软件作品的著作权，理论上每一段完整的代码都有其原生作者和著作权人。为表述方便，本文不区分职务作品，后续的讨论中原生作者包含以雇员为代表的单位[3]。
以我国为例，根据《计算机软件保护条例（2013 年修订）》第9条，软件著作权属于软件开发者……。第10条，由两个以上的自然人、法人或者其他组织合作开发的软件，其著作权的归属由合作开发者签订书面合同约定。无书面合同或者合同未作明确约定，合作开发的软件可以分割使用的，开发者对各自开发的部分可以单独享有著作权；但是，行使著作权时，不得扩展到合作开发的软件整体的著作权。合作开发的软件不能分割使用的，其著作权由各合作开发者共同享有，通过协商一致行使；不能协商一致，又无正当理由的，任何一方不得阻止他方行使除转让权以外的其他权利，但是所得收益应当合理分配给所有合作开发者。
《中华人民共和国著作权法（2020 修正）》第14第1款，两人以上合作创作的作品，著作权由合作作者共同享有。没有参加创作的人，不能成为合作作者。
在不考虑软件领域特殊性和复杂性的前提下，从简处理著作权归属的问题：如果是单一的组织或个人开发的开源软件，其开发者就是著作权人；如果是多个组织或个人分别开发了各自的模块共同组成了一个完整的开源软件，每个模块的开发者就是该模块的著作权人；如果是多个组织或个人协作完成了某一开源软件，且又不属于上述模块的形式，属于“合作作品”（开源软件复杂的著作权构成，下一篇还会继续讨论）。
（2）开源许可证不涉及著作权转让
针对特定开源软件，无论规模大小，若面向全球开发，除由单一组织或个人开发的模块外，法律上应当视为合作作品，且大部分此类作品不能分割使用。开源许可证以及下面讲的贡献者协议就是“合作开发者签订的书面合同约定”，且绝大部分许可证和贡献者协议都不涉及著作权转让。以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）存在的意义。
（3）贡献者协议不涉及著作权转让
开源项目的原始著作权人、基金会与开源项目，他们之间是怎么样的一种关系呢？
若个人、组织或基金会作为原始开发者开发了某一软件，开发者便自然拥有了该软件的著作权。若原始开发者选择开源其作品，其便成为原始贡献者，且有权选择或者制定许可证。同时为了接受其他开发者贡献的代码，更好的对该开源软件进行管理和控制，原始贡献者可以让开发者签署贡献者协议，比如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公司的旧协议和新协议的区别在于：旧协议是著作权转让协议，新协议是著作权许可协议。
（4）项目捐赠仅涉及商标著作权转让
有些基金会接受捐赠的开源项目，即项目原始贡献者或当前管理者将开源项目控制权交给基金会，并按照基金会的管理制度进行管理。如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基金会。
（5）许可证制定者
以上讲了很多，但没有涉及到开源许可证的制定者。以Apache 2.0为例，其制定者是Apache基金会，也是开源项目的潜在受捐赠方，同样也是部分开源项目的发起者。如果针对某个开源软件，排除了这三种角色，单纯作为许可证的制定者，其扮演什么角色呢？
基本上什么角色都没有，唯一值得着重说明的是他们是其所制定的许可证本身的著作权人。如果制定者/组织有足够的影响力、能获得社区的认可，还能附带的具有解释其许可证，甚至充当协议纠纷仲裁者的角色，当然这建立在其自身的可信赖性基础上。比如FSF（Free Software Foundation）[14]，其自由软件理念鲜明的价值追求，获得了广泛的认可，包括Copyleft开源理念。不过，这种信赖是自愿的，理论上任何著作权人可以选择信赖某一个许可证及其组织，也意味着随时可以收回信赖。FSF作为自由软件运动的旗手，Copyleft理念的捍卫者，同时积极参与/支持涉GPL的诉讼、进行GPL执法，这是其他许可证制定者不曾拥有的信赖和地位。
3、开源软件著作权授权的内在逻辑
（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这类协议使得项目的主导者更够更好的管理软件的开发工作。
（2）没有权利转让的授权意味着什么？
对比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]）。
（3）著作权授权的内在逻辑
综上，开源许可证、典型CLA 、SGA和DCO无一例外，都不涉及知识产权权属的转移。这足以说明开源软件的知识产权从来只属于其原生作者或职务作品的雇主，而非仅仅是这个开源软件的原始贡献者，也非许可证制定组织，更不可能是纯粹的代码管理或平台托管方。
开源软件可以认为是多个作品的组合作品或合作开发的作品，其著作权归属于特定作品的创作者或全体代码贡献者（包括职务作品的雇主）。因此，开源软件许可证就是贡献者之间、贡献者与使用者之间的书面协议，贡献者之间成立的是合作开发协议，贡献者与使用者之间成立的是许可/授权协议。CLA、SGA是贡献者/捐赠者与主导者/被捐赠者之间的书面协议，属于合作开发或委托协议。宽松型许可证使得代码共享有了法律上的缘由，Copyleft许可证则巧妙地利用了著作权法来保护贡献者和用户的权利，CLA、SGA则为项目的管理、控制提供的法律支撑。但作为著作权所有人的作者、雇主或其代理人仍然是能够维护和保护用户权利的唯一人选，也是能够行使权利的唯一人选。
至此，本文开头的问题，答案就显而易见了：开源代码的贡献者或职务作品的雇主是著作权所有人，拥有处置其权利的最终决定权；而针对许可证违约者的诉讼，由且只能由这些人提出；同时，授予你权利的人也只能是这些人，无论你手里的作品副本来自于谁；最后，能够给软件添加例外声明或者进行多重许可的必须是著作权人或其授权的个人/组织。
理解了开源软件中原生代码著作权人和许可证的本质，也就很容易理解另一个问题，许可证权利终止问题。由于每一个接受者，其所获得的授权都直接来源于该软件上的每一个权利人，无论中间经过多少个分发环节。用户享有的权利并不取决于上游提供者是否合规，因为用户的许可证是由版权持有人直接下发的。其次，一旦许可自动终止，即使从其他分发者处再次获取软件也无法恢复权利许可权限，只能由原许可人授予。如果原许可人自动终止了许可，则任何中间许可证持有人，都无法恢复这些已经终止了的权利[22]。
【致谢】在此再次感谢大会、论坛组织者及与会的各位老师，特别感谢北京大学周明辉教授对本次论坛主题的思考和引导，这种思维的碰撞才得以让本系列文章得以成文、更加完善。
【本文作者】付钦伟，集慧智佳高级咨询师、专利代理人，擅长专利布局、检索分析、专利预警&信息跟踪、FTO&风险分析，对企业开源软件法律风险管控、合规治理有深入研究和丰富经验。
【作者注】
[1]不区分授权和许可的内在差异（法律专家手下留情）
[2]https://mp.weixin.qq.com/s/_IAE7hmD_jpHv3SwlcvcFQ
[3]严格来说职务作品的作者和著作权人非同一主体
[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
开源问题系列探讨之四：衍生作品及 GPL 传染性
【编者按】在开源软件漫卷全球，开源商业蓬勃发展的今天，如何合法合规地使用、修改、发布、运营开源软件，已经成为不少企业和开发者拥抱开源前的核心顾虑。有鉴于此，小编特邀开源行业内专家撰稿，对开源相关一系列知识产权与合规问题进行法理剖析和实务指导，以尽可能消解大家对开源的迷惑、误读及非必要的担忧，推动开发者们携手共创开源天地。
在《著作权归属与授权的内在逻辑（1）》一文中，笔者已经讨论了开源软件著作权归属问题，当时为了行文需要，文章故意回避了软件领域的特殊性和复杂性。但是，当我们谈及开源软件中 GPL 的“传染性”问题时，这就是一个无法回避的问题。
1、开源软件作品的特殊性和复杂性
一般情况下，无论软件的规模有多大，也不管该软件是否属于不同模块/组件的组合，基本上都可以将它们看作“一个作品”，因为没有必要区分其各个部分是否属于作品。但讨论 Copyleft 许可证关于衍生作品的范围，以及在诉讼中确定侵权代码的规模和方式时，就不得不关注软件开发领域作品的特殊性和复杂性。
在通行的著作权制度中，“作品”作为著作权的主要单元，其概念却很难映射到计算机编程领域。软件作品的特殊之处在于，它既是传统作品，又具有工业品的部分属性。下面重新审视一下《著作权归属与授权的内在逻辑》中提出三种情况：
情形一：如果是单一的组织或个人开发的开源软件/模块，其开发者就是权利人吗？
前文直接给出了结论，但实质上是有疑问的，因为这个软件可能必须要与某一款或几款软件同时使用，这个时候它不是完整意思上的独立软件。即使你承认了其本身的著作权归属于其开发者，你也不得不承认其必须受制于其所依赖的软件的著作权。参考我国《计算机软件保护条例（2013 年修订）》第 10 条，《中华人民共和国著作权法（2020 修订）》第13条规定。
情形二：如果是多个组织或个人分别开发了各自的模块共同组成了一个完整的开源软件，每个模块的开发者就是该模块的著作权人吗（2）？
这里的问题更大。首先，不能因为这些模块组成了一个开源软件就认为他们属于一个作品，因为某个模块的存在完全有可能与该开源软件没有太大关系。简单的说，它可以是独立且通用的，即工业品中的标准件，不依赖于完整软件而存在。
其次，有些模块可能其存在的目的就是为了组成这么一个完整的开源软件，其独立存在时毫无意义可言（像小说里的章节，这个比喻或许不恰当），你很难确切的说这是“一个独立作品”。
再次，如果某个模块它有独立的逻辑和功能，但又无法像第一种那样独立，又该如何对待呢？它就像小说的续集，延续原有的故事结构、人物形象和性格等基础构架，你无法否认他与原作品的联系（这个比喻或许不恰当）。
最后，也是软件开发领域的特殊性。模块之间的调用、引用、依赖等关系，很多时候并非代码直观呈现的那样。比如，在类 C 语言中，代码在编译、连接和运行状态下存在形式可能完全不同于源代码本身所展示的状态。模块的静态链接属于代码合并，动态链接是功能依存，而插件相对于主程序很多时候难以称得上“独立”。再如，软件模块完全可能是标准件，它独立存在却又不能独立实现其存在的意义，这种依赖可以是定向的，也可以是不定向。更重要的是，模块是编程的单元，其自身的形式和组成是完全不固定的。
情形三：如果是多个组织和/或个人协作完成了某一开源软件，且又不属于上述两种情形，依然符合“合作作品”的概念。但这种合作作品也不同于传统著作权或软著中合作作品的概念，开源领域中的合作是自发的、主动的，没有中心化的作品大纲或蓝图，而是充分发挥单个个体智慧和主动性创造的结果，属于纯粹的合作作品。这种情形下，合作作品本身的代码整体属于“单一作品”，不讨论传染性问题。该“单一作品”整体作为一个软件/模块，与其他模块间的关系，符合【情形一】的情况。
2、软件领域“作品”概念的模糊性
上述开源软件开发模式和开源软件的组成，不同于传统著作权中对作品的定义和作品的创作模式，造就了开源软件作品的特殊性和复杂性。即便如此，还尚未涉及软件开发领域各种编程单元和软件打包方式。“作品”作为著作权的主要单元，但其概念很难映射到计算机编程领域。在软件著作权领域，你甚至连什么是“作品”这个问题都回答不了。因为软件作品具有传统作品和工业品的复合属性，使得“作品”概念在软件领域具有不确定性。不仅上面讨论的模块存在这个问题，软件领域信手拈来的子程序“routine”、对象“object”、函数”function“、库”library”、模块“module”或任何其他软件单元都存着类似的问题，它们何时构成作品的一部分，何时自己构成作品本身？至少是现在的著作权相关法律和理论无法解释的。这种以模块为单位，结构化的开发模式，使得软件作品的创造更像是工业品，而非作品。
因此，代码的特殊性和复杂性就在于，软件代码超出了著作权法所谓的著作权仅保护其表达方式的定位。软件代码完全符合工业品的性质，却披上文学作品的外衣。这一特性就决定了，软件著作权领域不能简单的按照传统著作权判断原则来机械的适用。这一点在传统专有软件开发领域表现还不明显，但开源软件这种共享、共建的开发模式，让这种复杂性骤然凸显了出来。
当然，这里笔者不准备进行深层次的学术研究，本文只提出问题，留待专业的人士进行学术和法理的研究。但是，在企业开源合规治理和司法实践中，基于对以上问题的认识，还是有助于我们进行一些应用层面的分析。
3、Copyleft 的理解和衍生代码判断原则
目前，国内公开可查的涉及 GPL 的“传染性”认定的诉讼案例有两个，尚未公开的有一个，笔者有幸参与其中的两起诉讼。下面，结合多年的企业开源治理经验，笔者从应用层面讨论下 Copyleft 与衍生作品的问题，以及在诉讼中该如何定义侵权代码的规模和方式。
整体上，对衍生作品的认定，对许可证传染性的认定，既是法律适用问题，又是事实认定问题，也涉及双方意思表示的确认问题。所谓的法律适用问题，就是前面讨论的软件领域特殊问题在法律上如何适用；所谓的事实问题，就是理清软件领域复杂的技术和事实因素；所谓意思表示的确认，就是准确理解许可证要表达的意思，不能偏离许可证初衷。
由于每个许可证规定不一致，世界各国家/地区著作权法律规定和适用各异，开源软件领域有关衍生作品、传染性解释等并没有一个通用的标准。但是，司法实务、开源治理上确有原则可遵循。
如果将开源许可证看作类似于有名合同的一类合同，所有满足 OSI (Open Source Initiative) 或 FSF (Free Software Foundation) 认证的许可证都符合“自由/开源”软件许可证这个范畴。但具体许可证是宽松许可证，还是 Copyleft 许可证，及其细节规定需要尊重当事人意思，即取决于当事人选择/制定了哪种许可证和许可证的具体条款。
（1）开源精神原则
按照上述假设，可以推出开源治理的第一个原则，即符合“开源精神”原则，Copyleft 许可证和宽松许可证是开源理念中最典型的两种形式。司法实践中，在承认许可证是协议的同时，需要考虑是否符合开源精神、开源的初衷、权利人选择特定许可证的考虑，这本质上也是民法上所谓“意思自治”原则。
（2）特定许可证的“价值追求”或宗旨
从内容上看，许可证分为宽松型许可证和 Copyleft 许可证。Copyleft 许可证根据所谓“传染性”的强弱，分为强 Copyleft 和弱 Copyleft. AGPL 和 GPL 属于强 Copyleft 许可证，弱 Copyleft 许可证又分为File Level（文件级）、Library Interface Level（库接口级）、Module Level（模块级）。EPL和CPL属于文件级，LGPL属于库接口级，MPL1.1（Mozilla Public License 1.1）和CPAL1.0（Common Public Attribution License 1.0）属于模块级许可证。
开源治理和司法实践中，针对采用宽松型许可证的代码，其治理和侵权判定并没有什么特殊的，按照传统软件著作权的思路分析即可（著作权侵权本身就存在模糊的空间，不会因为属于开源软件著作权而有什么不同）。但 Copyleft 许可证在这个问题上确实存在特殊性，包括强 Copyleft 和弱 Copyleft 许可证。即便弱 Copyleft 许可证有所谓的文件级、库接口级、模块级的区分，有其特定的考虑，但因为软件领域复杂性和软件场景的多样性、差异性，衍生作品及其规模和认定方式依然存在模糊空间。
关于特定许可证的“价值追求”或宗旨，以下以 GPL 为例讨论一下强 Copyleft 许可证制定的初衷，即特定许可证背后的开源哲学和价值追求。
与宽松许可证不同的是，GPL 的精髓在于防止自由软件的私有化改进。如果GPL程序可以用私有化代码改进，无论这种改进是如何包装（packaged）或改写的，都无法实现开发者保护用户权利的初衷。GPL 存在的意义，就在于通过阻止私有化的改进来保护所有下游用户的自由权利。
虽然著作权制度是国际通行的法律制度，但是各国实际的立法和司法情况并不相同。GPL 许可证旨在最大的保护到当地版权法认可的、所有基于原作品的作品这个范围。这就是 GPL 许可证的诉求，或者说是 FSF 基于 Copyleft 理念下的“价值追求”。在司法实践中，当案件事实不能很好的匹配相应的法律规定时，需要考虑立法初衷。开源治理和司法实践也一样，当著作权法律没有明确规定时，在不违背著作权法律大前提下，也需要考虑许可证的制定初衷，即许可证制定者和许可证应用者内心的真实意思。
（3）特定区域的法律规定和适用
上面已经提到著作权制度在各国的实际规定并不一致，GPL 旨在最大程度的适应各国著作权法律的不同规定，在各国著作权制度允许的前提下最大程度的涵盖所有衍生作品、修改作品和/或结合作品。
对 GPL “传染性”的疑问或担忧，一般归结为 GPL 许可证关于其衍生作品“derivative work”及结合作品的定义含糊不清。事实上，正如讨论 GPL 初衷时所述，这其实是有意为之，因为不管是著作权法律本身还是软件开发实践都无法明确这个问题，GPL 能做的就是基于其“价值追求”给出一个严格的原则，将细节交给法院。
比如美国《版权法》第 101 条：“衍生作品”是基于一个或多个现有的作品而创作的作品，如翻译、音乐编排、戏剧化、小说化、电影版本、录音、艺术复制、删节、压缩，或任何其他形式的作品可能被重铸、转换或改编。由编辑修改、注释、阐述或其他修改组成的作品，整体上代表作者的原创作品，是“衍生作品”。
我国著作权法中没有关于衍生作品、派生作品或演绎作品的明确定义，不过基于法条的理解，学理中三种称谓并存。《中华人民共和国著作权法（2020 修订）》第十三条：改编、翻译、注释、整理已有作品而产生的作品，其著作权由改编、翻译、注释、整理人享有，但行使著作权时不得侵犯原作品的著作权。
该条款明确了演绎作品的作者，基于原作品再创作时，应事先征得原著作权人的同意，同时原作者仍享有署名权。演绎作品的作者，在进行作品的改编、翻译、注释、整理时，其他人也可以对该作品进行改编、翻译、注释、整理，各演绎作品的作者对自己创作的演绎作品分别享有著作权。
不过，以上著作权法律规定，对许可证如何定义衍生作品依然没有太大帮助，基于软件开发、使用和应用场景的复杂性，且区别于传统的作品，许可证本身很难对衍生作品进行明确的定义。毕竟，许可证作为著作权许可协议并不能创设或改变著作权本身的规则，与其让许可协议来定义这些术语的含义和范围，不如将其交给著作权制度本身或法院去解决。
因此，要解决 GPL “传染性”的问题，还需要积极的推动软件著作权和开源相关的立法、司法。当前业界的困惑与探索也有助于更好的指导未来的立法、司法活动，这是相辅相成的。美国相关纠纷比较多、软件开发特别是开源软件开发比较成熟，相应的研究和探索要多一些。正所谓理论出于实践，没有现在的困惑和纠结，如何期待未来的理论、司法层面的进步。学术、司法和企业还需要不断的碰撞和思考，结合我国的实际情况、著作权法立法初衷和当前的软件发展水平进行适用和解释，不断深化理论层面的研究。
（4）理清事实原则
根据我参与的两起诉讼看，上面所说的“开源精神”、“许可证初衷”、“特定区域的法律”三个方面，实践中虽然尚未形成体系或清晰裁判模式，但法院基本上都不会有太大的偏离。但技术事实的认定是存在这种可能的，技术部分有两大难点：一是要弄懂技术本身比较难；二是把认定的技术与法律和协议条款进行对接更难。
很多时候法官和律师即便能够很好的把握其他三个原则，也难以驾驭技术部分；而技术人员能够理解技术，但完全无法代入法律大前提。以至于判决中会出现一些瑕疵，甚至技术性错误（参见：中国 GPL 诉讼第一案（3））。比如，在数字天堂与柚子案的判决中关于“单独文件夹”的论述，严重不符合技术事实，稍有编程经验的人都能理解这基本上说明不了任何事情。当然，我们不能指望开源的法律问题能够通过一两次的司法实践就能彻底解决。以下的技术事实分解，可以从宏观上把握在司法和企业开源治理中需要重点关注的技术事实的分析程序。
自由/开源软件的共享、共建精神告诉我们，自由/开源软件无论是 Copyleft型还是宽松型许可证，都绝不是拒绝其被使用，相反是鼓励接收者使用。由于开发者对使用者的期待不同，附带了一些使用条件。理论上，即便是强 Copyleft 许可证的软件，在符合条件的情况下也可以无限制的使用。但软件领域复杂性和软件场景的多样性、差异性使这一条件的边际变得模糊不清，在评估某一款软件时必须将其放入实际场景中去分析。
在具体技术事实调查中，涉及很多具体的技术细节，需要具体问题具体分析，不过总体可以遵循一定的流程：
首先，清楚的把握和区分开源代码与自有代码是前提，这通常也意味着弄清楚自有代码是如何与开源代码结合/交互的。
其次，是理解代码的使用场景，如图中③所示，往往是一个关键的步骤，因为很大一部分分析工作到此就可以结束了，而不需要再投入巨大的工作来做深入的技术调查。
接下来关键的步骤就是对图中⑤的分析，如果必须走到这一步，就不得不让研发人员参与了，甚至技术鉴定。法官、律师和研发人员可能都不太愿意做这一步工作，但这是 GPL 软件避免不了的，且未来开源诉讼大概率无法回避的问题。当然，并不是说从第⑤步骤后，就必须受 GPL许可证“传染性”感染，这仅仅是需要更深入的技术调查而已，像独立软件⑥、及⑦中的插件有时也会存在比较清晰的判断依据。
当然上图只是按照软件的大致分类，给出的简单框架，图中的大部分圈是可以细分下去，一直到能够结合法律和许可证条款进行认定，得出结论为止。如果否定了代码表层的独立性，就会讨论具体模块的交互、通信方式、调用等深层次技术性问题。深层次的技术分析，会涉及本文开头讨论的问题，如何认定代码作品的独立性。
以上四个原则，可以作为企业开源治理和司法实践中参考的，至少我参与的两起开源 GPL 诉讼按照这个思路能够很好的得出结论。鉴于开源软件有可能成为未来的软件开发的基本模式，且国内开源软件的发展正处于一个关键的上升期，司法实践中在认定衍生作品时，法庭必须谨慎，让每一个案例都朝着排疑解惑迈进，因为每一个案件都有可能成为影响国内开源软件发展的关键。
4、Copyleft 是手段而不是目的
开源软件治理的复杂与困难不是绝对的，理论上所有知识产权案件都不是一件简单的事情。司法实践中，法官需要在充分理解软件领域的复杂性和软件场景的多样性、差异性基础上，在不违背开源精神以及特定许可证背后的价值追求的前提下，综合技术与法律因素做出认定、取舍和裁判。只有这样才能做到既兼顾法律规定，又考虑开源实际情况，不偏离国内外开源社区的整体预期。从另一个层面上讲，这种良好的可预期性和实践性，也能促进国内软件领域的发展、促进开源社区的成熟，提高中国在开源领域话语权。
最后需要强调的是，不管是宽松型许可证还是 Copyleft 许可证，其本身都是手段而不是目的。就像前面提到的，GPL 存在的意义，就在于通过阻止私有化的改进来保护所有下游用户的自由权利。开源的理念是共享、共建、共赢，宽松型和 Copyleft 许可证毫无疑问都在以不同的方式践行这个理念。开源之所以出现法律问题，还在于这种理念还未完全普及，还未真正成为基本共识。
【致谢】在此再次感谢大会、论坛组织者及与会的各位老师，特别感谢北京大学周明辉教授对本次论坛主题的思考和引导，这种思维的碰撞才得以让本系列文章得以成文、更加完善。不妥之处，期待各位老师、朋友批评指正，共同推进国内开源软件的发展。
【本文作者】付钦伟，集慧智佳高级咨询师、专利代理人，擅长专利布局、检索分析、专利预警&信息跟踪、FTO&风险分析，对企业开源软件法律风险管控、合规治理有深入研究和丰富经验。
【作者注】
（1）：https://mp.weixin.qq.com/s/xJafeeMZaH1UIWkD1HUE7A
（2）：严格来说职务作品的作者和著作权人非同一主体
（3）：https://linux.cn/article-11683-1.html
What
谷歌宣布，今年3月15日起，Chrome 浏览器的开源版本 Chromium 不再能够调用谷歌 API，这意味着Chromium 的书签、浏览记录等将都无法同步了。
华为已捐赠鸿蒙最核心基础架构，开放原子：开源 OpenHarmony 是每个人的 OpenHarmony
IT之家 6 月 6 日消息 开放原子开源基金会表示，已经于 2020 年 9 月接受华为捐赠的智能终端操作系统基础能力相关代码，随后进行开源，并根据命名规则为该开源项目命名为 OpenAtom OpenHarmony（简称“OpenHarmony”）。
[华为已捐赠鸿蒙最核心基础架构，开放原子：开源 OpenHarmony 是每个人的 OpenHarmony]
2020 年 12 月，博泰、华为、京东、润和、亿咖通、中科院软件所、中软国际等七家单位（按各单位简称首字母排序）在开放原子开源基金会的组织下成立了 OpenHarmony 项目群工作委员会，开始对 OpenHarmony 项目进行开源社区治理。各家单位对 OpenHarmony 开源项目持续投入和贡献。
OpenHarmony 开源项目重大事项均由项目群工作委员会各成员单位代表用投票方式共同决定，投票权利均等，一家单位一票，遵循公开明确的 OpenHarmony 项目群管理制度规则。
[华为已捐赠鸿蒙最核心基础架构，开放原子：开源 OpenHarmony 是每个人的 OpenHarmony]
截至 2021 年 5 月 31 日，已有 240 多个共建企业、共建机构与个人贡献者参与项目共建。2021 年 6 月 1 日，开放原子开源基金会在代码托管平台 Gitee 发布 OpenHarmony 2.0 Canary 版。
OpenHarmony 开源项目主要遵循 Apache 2.0 等商业友好的开源协议，所有企业、机构与个人均可基于 OpenHarmony 开源代码，结合自身优势，去做各领域的操作系统发行版及终端产品。通俗地说，
开源项目 OpenHarmony
是每个人的 OpenHarmony。
IT之家获悉，开放原子开源基金会是致力于推动全球开源产业发展的非营利机构，由阿里巴巴、百度、华为、浪潮、360、腾讯、招商银行等多家龙头科技企业联合发起，于 2020 年 6 月登记成立，“立足中国，面向世界”，是我国在开源领域的首个基金会。
开源生态白皮书（2020年）
一、开源生态概述
（一）开源概念逐渐明晰
（二）开源生态以开源项目为中心构建
二、开源生态发展现状
（一）开源数量持续攀升，我国开源覆盖全栈技术领域
（二）开源占据各领域主要市场份额，我国开源应用逐年攀升
（三）开源企业数量保持稳定增长，我国企业呈现主动开源趋势
（四）开源基金会成为开源运营重要角色
（五）各行业开源生态已经形成，我国行业积极拥抱开源
（六）开源风险问题凸显，成为开源应用屏障
（七）全球开源治理理念兴起，我国初步形成开源治理模式
（八）开源配套政策正在完善，我国政策引导开源社区构建
三、开源成为企业商业布局的重要手段
（一）全球开源商业模式多样化发展
（二）全球开源企业已启动收购模式，进一步扩大用户群体
（三）我国开源企业已初步构建形成有影响力的开源项目
四、全球开源基金会运营模式成熟，我国率先探索联盟运营机制
（一）良好的开源社区是形成开源代码的前提条件
（二）开源基金会运营通过知识产权托管培育开源社区
（三）我国逐步形成稳定的开源运营机制
五、传统行业逐步拥抱开源生态，我国行业用户关注开源使用
（一）工业互联网布局开源看重产业数字化新机遇
（二）电信行业由用户侧及运营商推动开源，探索产品创新
（三）政府采购行业发展开源看重公开透明
（四）金融机构开源看重产业创新力和市场布局
六、开源风险问题复杂，开源治理体系正在构建
（一）知识产权合规及安全漏洞风险相对普遍
（二）开源法律和知识产权环境推动开源良性发展
（三）开源治理工具加速企业开源治理体系构建
（四）开源治理模式逐步落地
七、开源生态未来发展趋势与建议
（一）开源生态未来发展趋势
（二）我国开源生态发展建议
常见的开源协议及其联系和区别
常见开源协议有GPL、LGPL、BSD、Apache、MPL、MIT等
联系及其区别
GPL
在自由软件所使用的各种许可证之中，最为人们注意的也许是通用公开许可证(General Public License，简称GPL)。
GPL同其它的自由软件许可证一样，许可社会公众享有：运行、复制软件的自由，发行传播软件的自由，获得软件源码的自由，改进软件并将自己作出的改进版本向社会发行传播的自由。
GPL还规定：只要这种修改文本在整体上或者其某个部分来源于遵循GPL的程序，该修改文本的 整体就必须按照GPL流通，不仅该修改文本的源码必须向社会公开，而且对于这种修改文本的流通不准许附加修改者自己作出的限制。
因此，一项遵循GPL流通 的程序不能同非自由的软件合并。GPL所表达的这种流通规则称为copyleft，表示与copyright(版权)的概念“相左”。
GPL授予程序接受人以下权利，或称“自由”：
以任何目的运行此程序的自由
以学习程序工作机理为目的，对程序进行修改的自由（能得到源代码是前提）
再发行复制件的自由
改进此程序，并公开发布改进的自由（能得到源代码是前提）
GPL协议最主要的几个原则：
1、确保软件自始至终都以开放源代码形式发布，保护开发成果不被窃取用作商业发售。任何一套软 件，只要其中使用了受 GPL协议保护的第三方软件的源程序，并向非开发人员发布时，软件本身也就自动成为受 GPL 保护并且约束的实体。也就是说，此时它必须开放源代码。
2、GPL 大致就是一个左侧版权（Copyleft，或译为“反版权”、“版权属左”、“版权所无”、“版责”等）的体现。你可以去掉所有原作的版权 信息，只要你保持开源，并且随源代码、二进制版附上 GPL 的许可证就行，让后人可以很明确地得知此软件的授权信息。GPL 精髓就是，只要使软件在完整开源 的情况下，尽可能使使用者得到自由发挥的空间，使软件得到更快更好的发展。
3、无论软件以何种形式发布，都必须同时附上源代码。例如在 Web 上提供下载，就必须在二进制版本（如果有的话）下载的同一个页面，清楚地提供源代码下载的链接。如果以光盘形式发布，就必须同时附上源文件的光盘。
4、开发或维护遵循 GPL 协议开发的软件的公司或个人，可以对使用者收取一定的服务费用。但还是一句老话——必须无偿提供软件的完整源代码，不得将源代码与服务做捆绑或任何变相捆绑销售。
LGPL
GNU宽通用公共许可证，简称LGPL(GNU Lesser General Public License)，被用于一些(但不是全部)GNU程序库。这个许可证以前被称为GNU库(Library)通用公共许可证。
LGPL是GPL的变种，也是GNU为了得到更多的甚至是商用软件开发商的支持而提出的。与GPL的最大不同是，可以私有使用LGPL授权的自由软件，开发出来的新软件可以是私有的而不需要是自由软件。所以任何公司在使用自由软件之前应该保证在LGPL或其它GPL变种的授权下。
BSD
BSD开源协议是一个给于使用者很大自由的协议。可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。当你发布使用了BSD协议的代码，或者以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：
1、如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
2、如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
3、不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销 售，因此是对商业集成很友好的协议。很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者 二次开发。
Apache
Apache License是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布(作为开源或商业软件)。
需要满足的条件：
1、需要给代码的用户一份Apache License
2、如果你修改了代码，需要再被修改的文件中说明
3、在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议、商标、专利声明和其他原来作者规定需要包含的说明
4、如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache License。你可以在Notice中增加自己的许可，但不可以表现为对Apache License构成更改
Apache License也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
MPL
MPL是The Mozilla Public License的简写，是1998年初Netscape的 Mozilla小组为其开源软件项目设计的软件许可证。MPL许可证出现的最重要原因是，Netscape公司认为GPL许可证没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益。同著名的GPL许可证和BSD许可证相比，MPL在许多权利与义务的约定方面与它们相同（因为都是符合OSIA 认定的开源软件许可证）。但是，相比而言MPL还有以下几个显著的不同之处:
1、MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来，以保证其他人可以在MPL的条款下共享源代码。但是，在MPL 许可证中对“发布”的定义是“以源代码方式发布的文件”，这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以MPL 许可证的形式对外许可外，源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些，就为借鉴别人的源代码用做自己商业软件开发的行为留了一个豁口。
2、MPL许可证第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。
3、对软件专利的态度，MPL许可证不像GPL许可证那样明确表示反对软件专利，但是却明确要求源代码的提供者不能提供已经受专利保护的源代码（除非他本人是专利权人，并书面向公众免费许可这些源代码），也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。
4、对源代码的定义
而在MPL（1.1版本）许可证中，对源代码的定义是:“源代码指的是对作品进行修改最优先择取的形式，它包括:所有模块的所有源程序，加上有关的接口的定义，加上控制可执行作品的安装和编译的‘原本’（原文为‘Script’），或者不是与初始源代码显著不同的源代码就是被源代码贡献者选择的从公共领域可以得到的程序代码。”
5、MPL许可证第3条有专门的一款是关于对源代码修改进行描述的规定，就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述
MIT
MIT是和BSD一样宽范的许可协议，作者只想保留版权，而无任何其他了限制.也就是说，你必须在你的发行版里包含原许可协议的声明，无论你是以二进制发布的还是以源代码发布的。
开源软件简介序列一
作者: 李丽 时间: 11.06.2020
近年来，与软件、通信技术（ICT）、金融科技（FinTech）相关的行业都在被开源逐渐渗透，软件的开发越来越依赖于开源，企业也是越来越重视开源，在开源社区的参与也越来越多。比如，Q公司，即是许多开源项目的发起者，也是开源社区的重要贡献者和回馈者，其在Github（全球最大的开源社区，由微软运营）上已经开源了80多个项目，在Github全球公司贡献榜上排名前十。
从企业角度讲，投入一个项目都是需要取得收益的，同样投入开源也是为了企业取得商业利益。
但是，开源软件是否可商用？是可以想怎么用就怎么用的吗？开源许可证中关于知识产权的规定是怎样的？在使用开源软件的时候，需要注意防范哪些法律风险呢？
接下来，我们会从多个角度以分章节的形式来共同探讨开源的相关知识，包括如下内容：开源软件是什么？开源软件的商业模式、开源许可证中知识产权规定及风险、风险防范的建议等。希望可以帮助到想了解开源的一些人。
系列一：开源软件是什么？
开源软件（Open Source Software，缩写OSS），又称之为开放源代码软件，其实就是一种软件产品。我们都知道，计算机只能执行二进制代码，即“0”、“1”序列；而源代码程序是一种比较接近自然语言的计算机源程序，这样方便人们的理解和交流，这种源程序需要被翻译成二进制代码才能被计算机执行。那么开源，一般指的就是开放这个源代码，而这个源代码，一般是计算机软件的作者才会拥有。那么这其中，就会涉及到版权、专利权及商标权。
那么是否开放源代码的软件都是开源软件呢？—答案是否。
一般来说，我们提到的开源软件是指符合开源软件促进会（OSI，Open Source Initiative）定义的软件。
OSI创建于1998年2月，是一个旨在推动开源软件发展的非盈利组织。
开源软件的定义可参见图1所示，这个定义共有10个要件，包括：自由再发布（Free Redistribution）、源码（Source Code）、衍生著作(Derived Works)、原创作者程序源码的一致性(Integrity of The Author’s Source Code)、不歧视任一个人和团体(No Discrimination Against Persons or Groups)、不歧视在任何领域的使用(No Discrimination Against Fields of Endeavor)、散布许可协议(Distribution of License)、不得限定于特定产品(License Must Not Be Specific to a Product)、许可协议不得限制其他软件（License Must Not Restrict Other Software）、许可协议必须保持中立（License Must Be Technology-Neutral）。基于这个定义要件，可以确定一个软件是否可以被标记为开源软件。
更多详情可查阅OSI官网：https://opensource.org/osd-annotated。
图1
OSI有专门的流程来审核一个软件是否符合开源的定义。一个软件在完成OSI认证前，不能说自己是开源的。
那么开源软件是如何产生的？与商业软件有何区别？
在上世纪70年代，开源几乎是与互联网及软件同时期诞生的。在最初的时候，软件和硬件紧密联系在一起，软件是自由的、免费的、开源的。后来随着计算机的快速发展和软件的兴起，软件和硬件也出现了分离，比如IBM和Microsoft合作，由Microsoft给IBM生产的个人计算机提供OS，就出现了商业软件模式。再比如，oracle的提供的数据库、应用软件等；再比如SAP公司提供的企业管理软件等。
这些商业软件通常会部署大量的专利，如下图2所示，我们通过专利检索网站（Patentcloud；https://app.patentcloud.com/index.html）通过关键词"Microsoft Corporation” or “微软公司”,大致查到了10多万件专利/专利申请。
图2
大量的软件专利部署在商业软件中，一定程度上形成了技术独占的现象，能极大地保护各大商业软件公司的独享及垄断地位。而且商业软件几乎不开放源代码。
我们通过如下图3可以了解下开源软件和商业软件的区别。
图3
开源软件产生的目的就是要打破商业软件占据主导的垄断地位。开源软件通过技术共享的方式来促进自身及技术的发展，比如开放源代码、鼓励开发者/用户之间通过互相复制、学习、修改、发布等途径进行传播，这样通过更多人参与软件建设、完善了软件的缺陷，促进了技术的发展及普及。
同样的，开源软件也是受版权法保护的；但是开源软件对授权后的专利的权利行使做了限制。这些方面体现在随同开源软件一起发布的软件许可证里。开源软件通过许可证的方式维护了自身的生存及健康发展。关于开源许可证，我们在后续章节会聊到。
本次对开源软件的简介就先聊到这里，在下一次我们会共同来了解和探讨下开源软件与知识产权之间的事情。
How
开源软件商业模式的死亡（英文）
开源软件常见的商业模式是”软件开源 + 服务收费”，但是云服务商正在杀死这种模式。
如果你免费提供软件，并且这种软件足够受欢迎，云服务商将不可避免地使用你的代码提供竞争性服务。他们会毫不留情地用自己的方法痛击你，在你的前院倾倒垃圾。而你的律师则站在你耳边低语，”什么也做不了。”
Experience
亚马逊正式发布了 OpenSearch，这是对 Elasticsearch 官方版本的反击，后者最近修改许可证，禁止作为云服务进行销售。两者的关系有点像 MariaDB 和 MySQL，双方势均力敌，大概过一两年，才能看出来谁会赢。
中国法院倾向保护违反GPL软件协议的行为吗？
——兼谈开源软件的风控问题
摘要：涉开源软件的计算机软件著作权纠纷数量随开源软件商业化的加速发展呈上升趋势。当事人以开源软件为由进行抗辩时，似乎难以得到法院支持。因此有声音认为我国法院倾向保护违反GPL协议的行为。本文通过数字天堂公司与柚子科技公司、柚子移动公司案以及不乱买公司与闪亮时尚公司案来分析中国法院是否具有保护违反GPL协议行为的倾向，并通过案例中判定涉案程序是否属于“独立程序”的方法与思路进一步讨论开源软件的风控问题。
一
前言
笔者在做开源软件著作权纠纷判例研究时检索出一文章，名为《中国法院为什么保护违反GPL软件协议的行为？》[1]，而另一署名为You Yunting的作者在Bridge IP Law Commentary网站发表的文章《Why China Court Protects Violation Against GPL License Agreement?》[2]内容与前篇完全对应。两篇文章介绍了一经北京市海淀区人民法院一审，北京市第一中级人民法院终审判决的案件：
被告从原告公司离职后开设新公司，继续使用原告公司的软件为客户制作网站程序，被告认为原告的软件是基于GNU GPL协议的开源软件DNN 修改的，其应当公开软件源代码，所以被告不构成侵权。法院查明原告的软件是基于GPL协议的开源软件修改而成，但属于非法演绎作品，即原告付出了创造性劳动，对于软件享有著作权，有权禁止他人使用。因此最终判决，原告未开放的源代码著作权受法律保护，被告构成侵权。
文中的律师点评指出该案“显示了中国法院的实用主义特点”[3]即“目前90%以上的开源软件代码是国外开发者贡献，中国公司贡献很少，因此，不保护开源软件对国内产业影响不大，同时，目前法院需要保护国内竞争秩序，中国国内开发者不规范使用开源软件的情况比较普遍，虽然本案中的原告违反了开源协议，但其还是为软件付出了一定创造性劳动，如果不予保护，将使类似公司都面临问题，从而影响国内市场的竞争秩序”[4]。有学者总结“中国裁判文书网公开的17万余份著作权侵权民事案件裁判文书中，涉及当事人以当事人使用开源软件或自由软件为由进行抗辩时，法院均以证据不足为由未予支持”[5]。其中，一典型案例是天津市网城天创科技有限责任公司、天津市网城科技股份有限公司等与温岭市达克罗涂复工业有限公司等侵害计算机软件著作权纠纷案[6]。被告温岭市达克罗涂复工业有限公司主张原告ShopNC软件系用开源软件PHP+MYSQL编写，PHP、MYSQL分别使用基于GPL开源协议的PHPCCPL开源协议及标准GPL开源协议。因此原告有署名权，但是不能禁止其他方改编、使用、复制、发表该软件，也不得向其他方收取软件使用费[7]。法院认定被告没有提供证据证明涉案软件是开源软件，也未对原告是否违反GPL协议进行实质审理。该案似乎也体现了“实用主义”，但中国法院真的保护违反GPL软件协议的行为吗？笔者认为这是一个值得深思的问题，原因有二：其一，如果中国法院真的保护违反GPL软件协议的行为，那么会鼓励更多企业“钻空子”、“走捷径”、“挣快钱”，反而不利于稳定国内市场的竞争秩序；其二，中国法院是否保护违反GPL软件协议的行为这一问题背后更加重要的议题是相关开源软件应如何风控。
下面笔者通过两个典型案件来分析中国法院是否具有保护违反GPL软件协议行为的倾向及相关开源软件的风控问题。
二
数字天堂公司与柚子科技公司、柚子移动公司案
（一）一审案情简介[8]
原告数字天堂（北京）网络技术有限公司（以下简称“数字天堂公司”）是HBuilder开发工具软件的著作权人，其发现被告柚子（北京）科技有限公司（以下简称“柚子科技公司”）及被告柚子（北京）移动技术有限公司（以下简称“柚子移动公司”）于2014年9月通过官方网站发布一名为APICloud的软件。原告数字天堂公司经对比，认为APICloud软件抄袭了其HBuilder开发工具软件中的三个插件（代码输入法功能插件、真机运行功能插件、边改边看功能插件）的源代码。
被告柚子科技公司、柚子移动公司辩称HBuilder开发工具软件是GPL协议下开源软件分支，即HBuilder软件使用了受GPL协议保护的第三方软件源程序，其亦为开源软件，任何第三方有权在GPL协议授权下使用其代码并构建衍生软件产品。
北京知产法院经查认定：
1、HBuilder软件属于《著作权法》第三条规定的计算机软件作品，原告数字天堂公司是HBuilder软件的著作权人。
2、代码输入法功能插件、真机运行功能插件、边改边看功能插件虽包含于HBuilder软件中，但均可以独立运行，且原告对上述三插件分别进行了著作权登记，因此属于独立的计算机软件作品。原告数字天堂公司是上述三插件的著作权人。
3、工业和信息化部软件与集成电路促进中心知识产权司法鉴定所（以下简称“鉴定机构”）对APICloud软件与HBuilder软件进行同一性鉴定。据其鉴定意见，柚子公司APICloud软件中对应插件源代码部分与数字天堂公司的涉案三插件构成同一性。
4、涉案三插件所处文件夹中并无GPL开源协议文件，据此，涉案三插件并不属于GPL协议中所指的应被开源的衍生产品或修订版本。
5、被告柚子科技公司和柚子移动公司认为原告HBuilder软件为开源软件的相关抗辩理由不能成立，其被诉行为构成对原告复制权、改编权及信息网络传播权的侵犯。
扫码进入知产宝
查看裁判文书
案号：(2015)京知民初字第631号
（二）二审案情简介[9]
柚子科技公司和柚子移动公司不服北京知产法院的判决，向北京市高级人民法院提起上诉。上诉人柚子科技公司和柚子移动公司坚持HBuilder软件整体上应受到GPL协议约束，涉案三个插件中包含大量开源或第三方代码，应依照GPL协议的规定承担开源义务。二公司针对涉案三个插件的独立性认定问题再次提出司法鉴定申请。二审法院认为柚子科技公司和柚子移动公司在一审两次鉴定程序中均怠于行使自己的举证责任，二审诉讼中再次提出第三次鉴定申请，有违司法程序公正和司法程序效率，且二公司提出的相关司法鉴定申请内容与本案待证事实间无直接关联性，因此二审法院驳回了其司法鉴定申请。二审法院承继了一审法院对于涉案三插件不应受到GPL协议约束的论述，维持了柚子科技公司和柚子移动公司的行为构成侵权的判定，仅对一审法院侵权代码的数量、侵权行为个数和赔偿金额的认定做出修正。
扫码进入知产宝
查看裁判文书
案号：(2018)京民终471号
（三）本案亮点与启发
开源软件运动源自自由软件并早已从追求叛逆版权（又称“著佐权”、“反版权”，即Copyleft）走向商业化[10]。尽管在理念上，开源软件反对“垄断”，倡导“自由、共享”[11]，但随着商业化的进行，开源软件也在逐渐转为与知识产权制度兼容[12]。开源软件基于著作权法，通过许可证约定使用该软件应遵循的条款与条件，以达到向公众贡献源代码，使源代码在一个合理合适的环境内交流和再发布的目的[13]。
数字天堂公司与柚子科技公司、柚子移动公司一案中，一审法院大篇幅引用了2007年6月发布的GPL协议第3版的规定，二审法院也同样接受了一审法院关于GPL协议效力问题的论述。这表明我国法院承认GPL协议在中国具有法律约束力。
一审法院对GPL协议第3版的规定的引用主要涉及以下内容（笔者亦摘录了GPL协议第3版相应部分的原文供参考）：
1、定义部分：
“本程序”指任何在本许可下批准的受版权保护的程序。“修订”程序是指从软件拷贝或者做出全部或一丁点儿的修改，这不同于逐字逐句的拷贝，是需要版权许可的。修订成果被称为先前程序的“修订版本”或者“基于”先前程序的程序[14]。
（“The Program” refers to any copyrightable work licensed under this “License”. Each licensee is addressed as “you”. “Licensees” and “recipients” may be individuals or organizations. To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.[15]）
2、对于“聚合体”的判断（GPL第三版协议第5条）：
发布修订过的源码版本，您可根据第4条的条款，以源码形式发布一个基于本程序的程序，或者从本程序中制作该程序需要进行的修订，但是您必须同时满足所有以下条件：a)……b）……c)……本许可以及第7条中的任何附加条款适用于整个程序及其所有部分，无论该等程序以什么形式打包。……d) ……如果一个受保护程序和其它独立程序的联合作品，则若该联合作品并非该程序的自然扩展，也不是为了在某个存储或发布媒介上生成更大的程序，且如果联合作品和产生的版权未用于限制编译用户的访问或超出个别程序许可的合法权利时，这样的联合作品就被称为“聚合体”。包含受保护程序的聚合体并不会使本许可应用于该聚合体的其他部分[16]。
（You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions: a) ……b) ……c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it. d)……A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation’s users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.[17]）
本案的关键点在于对于“聚合体”（the aggregate）的判断与认定。一审法院的判断方法可总结为：
1、三个文件所处位置。
2、三个文件所处文件中是否包含GPL开源协议文件。
3、HBuilder软件根目录下是否存在GPL开源协议文件。
二审法院继承了一审法院的判断方法与结论，即涉案三插件所处文件夹中无GPL开源协议文件，HBuilder软件根目录下亦不存在GPL开源协议文件，涉案三插件不属于应被开源的衍生产品或修订版本。因此，尽管HBuilder软件其他文件夹中包含GPL开源协议文件，但该协议对涉案三插件无约束力。
有观点指出判断某程序是否属于独立程序不应仅依据该程序所处文件夹中是否包含GPL开源协议，而应“基于对程序之间通信关系、依赖关系、调用关系的深入分析”[18]。下面介绍的不乱买电子商务（北京）有限公司（以下简称“不乱买公司”）与北京闪亮时尚信息技术有限公司（以下简称“闪亮时尚”公司）侵害计算机软件著作权纠纷案就体现了我国法院对于开源代码抗辩是否成立判断时综合考虑展示方式、所用技术、功能分工等方面的整体思路。
三
不乱买公司与闪亮时尚公司案
（一）一审案情简介[19]
原告不乱买公司是软件“不乱买时尚海淘软件（PC版）”的著作权人，该软件开发完成日期和首次发表日期为2015年3月27日，取得计算机软件登记证书日期为2016年8月23日。原告不乱买公司在本案中主张的代码为后端代码。被告闪亮时尚公司成立于2016年6月15日，是www.blinghour.com网站的主办单位。被告时尚闪亮公司的蔡某（股东之一）及彭某原为不乱买公司员工。一审法院采用以5%的比例从原告提供的源代码中挑选20个文件作为原告的抽样对比文件，再以关键词等方式确定被告的对应文件，用对比软件进行对比的方式进行同一性对比。对比结果和技术分析表明抽样对比的绝大部份程序文件在程序逻辑和结构方面实质相同，函数变量命名特点相同或相似，被告不同文件的代码中多次出现与原告程序中相同的注释错误。
一审法院认为，原告不乱买公司软件的前端代码开发主要是前端用户可见的操作界面，后端代码开发则主要是指后端用户不可见的服务端相关逻辑功能等模块的实现，二者展示方式不同、所用技术不同、分工亦有明显区别，属于可独立的程序。被告闪亮时尚公司的股东之一蔡某曾在原告公司研发部门任要职，曾为被告公司监事的彭某亦曾在原告公司研发部门任要职，因此被告具有接触到原告涉案权利软件的可能性。基于抽样对比结果及技术分析，被告与原告抽样选取的程序文件实质相似的比例较高，因此，被告的行为构成侵权。
扫码进入知产宝
查看裁判文书
案号：（2016）京73民初1111号
（二）二审案情简介[20]
闪亮时尚公司不服，向最高人民法院提起上诉，其理由包括：
1、原审法院认定上诉人侵权事实不清：不乱买公司版权登记证书的时间等方面存在重大瑕疵、取得也违反相关流程。
2、原审法院存在程序非法情形：超出诉讼请求裁判。
3、蔡某无接触涉案相关代码的可能。
4、不乱买公司遵循GPL第二版协议的前端代码文件不能独立工作，需要调用其后端PHP软件进行配合。因此前段文件和后端文件共同构成了不乱买公司主张著作权的软件，根据GPL协议，该软件作为整体应向任何第三方无偿开源。
5、原审法院判决闪亮时尚公司应停止侵权已无必要。
6、原审法院赔偿额过高。
7、原审法院认定闪亮时尚公司侵害不乱买公司署名权属于错误认定。
二审法院承继了一审法院对于不乱买公司后端代码属于可独立的程序的认定，维持了闪亮时尚公司的行为构成侵权的判定，同时认定其上诉理由均不能成立，因此维持原判。
扫码进入知产宝
查看裁判文书
案号：（2019）最高法知民终663号
（三）本案亮点与启发
本案的裁判一方面强调了判断被诉侵权作品是否使用了享有著作权作品时一般适用“接触+实质性相似”的方法，一方面也体现了开源协议适用范围及对软件著作权侵权判定的影响。最高人民法院指出，“网站前端代码与后端代码在展示方式、所用技术、功能分工等方面均存在明显不同，属于既相互独立又互相联合的独立程序，即便前端代码使用了GPL协议项下的开源代码，后端代码也不受GPL协议约束，未经许可复制后端代码仍构成侵害软件著作权”[21]。
相比于数字天堂公司与柚子科技公司、柚子移动公司案对于涉案程序是否属于独立程序判断时的判断方法与思路，本案则突出体现基于对程序之间关系的深入分析、综合判断涉案程序是属于“衍生产品”还是“独立程序”的总体思路。这体现了我国法院对于涉开源协议相关案件审理理论和方法的进步，也更符合开源社区和其他国家司法实践中的主流思路和方案。
上文中提到了一篇关注率颇高的文章，其批评我国法院对于GPL协议的违反行为的保护。结合数字天堂公司与柚子科技公司、柚子移动公司案以及不乱买公司与闪亮时尚公司案来看，我国法院意在不断调整思路和方法以求合法公正的判决、保障当事人的合法权益。可以说，尽管不能排除实用主义的存在，但从最高人民法院知识产权法庭裁判要旨来看，我国法院并不倾向于保护对GPL协议的违反行为。
四
开源软件的风险防控问题
GPL的法律性质是合同。我国《著作权法》第24条、《著作权法实施条例》第23条以及《计算机软件保护条例》第18条均对使用他人作品应同著作权人订立许可使用合同进行了规定。但我国目前尚无法律直接调整开源软件或自由软件的许可行为[22]。因此，开源软件的风险防控问题尤为重要和复杂。
商业软件开发公司常咨询利用开源软件时如何风控的问题。开源软件的风险根本在于“发布义务”，即“传染性”。GPL第二版协议中明确GPL协议的触发点是“分发”（distribute），而在GPL第三版协议中GPL协议的触发点还包括“输送”（convey）。因此，只要不对外分发或输送基于GPL协议的软件或其衍生作品，就可避免“传染”。一个常用的规避风险的措施就是“在后端服务器部署GPL开源软件，而用户无需进行任何安装，直接通过网络远程接入服务[23]”。
数字天堂与柚子科技公司、柚子移动公司案似乎体现了另一种规避风险的方式，即GPL协议不会传染“聚合体”。那么，将包含GPL开源协议文件与商业软件产品放在不同空间，通过其他方式达到独立程序间的通信或调用可规避传染风险。需要强调的是，这一方式仍存在很大争议。
在不乱买公司与闪亮时尚公司案中，最高人民法院对“独立程序”的认定方式对GPL开源软件风控问题有一定启示意义，即商业软件公司在使用包含GPL开源协议文件时，即使将其与商业软件产品放置在不同空间，也需考量二者在展示方式、所用技术、功能分工等方面的关联程度，以进一步规避风险。
五
结语
本文通过两个案例展示了我国法院对涉GPL开源协议计算机软件著作权纠纷的审理思路以及对“独立程序”的判断方法，并基于该案例探讨了开源软件的风险防控问题。本文对相关风险防控问题的说明仅围绕著作权展开。
随着商业化的进行，开源软件在行动上寻求包括著作权法、商标法和专利法的综合保护，并将这些保护与许可协议相结合[24]。因此，在讨论开源软件风险防控时候，还需要从商标、域名及专利角度出发，综合把控。
Elasticsearch 许可证
业界应用最广的开源搜索工具 Elasticsearch 上周修改了许可证，新版本将不允许云服务商使用它提供服务。这主要是针对亚马逊公司，后者出售 Elasticsearch 搜索服务，开源项目的维护者拿不到任何好处，等于是为亚马逊免费打工。
亚马逊立刻回击了，宣布将提供自己的开源版本。Elasticsearch 等于是为自己找了一个竞争对手，而且对手有无限资源。这件事的启示就是，开源时要想好，如果大公司拿你的代码挣钱，也不会分给你，你怎么办。
传奇路由器 WRT54G
2002年12月，Linksys 公司发售了一款新的路由器 WRT54G，售价199美元。
第二年，网络硬件巨头思科就以5亿美元的价格，收购了 Linksys。
有一个 Linux 开发者意外发现，WRT54G 的驱动程序基于 Linux。但是，Linksys 公司并没有披露这一点。这意味着根据 GNU 许可证，必须发布无线固件的源代码。
事实上，Linksys 自己也没意识到这个问题。因为这台路由器使用了 Broadcom 公司提供的芯片，Broadcom 使用了基于 Linux 固件，但是没有通知 Linksys，后者随后又被出售给了 Cisco。
社区就向思科公司提出要求，提出必须开源固件。一个月以后，无线固件的源代码就真的开源了。
这是第一次外部程序员可以完全控制高规格的商业路由器，并且有办法增强功能或者改进其他路由器。后来很多的路由器开源系统，比如 OpenWrt 和 Tomato 等，都是起源于这个开源固件。
这导致 WRT54G 路由器在开发者社区异常受欢迎，直到2016年依然有数百万美元的销售额。
思科显然很不喜欢这种状况，后来修改这个路由器的固件，不使用 Linux。这引起了社区的强烈反弹，加上思科发现 Linux 版的 WRT54G 销量很好，所以就恢复了原来版本的销售。
澳洲开发者：我的开源项目被科技巨头窃取，只是注释删掉了我名字
IT之家 6 月 6 日消息 据外媒报道，一位来自澳大利亚的开发者 Brendan Gregg 在最近的一篇博客中表示，他的开源项目「DTraceToolkit」代码 被 IT 巨头 Sun Microsystems 窃取，而对方只是删掉了代码中的注释，无可奈何。
IT之家了解到，Sun Microsystems 是一家 IT 及互联网技术服务公司（已于 2009 年被甲骨文收购），创建于 1982 年，主要产品包括工作站、服务器和 UNIX 操作系统等，内地多译为太阳计算机系统，曾被认为是最具创造性的企业之一，也是引领过一个时代的巨头，例如 Java、MySQL 等。
（小插曲：甲骨文收购后利用该专利状告谷歌的 Android 项目使用了大量 Java 代码（闭源），双方扯皮十多年，最终由美国最高法院在 2021 年 4 月判处谷歌胜诉）
说回 Brendan Gregg，这个故事要从 2005 年讲起，当时他作为一名个人性能顾问，而恰逢 Sun Microsystems 刚发布了 DTrace 工具，迅速在他这类性能分析师 中爆火起来。
而他发现，他开发出的 DTrace 工具比 Sun 本身生产的还要多，包括 DTrace 开源项目 DTraceToolkit 和其他 DTrace 工具（也就是脚本) 编写和发布的高级性能工具。
（科普：DTrace 全称 Dynamic Tracing，即动态跟踪，是由 Sun Microsystems 开发的一个用来在生产和试验性生产系统上找出系统瓶颈的工具，可以对内核和用户应用程序进行动态跟踪并且对系统运行不构成任何危险的技术）
之后他还附上了一张 DTraceToolkit v0.96 tools (2006) 的截图佐证。
在那之后，一位官方专家从美国到访，并交给他了一个内部项目，其中包括来自 Sun 的一些高端技术。他们见面之后，对方向他演示了一些 DTrace 功能，例如双击图标来运行多个 DTrace 工具，并将原始数据输出到单独的窗口中，或者将结果显示为折线图，原主认为似乎相当平庸，而且对方还向他炫耀。
此时，为了避免尴尬，原主决定顺对方的意思看一下其演示内容的套接字 I/O 脚本。
之后，当他找到这些工具的目录后发现，它们名字都显得十分很熟悉，例如其中一个叫做「socketsnoop.d」的程序，他尝试了一下，结果证实了心中的猜想：是他在那一年前的尝试性内容，当时已作为开源项目发布。
再然后，他尝试了更多工具，编码风格完全一致，最后发现这些工具基本都是他早期编写的脚本，而他注释中的署名、开源许可证等也完完全全地被替换掉，也就是说这些人推销抄袭的工具竟然可笑地推销到了原主头上。
他并没有当场发作，只是建议他们更新一下代码，因为有些 bug 已经修复很久了，而且他还开发出了比「socketsnoop.d」更好用的新版本。
值得一提的是，他也只是讲述了这个十多年前的故事，而没有带公众节奏或试图去拿到赔偿，也仅仅只是以第一人称讲了一个故事罢了。
此外，他还特意表扬了苹果，因为苹果在那之后也将其数十种工具添加到 OS X 中，不过这次完整地保留了原作者的姓名、版权和完整的 CDDL 开源许可证等信息。
蚂蚁自研数据库 OceanBase 正式开源，采用木兰公共协议 MulanPubL-2.0 版
IT之家 6 月 1 日消息 6 月 1 日，蚂蚁集团自主研发的分布式数据库 OceanBase 3.0 发布，同时，OceanBase 宣布正式开源，并成立 OceanBase 开源社区，社区官网同步上线，300 万行核心代码向社区开放。
IT之家获悉，蚂蚁自研数据库 OceanBase 致力于打造企业级开源数据库，将快速发行商业版本，满足行业客户对数据库高性能、高可靠、融合处理的业务诉求。
据介绍，开发者在开源社区能够完整使用 OceanBase 数据库内核。此次开源采用业界通用 Open Core 模式。开源范围包含数据库内核、分布式组件和接口驱动，并提供完整的 SQL 引擎、事务引擎和存储引擎，支持多副本、分布式事务、高性能、扩展能力、故障恢复、优化器、多活容灾、语法兼容等核心技术，开源 300 万行核心代码。
OceanBase 采用木兰公共协议 MulanPubL-2.0 版，协议允许所有社区参与者对代码进行自由修改、使用和引用。OceanBase 社区同时成立了技术委员会，欢迎所有开发者贡献代码和文档。
更多细节，请至 OceanBase 开源官网查看、体验。
开源官网：https://open.oceanbase.com/
鸿蒙之迷思：方舟应用开发框架仍不清晰，华为 HarmonyOS 尚未完全开源
本文通过追根溯源和道听途说，从“纯技术”层面探讨了鸿蒙演化到今天“不得已”的现状。就事论事，不讨论其他领域的争执。
鸿蒙之迷思：方舟应用开发框架仍不清晰，华为 HarmonyOS 尚未完全开源
一、2012 实验室
鸿蒙是个品牌，背后是 n 套核心的 n 套系统的组合。
鸿蒙中的关键曾经是方舟编译器，鸿蒙的开发代号还叫过 Ark (方舟)。由于方舟团队的几位离职负责人在网上写过回忆录，所以我们能拼凑出当初发生了什么。
华为 2012 实验室有个了不起的组织架构，就是把研发实验室设到全球各地，这样那些不想到深圳工作的牛人可以安心在本地，不用拖家带口。
当然猎头也更方便，不少实验室设在其它巨头旁边。
从基站上的 DSP 到后来的麒麟和鲲鹏，华为自建编译器团队越来越必要，来实现性能的优化到自有指令集等等。
世界软件的灯塔在硅谷，所以华为编译器团队就在美研所组建。中国软件的灯塔之一在杭州，国内编译器团队集中在杭研所。
美研所在 2014 年请到 Open64 编译器的总架构师周志德老爷子。也许由于 Open64 日暮西山，而苹果支持的 LLVM 如日中天，不服气的周老和小伙伴们做起 Maple 编译器，这就是方舟的前身。
Maple 为什么改叫方舟，网上众说纷纭。一种说法是周老的英文名字 Fred Chow 谐音就是“方舟”；另一种说法是 2012 世界大难来了要方舟来救命，这和 2012 实验室的名字吻合。
在晚舟女士被 Maple 国扣留以后，改名字更是大势所趋。不过到今天方舟大量文件名仍保留了 Maple 或 Mpl 等。
华为美研 (Futurewei) 在美帝制裁后，出现了个法律悖论。因为 Futurewei 是美国公司，美帝没法制裁，但它能限制 Futurewei 向母公司输送技术，后来华为员工好像也不被允许进入 Futurewei。
大概因为如此，华为对开源模块的合规非常谨慎，毕竟来自美帝的即使是外部的贡献都得考虑删改。如果这是“按揭开源”的原因之一，我觉得特别能体谅。
二、编译器的进攻方向
现代高级编译器多是三层架构: 前中后端。前端是翻译各种语言，中端优化，后端对应出不同类型 CPU 的机器码。中间优化的过程，经常用 IR 来表示，比如 MapleIR。
周老设计 Maple 的初衷据说是前端用 Javascript，即 MapleJS，这样可以实现跨平台和在轻量化的智能 iot 设备上运行和优化。
机缘巧合，华为消费者事业群 (CBG) 在努力实现对阵友商的安卓差异化时，想到静态编译 Java 来实现速度上超越竞争对手，立项联合 2012 的几个团队一起攻坚 MapleJava。
虽然大家都知道 Java 虚拟机开销很大，安卓代码翔山也多，但挑战 Google 里顶尖高手们连续优化了 10 年的虚拟机 (ART)，这个想法可以说无比大胆。
后来的事实证明，MapleJava 这个思路有点天真了。
三、MapleJava 的碰壁
MapleJava 1.0 (即方舟 1.0) 可以说比较成功，它验证了部分静态编译的 App 可以比在谷歌虚拟机上跑得快。
此时刚好碰到美帝的无端制裁，所以余总裁高调宣布了鸿蒙和方舟编译器。但这时，MapleJava 只是实验室产品。
接下来，方舟 2.0 的任务就清晰了，编译适配各种商用 App 和优化方舟 runtime。
大量兼容性的困难随之而来，安卓十年的生态显然不是一个编译器就可以随便破掉的。大家发现方舟 runtime 即使替换掉 ART，也无法完全绕开安卓核心服务。
这样，因为无法完全摆脱了安卓，整个这件事的政治价值大幅度降低了。
更重要的是，抛开各种 bug 和兼容性等负面因素，方舟编译过的 App 比标准安卓 App 在速度上的差异并没有预期那么大，在两者都足够流畅的情况下，意义在哪里呢？
从今天看，MapleJava 的方案被搁置。这也许是这百人团队中很多离职的原因。
客观地说，MapleJava 是一次很不错的尝试，起码绕开了谷歌虚拟机。遗憾的是，MapleJava 的相应 runtime 没有完全开源，这使得开发者们没法继续发掘静态编译 Java App 的潜力。
就在前几天，微软最新的 Windows 11 宣布采用英特尔 Bridge 编译器在 x86 上原生支持安卓 App。
四、鸿蒙对标谁？
MapleJava 的不顺利，导致了后来一系列宣传上的困境，整个鸿蒙的战略给社会带来很多误解。
华为坚持说开源鸿蒙 (LiteOS，后叫 Open Harmony) 和手机鸿蒙 (HarmonyOS) 之间是有关联的，虽然两者内核都不一样。我们探究这种关联很可能指方舟和通讯协议。
早期方舟的开源也许更重要，这毕竟实际展示了挑战巨人的勇气。方舟开源包括了 MapleC，这勉强可以看到对标 Clang-LLVM-> 苹果 Swift 的一条路径。如果手机鸿蒙选了这个路线，应该是鸿蒙在性能上追赶苹果 iOS 的唯一选择。
苹果是静态编译，加上自家编译器对自研 CPU/GPU/NPU 的优化，性能上是安卓没法比的，而且硬件开销也是最小的。
但是，MapleC 这个路线还有 n 年的差距。说服开发者用开发效率低的 C/C++ 语言来做原生鸿蒙程序，是个不可能的挑战。
所以有传言，华为会推出真正对标苹果 Swift 的自有语言：“Maple + 仓颉”。不过新语言的学习周期和生态建立，都需要非常长的时间和投入。
与此相关的是，如果华为不能长期获得 ARMv9 以后的授权，仓颉的优化也许要从 ARM 转到 RISC-V。而 RISC-V 的生态差距仍旧过大，如何下手选择两难。
那么在 MapleJava 之后，华为的选择是什么呢？
虽然最新的鸿蒙架构图里方舟 runtime 被称为方舟“多语言”运行时，但很多人觉得 Javascript (MapleJS) 是主打牌。
五、Javascript 的选择
Javascript 是近年最红的全栈语言，开发效率最高，可以跨平台，甚至可以嵌入平台内作为子平台跑，最典型的例子就是微信小程序。
手机用 JS 做 App 的先驱是 Palm 的 WebOS。WebOS 和 Palm Pre 手机设计理念非常超前：多任务卡片，全屏手势，无线充电等都是多年后才被苹果和安卓抄袭。
WebOS 的标准 Linux+JS 作前端的架构更是有前瞻性，但它超越了时代，那时硬件性能支持 JS App 还是比较吃力的，甚至当时程序员们还不觉得 JS 是个语言。
WebOS 失败后，三星的 Tizen/JS 接棒再战，仍以失败告终。
多年以后，JS 获得了空前的发展。KaiOS, PWA 等等 JS 生态野火重燃，加上硬件性能的冗余，鸿蒙原生 JS 应用成功的概率提高了。网银和电商 App 那种本来就是 Webview 不需要性能的更是没有阻碍。
谷歌 ChromeOS 和强大的 V8 引擎也背书了鸿蒙用 JS 拓展到桌面领域是完全可行的。
当然手机原生 JS App 的挑战也很大，直接用现有框架 (RN, Weex, Webview..) 适配还是比较麻烦，而且很难调用底层和利用 GPU 等硬件特质，游戏性能也受影响。关于这点，我还是很期待看到 MapleJS 的技术突破。
六、务实的做法
在上述 JS 生态建立前，鸿蒙手机的务实做法是同时支持安卓 AOSP 和原生 JS 应用。但是鸿蒙手机系统未完全开源，MapleJS 应用开发框架仍不清晰，所以我们大多数人只看到了 AOSP，外界出现了“套壳安卓”的声音。
在 AOSP 开源的情况下，打造另一套未开源手机生态的价值在哪里，也确实让人困惑。
如果芯片代工问题最终可以解决，各种去美化的 IP 核仍能买到，华为重新走鸿蒙 + 仓颉 + 麒麟的软硬一体路线，那将是非常有勇气和值得钦佩的。这里先为华为保留海思团队点个赞。
用于智能设备的开源鸿蒙 (LiteOS)，在国内自有知识产权和开源 iot 生态已经百花齐放的情况下，价值在哪里，不在本文探讨范围内。
我们目前看到的是，各种不同鸿蒙设备间的通讯机制 (分布式软总线，或叫“万物互联”)，成为鸿蒙的最大卖点。
七、谷歌的 Fuchsia
正巧在鸿蒙 2.0 开源前，谷歌正式发布了 Fuchsia。和沸腾党说的相反，谷歌很低调，并没有描绘 Fuchsia 的前景，只是说它是一个适合“connected devices”的全新的安全的操作系统。
从架构看，Fuchsia 非常模块化，适合拼装快速开发。它似乎在耐心等待各种模块 (轮子) 被造出来，而且鼓励开发者尝试新一些的技术: Rust/Dart/Flutter… 这说明谷歌这次并不着急。
Fuchsia 和安卓的未来关系没有人知道，包括谷歌自己。对谷歌来说，摆脱 Linux GPL 和陈旧的 JDK 也一直是梦想，但它知道这需要漫长的时间和机缘，所以只能低调。
试图对比开源鸿蒙 2.0 和 Fuchsia 我猜是徒劳的，两者几乎没有共通点，除了都号称微内核。
八、愿景
值得八卦一下的是，LLVM 和 Swift 之父 Chris Lattner 从苹果跳槽到特斯拉主管 Autopilot 后，仍想把 Swift 引入特斯拉，结果他理念和马斯克不合只半年就离职了。
这看来像是没有完成从工具到应用的思路转换，迷恋打造锋利的菜刀超过了做菜。
当然这么草率评价大神，在一定程度上展示了我自己的愚蠢。这里只是想善意地祝福鸿蒙，不会因迷恋所谓工具而忘了初心。
从我个人的狭隘视角看，鸿蒙的愿景仍不够清晰：就是她最终能给用户和行业带来什么；“万物互联”对用户来说，和目前的工控、智能家居的区别有多大。
如果鸿蒙放弃最终和苹果的性能对标，退而和安卓比情怀和使用差异化，在芯片问题悬而未决的情况下是务实而且无奈的做法，即使会让一些开发者失望。
九、未来的挑战
华为虽然在产品线上完成了大量 CT 向 IT 的转换，但坦率地说其在 IT 核心技术 (CPU/GPU/OS/ 关键软件等) 上仍存在差距。加之华为还要分兵打造去美化的芯片生产体系，综合挑战是巨大的。
即使在跨平台编译这个小领域，我们也看到英特尔的 Bridge 和苹果的 Rosetta 都展示了硬硬的肌肉。从情感上我们期望一家中国公司就能全方位席卷全球的各个科技巨头，但冷静和脚踏实地还是需要的。
如果华为能充分发挥 CT 上的领先优势，把核心 CT 做成组合专利和软件 IP 组件的霸主，也许更符合任总今年“专注于软件”的战略。举个也许不恰当的小例子，去年的”多屏协同”功能就很不错。
参考微软从痛骂开源到拥抱开源，本人认为华为应该重新考虑一下出山领导 Open RAN。
在极端困难的情况下，华为已经做到了超乎想象的勇敢和坚韧，“软件化和 IP 专利化”也许正是浴火重生前的“黄沙百战穿金甲”。