开源软件与开源协议的法律问题分析

一、开源协议是什么？

上个世纪 80 年代中后期，美国麻省理工学院的理查德·马修·斯托曼 (Richard M atthew Stallman) 提出了自由软件 (free software) 的概念。Stallman 发表著名的 GNU 宣言，宣布开始一项宏伟计划，创造一套完全自由免费，而又兼容于 Unix 的操作系统 GNU，并于同年成立了自由软件基金会 (Free Software Foundation，FSF)。同时还起草了广为使用的 GNU 通用公共协议证书(GNU General Public License，GNU GPL)，并创造性地提出 copyleft 规则以对抗专有软件的私有属性，规定作者和用户不能对 GNU 的自由软件主张私有化，以保证软件的自由和开源可以不断的延续并且不断扩大。1991 年，芬兰赫尔辛基大学的一名学生 Linus Torvalds 在 GNU GPL 条款下发布自己创作的 Li nux 操作系统，称作 GNU/Linux，成为 GNU 最成功的项目之一。1998 年，E.S.Raymo nd 提出了开放源代码(Open Source) 的新概念。

开源软件最先起源于 Stallman 所提倡的自由软件，但又有所发展。Stallman 坚持其自由软件中的自由为带有政治意味的“自由”并认为传统专有软件禁止用户分享和修改软件是完全错误的，并且也是不道德和反社会的。J. RACINE 认为 FSF 所给予的自由是指自由运行软件、自由研究程序如何运作并能够对其自由调整以适应你的需要、对复制品进行自由组合、自由改进程序以及将你改进的软件自由投放到公共领域。自由软件运动通过五个关键要素分类许可证：

(1) 为任何目的运行程序的自由;

(2)访问修改源代码的自由;

(3)再发布程序副本的自由;

(4)将修改后的版本发布给公众的自由;

(5) 是否是遵循 copyleft 规则的许可证。

前面的四大自由是一致的，而第五个因素则是一种确保四个自由不被从公众领域任意撤回。

美国于 1980 年通过修订版权法以单独立法和判例、命令等形式将软件纳入版权法的保护范围。在美国的大力倡导下，逐渐形成了以《伯尔尼公约》为平台的计算机软件版权法保护模式。传统商业软件的版权特点是软件的私有化，不能对源代码进行随意复制和传播，这些特点在为商业软件开发者带来巨大利益的同时，也阻碍了软件技术的交流和发展。开源软件是通过与软件和源代码一同发布的许可证来实现版权要求的，它可以同时体现和维护开发者和后续使用者的权利和利益。

而我国根据《计算机软件保护条例》我国公民、法人或者其他组织对其所开发的软件，不论是否发表，都可以享有著作权，如发表权、署名权、修改权、复制权、发行权、出租权、信息网络传播权、翻译权等人身权和财产权，其保护权限自然人的软件著作权，保护期为自然人终生及其死亡后 50 年，截止于自然人死亡后第 50 年的 12 月 31 日;软件是合作开发的，截止于最后死亡的自然人死亡后第 50 年的 12 月 31 日。法人或者其他组织的软件著作权，保护期为 50 年，截止于软件首次发表后第 50 年的 1 2 月 31 日，但软件自开发完成之日起 50 年内未发表的，不再受该条例的保护。

与商业软件类似，开源软件也包括程序源代码和相关的文档，这些都是受版权保护的对象。虽然开源软件的权利人通过许可证放弃了对开源软件的复制权、修改权、发行权，但是这并不代表他人可以肆意使用。任何人如果要对一个已经通过 OSIA 认证的开源软件进行复制、修改并再次发行，其必须遵守该开源软件所附带许可证的规定。

2008年8月13日，美国联邦巡回上诉法院对Jacobsen v. Katzer案作出的判决对开源许可协议的强制性作出了认定。其在判决中认定，“开源软件许可条件明确的前提下，使用者一旦复制、修改或发布该开源软件即被视为承认该开源软件的许可条件，该开源软件许可协议具有《著作权法》规定的强制力”。

二、主流开源协议介绍

Apache License

Apache License（Apache许可证），是Apache软件基金会发布的一个自由软件许可证。

Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和最终原作者的著作权，同样允许源代码修改和再发布。但是也需要遵循以下条件：

需要给代码的用户一份Apache Licence。
如果修改了代码，需要再被修改的文件中说明。
在衍生的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以再Notice中增加自己的许可，但是不可以表现为对Apache Licence构成更改。
Apache Licence也是对商业应用友好的许可。使用者也可以再需要的时候修改代码来满足并作为开源或商业产品发布/销售。

使用这个协议的好处是:

永久权利一旦被授权，永久拥有。
全球范围的权利在一个国家获得授权，适用于所有国家。假如你在美国，许可是从印度授权的，也没有问题。
授权免费无版税，前期、后期均无任何费用。
授权无排他性任何人都可以获得授权
授权不可撤消一旦获得授权，没有任何人可以取消。比如，你基于该产品代码开发了衍生产品，你不用担心会在某一天被禁止使用该代码

BSD

BSD是"Berkeley Software Distribution"的缩写，意思是"伯克利软件发行版"。

BSD开源协议：是一个给于使用者很大自由的协议。可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：

1．如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
2．如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
3．不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。

GPL

GPL （GNU General Public License）：GNU通用公共许可协议。

Linux 采用了 GPL。

GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。

LGPL

LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。

但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。

GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。

MIT

MIT是和BSD一样宽范的许可协议,源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称X11协议。作者只想保留版权,而无任何其他了限制。MIT与BSD类似，但是比BSD协议更加宽松，是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有：jquery、Node.js。

MIT与BSD类似，但是比BSD协议更加宽松，是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有：jquery、Node.js。

MPL (Mozilla Public License 1.1)

MPL协议允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者。这种授权维护了商业软件的利益，它要求基于这种软件的修改无偿贡献版权给该软件。这样，围绕该软件的所有代码的版权都集中在发起开发人的手中。但MPL是允许修改，无偿使用得。MPL软件对链接没有要求。

EPL (Eclipse Public License 1.0)

EPL允许Recipients任意使用、复制、分发、传播、展示、修改以及改后闭源的二次商业发布。

使用EPL协议，需要遵守以下规则：

当一个Contributors将源码的整体或部分再次开源发布的时候,必须继续遵循EPL开源协议来发布,而不能改用其他协议发布.除非你得到了原"源码"Owner 的授权；
EPL协议下,你可以将源码不做任何修改来商业发布.但如果你要发布修改后的源码,或者当你再发布的是Object Code的时候,你必须声明它的Source Code是可以获取的,而且要告知获取方法；
当你需要将EPL下的源码作为一部分跟其他私有的源码混和着成为一个Project发布的时候,你可以将整个Project/Product以私人的协议发布,但要声明哪一部分代码是EPL下的,而且声明那部分代码继续遵循EPL；
4.独立的模块(Separate Module),不需要开源。

Creative Commons 知识共享协议

Creative Commons (CC) 许可协议并不能说是真正的开源协议，它们大多是被使用于设计类的工程上。 CC 协议种类繁多，每一种都授权特定的权利。一个 CC 许可协议具有四个基本部分，这几个部分可以单独起作用，也可以组合起来。下面是这几部分的简介：

1、署名作品上必须附有作品的归属。如此之后，作品可以被修改，分发，复制和其它用途。
2、相同方式共享作品可以被修改、分发或其它操作，但所有的衍生品都要置于CC许可协议下。
3、非商业用途作品可以被修改、分发等等，但不能用于商业目的。但语言上对什么是"商业"的说明十分含糊不清 (没有提供精确的定义)，所以你可以在你的工程里对其进行说明。例如，有些人简单的解释"非商业"为不能出售这个作品。而另外一些人认为你甚至不能在有广告的网站上使用它们。还有些人认为"商业"仅仅指你用它获取利益。
4、禁止衍生作品

CC 许可协议的这些条款可以自由组合使用。大多数的比较严格的CC协议会声明 "署名权，非商业用途，禁止衍生"条款，这意味着你可以自由的分享这个作品，但你不能改变它和对其收费，而且必须声明作品的归属。这个许可协议非常的有用，它可以让你的作品传播出去，但又可以对作品的使用保留部分或完全的控制。最少限制的CC协议类型当属 "署名"协议，这意味着只要人们能维护你的名誉，他们对你的作品怎么使用都行。

CC 许可协议更多的是在设计类工程中使用，而不是开发类，但没有人或妨碍你将之使用与后者。只是你必须要清楚各部分条款能覆盖到的和不能覆盖到的权利。

三、开源协议的法律性质

开源许可证决定了开源社群如何发展和分发软件，并决定了开源项目的发展。在国际上，对于典型的开源软件许可证 GPL 是否属于合同存在着两种不同的观点。一种观点是主张 GPL 本身并不是合同，不应当适用合同法对其进行调整。该说认为:“合同的有效成立必须经过当事人双方通过公开、公平的谈判，而 GPL 的成立并没有经过自由软件的发行者和被许可人之间的谈判，双方没有达成一致的意思表示。” GPL 作为自由软件发行时捆绑的一个文件，其成立没有经过传统合同的要约和承诺两个阶段，所以其认为 GPL 并不能作为合同看待。

在维基百科上对于 GPL 的解说中也认为 GPL 是以一种许可证形式设计出来的而不是以合同的身份。其认为在英美法系国家中，许可证与合同在法律上还是有明确的区别的，GPL 只是一种可以寻求版权保护的许可证，但是其也承认在大陆法系中则没有这种区别。但是第二种观点则认为 GPL 无论是在英美法系还是在大陆法系中都应当作为一种赋予被许可人特殊权利的版权许可合同看待。其以美国法律为例，认为美国的版权法是一部全国统一的法律，根据版权法获得的权利是一种法定权利，被许可人根据版权法除使用权以外都只是一些禁止性的规定，如果要获得复制、修改、发布这些属于版权人的权利，只能通过许可证的形式来赋予，因此应该将 GPL 看成是一个合同，受合同法的调整。

我们来看个真实案例——2021年9月，广州知识产权法院就罗盒网络科技有限公司（以下简称罗盒公司）诉玩友网络科技有限公司（以下简称玩友公司）等侵害软件著作权纠纷一案。

2016 年 7 月，罗盒公司的股东罗迪在 Github 网站上传了其开发的 VirtualApp 软件初始源代码并引入 LGPLv3.0 开源许可协议（后更改为 GPLv3 协议），随后声明任何人如需将该软件用于商业用途需向其购买商业授权。2017 年 12 月，罗盒公司转为开发不开源的商业版本，并停止了开源版本的更新。

玩友公司开发了四款被诉侵权的微信视频美颜相机 APP 并上传于各平台供用户下载，但并未提供源代码。罗盒公司认为四款被诉侵权软件中的沙盒分身功能与原告于 2017 年 12 月 30 日在 GitHub 网站上发布的 VirtualApp 开源版本（下称“涉案软件”）构成实质性相似，玩友公司不提供开源代码且收取会员费的行为违反 GPLv3 开源许可协议，侵害其涉案软件著作权，遂诉至法院。广州知识产权法院认为，玩友公司收取被诉侵权软件的会员费并不违反 GPLv3 协议的规定，但是，使用涉案软件开发的商业软件需遵守 GPLv3 协议公开其全部源代码，玩友公司未向用户提供被诉侵权软件源代码下载，违反了 GPLv3 开源许可协议的约定，侵害了涉案软件著作权。广州知识产权法院依法判令玩友公司停止提供含有沙盒分身功能源代码的四款软件的下载、安装和运营服务，并赔偿罗盒公司经济损失及维权合理支出共计 50 万元。一审宣判后，双方当事人均未上诉。

前述已说明，因本案权利软件 VirtualApp 为适用 GPLv3 开源协议的软件，所以本案是否构成著作权侵权，需先行判断我国法律是否承认 GPLv3 开源协议的效力及认定其为什么法律属性的文件。

法院参考美国、德国等域外判例对 GPL 开源授权许可协议性质的认定，并结合我国涉合同相关法律的规定，最终认定：GPLv3 协议具有合同性质，是授权方和用户订立的格式化著作权协议，属于我国合同法调整的范围。

第一，GPLv3 协议的内容具备合同特征，属于广义的合同范畴。开源软件协议属于软件权利人和用户之间订立的合同，开源软件的发布视为发出要约，用户使用视为承诺，在用户使用开源软件时合同成立。

第二，GPLv3 协议是非典型合同。该协议是开源软件的作者向不特定的使用者让渡其著作权的部分人身权利和全部财产权利，权利授予的对象是不确定的，以换取使用者承诺遵守开源许可协议的许可条件和义务，开源软件许可协议并没有权利转让的对价或许可使用付酬等典型著作权许可合同的主要条款。

第三，GPLv3 协议是格式合同。GPLv3 协议是为特定开源项目开发而预先拟定，由著作权持有人向软件程序使用者提供的合同条款。……格式化条款保持承继性，且不属于格式合同条款无效的情形，其授权内容符合我国著作权法的规定，合法有效。

第四，对协议的承诺是通过行为作出的。GPLv3 协议第 9 条规定，一旦修改和传播一个受保护作品，就表明你接受本协议。

GPLv3 协议第 8 条“终止授权”规定，除非在本协议明确授权下，你不得传播或修改受保护作品。其他任何传播或修改受保护作品的企图都是无效的，并将自动终止你通过本协议获得的权利。

据此，法院认定，GPLv3 协议属于附解除条件的著作权合同，许可条款是版权许可的条件，如果用户违背条款规定，那么许可的前提条件已不复存在，则 GPLv3 协议终止适用，用户获得的授权也将自动终止。玩友公司未向用户提供被诉侵权软件源代码下载已经违反 GPLv3 协议规定，则玩友公司对涉案软件源代码的复制、发布行为因失去权利来源而构成侵权。即对违反开源协议的行为存在违约救济和侵权救济两种，守约方可以自行选择。本案罗盒公司选择主张追究玩友公司的著作权侵权责任。法院最终认定，玩友公司未向用户提供被诉侵权软件源代码下载，违反了 GPLv3 开源许可协议的约定，侵害了涉案软件 VirtualApp 软件发行权和信息网络传播权，承担停止侵权和赔偿损失的法律责任。

本案判决明确承认了在中国法下开源许可证的合同属性，并认定了违反 GPLv3 开源协议的行为构成著作权侵权。

我们来看另一个案子——原告济宁市罗盒网络科技有限公司诉被告福建风灵创景科技有限公司(以下简称福建风灵公司)、被告北京风灵创景科技有限公司(以下简称北京风灵公司)、被告深圳市腾讯计算机系统有限公司(以下简称腾讯公司)侵害计算机软件著作权纠纷一案。

法院认为开源软件依赖于现有著作权及相关法律体系的保护，授权人只在享有著作权的情况下，其通过许可证将权利有条件进行许可或让渡才有法理依据。关于 GPL3.0 协议的法律性质。其一，协议的内容具备合同特征。GPL3.0 协议属于发生私法上效果的意思表示，而意思表示是民事法律行为的核心要素，因此 GPL3.0 协议是一种民事法律行为。该协议授予用户复制、修改、再发布等权利，实际上在授权人和用户间形成了权利变动，属于设立、变更、终止民事权利义务关系的民事法律行为。授权人许可的权利符合我国著作权法的相关规定；其采用开源许可证发布源代码，将自己的大部分著作权授予不特定用户，完全是出于自愿。用户在许可证下复制、修改或再发布源代码，通过行为对许可证作出承诺，也是出于自愿。用户在对源代码进行复制、修改或发布时许可证成立，同时许可证发生法律效力。其二，协议的形式亦具备合同特征。GPL3.0 协议以电子文本方式表现其内容，而电子文本是一种有形的表现形式，属于以书面形式订立的合同。综上所述，GPL3.0 协议具有合同性质，可认定为授权人与用户间订立的著作权协议，属于我国《合同法》调整的范围。

关于违反 GPL3.0 协议的侵权责任。著作权法为了保护权利人的专有权，仅规定非权利人可以在如“合理使用”等范围内使用作品，诸如复制、修改、发行等权利则专属于权利人，任何人非经许可实施这些行为将构成侵权。根据 GPL3.0 协议第 8 条“终止授权”的约定，授权人许可用户在遵守许可证规定的前提下行使某些权利，但用户必须承担相应的义务。若用户违反 GPL3.0 协议的使用条件来复制、修改或传播受保护的作品，其通过 GPL3.0 协议获得的授权将会自动终止。对此，我国《民法总则》第一百五十八条规定：“民事法律行为可以附条件……附解除条件的民事法律行为，自条件成就时失效”。根据开源软件的特性，GPL3.0 协议规定的使用条件（如开放源代码、标注著作权信息和修改信息等）系授权人许可用户自由使用的前提条件，亦即协议所附的解除条件。一旦用户违反了使用的前提条件，将导致 GPL3.0 协议在授权人与用户之间自动解除，用户基于协议获得的许可即时终止。用户实施的复制、修改、发布等行为，因失去权利来源而构成侵权。明确违反开源软件许可证的侵权法律责任，一方面可以及时制止侵权行为，防止他人对开源软件的不正当利用；另一方面能够有效保护授权人的利益，使他们保有继续创作的动力，促进源代码共享和知识的传播。

针对原告的诉讼行为是否符合 GPL3.0 协议关于争议解决方式的约定问题。被告认为根据 GPL3.0 协议第 10 条的规定，不允许开源代码的授权人发起诉讼。回归该条的相关内容，其表述为：“你不可以对本协议所授或确认的权利的行使施以进一步的限制。例如，你不可以索要授权费或版税，或就行使本协议所授权利征收其他费用；你也不能发起诉讼（包括交互诉讼和反诉），宣称制作、使用、销售、批发、引进本程序或其部分的行为侵害了任何专利权”。由此可见，该条款仅限制授权人不得向用户主张任何专利权，而并未限制授权人对违反许可协议的用户主张著作权。因此，原告的诉讼行为并未违反 GPL3.0 协议关于争议解决方式的约定。

针对上述两个案子我们可以确定，GPL3.0 协议的法律性质。其一，协议的内容具备合同特征。GPL3.0 协议属于发生私法上效果的意思表示，而意思表示是民事法律行为的核心要素，因此 GPL3.0 协议是一种民事法律行为。该协议授予用户复制、修改、再发布等权利，实际上在授权人和用户间形成了权利变动，属于设立、变更、终止民事权利义务关系的民事法律行为。授权人许可的权利符合我国著作权法的相关规定；其采用开源许可证发布源代码，将自己的大部分著作权授予不特定用户，完全是出于自愿。用户在许可证下复制、修改或再发布源代码，通过行为对许可证作出承诺，也是出于自愿。用户在对源代码进行复制、修改或发布时许可证成立，同时许可证发生法律效力。其二，协议的形式亦具备合同特征。GPL3.0 协议以电子文本方式表现其内容，而电子文本是一种有形的表现形式，属于以书面形式订立的合同。综上所述，GPL3.0 协议具有合同性质，可认定为授权人与用户间订立的著作权协议，属于我国《合同法》调整的范围。所以开源协议具备法律性质。

四、开源协议之间的兼容性

讨论兼容问题，就得先考虑兼容问题的前提。只有发行、再传播作品时，才涉及兼容问题，若不实施发行、传播行为，即使开源许可协议之间相互冲突，也不妨碍用户使用软件。那么满足前提后，何为兼容状态呢?一种开源许可协议和另一种开源许可协议并存时，用户选择了其中一个开源许可协议发布软件，并且没产生任何冲突，则未被选择的协议被选择了的协议所兼容。需注意，兼容不能逆推，若 A 协议兼容 B 协议，不能反推 B 协议也兼容 A 协议。最后，兼容性的比较，开源继受要求低的协议(弱许可协议，如 MIT)比要求高的协议(强许可协议，如 GPL)的兼容性要好。

《中华人民共和国民法总则》第一百四十二条规定了“温和表示主义”的解释原则。温和表示主义即原则上采表示主义，例外采意思主义。该原则适用于普通著作权许可合同。而开源许可协议是附解除条件的格式合同，理应适用格式条款的解释规则。对于格式条款的解释，应采用客观解释的原则，且以客观理性人的平均而合理的理解能力为基准，当条款之间出现矛盾时，尽可能进行调和。同时，由于开源许可协议是平等民事主体根据意思自治原则订立的合同，所以不存在效力高低的问题。开源许可协议的成立途径为单方允诺，著作权人单方事先设定开源许可协议，并在合同未成立之前可以行使撤销权，享有更多的主动权，因此，在处理开源许可协议兼容问题的上，应倾向保护被许可人的利益，根据开源许可协议的理念，采纳“从旧兼从严”方法，即优先采纳版本较旧、开源继受义务较严格的开源许可协议。

我们来看一个真实的案例——数字公司诉柚子公司著作权侵权案。

2013 年 10 月，数字天堂(北京)网络技术有限公司(下称数字公司)开发了 HBuilder 软件，并进行了著作权登记。2014 年 9 月，数字公司发现柚子(北京)科技有限公司、柚子(北京)移动技术有限公司(下称柚子公司)通过官网发布了一款名为 APICloud 的软件，经过比对，APICloud 软件的源代码与 HBuilder 软件中的三个插件的源代码相同。据此，数字公司认为柚子公司侵犯了其对 HBuilder 软件插件享有的著作权，于是向北京知识产权法院提起了诉讼。但柚子公司并不认可侵权，其认为开源软件区别于普通软件，复制开源软件的源代码行为并不是侵权行为。柚子公司主张涉案软件受 GPL 协议(一种开源许可协议) 的约束而成为开源软件，根据开源许可协议的授权，柚子公司无需经过数字公司的许可，有权使用 HBuilder 软件插件源代码并构建衍生软件产品。

在数字公司诉柚子公司著作权侵权案中，HBuilder 软件中，除了包含涉案插件和 Aptana 插件之外还有第三方插件。若涉案插件、Aptana 插件和第三方插件存在关联通信关系，涉案插件将被传染上多种开源许可协议。一旦多种协议相互冲突，发布软件时就会产生兼容问题。回顾案件，可以发现 HBuilder 软件中的第三方插件文件夹中具有 EPL 开源许可协议。借助继受开源许可协议的界定标准，发现涉案插件也是第三方插件的演绎作品。因此，涉案插件除了需要继受 GPL 下的开源许可协议之外，还需要继受 EPL 下的开源许可协议。这就需要分析 EPL 和 GPL 间是否存在兼容问题。

Eclipse基金会自己推出了EPL开源许可证，被广泛应用于 Eclipse 基金会旗下的开源软件和 Eclipse 插件之中。EPL 对开源协议的继受要求较低。开源促进会在 2006 年针对兼容问题的研究报告中指出 EPL 和 GPL 不兼容。因此，涉案插件要想和第三方插件连接必须做 GPL 例外声明，而 Aptana 官网在例外说明中强调只有非演绎作品才能做例外声明，所以涉案插件存在 EPL 和 GPL 的兼容问题。故，需要借助兼容问题的处理规则，对两个开源许可协议的冲突作出解释处理。从传染性的强度来看，EPL 更加商业友好，被其他软件使用和集成时并不要求继受开源许可协议。而 GPL 的传染性极强，具有严格的继受要求。所以，根据上述“从旧兼从严”的兼容处理规则，涉案插件最终受 EPL 下的开源许可协议约束。因此，涉案插件是开源软件，柚子公司有权主张开源抗辩。根据 EPL 的规定，数字公司可以不公开源代码，但不能妨碍下游用户柚子公司使用。

我们在看一个真实的案例——众所周知，Google 的 Android 中是包含了 Linux 内核的。而 Linux 采用的 GPL 协议有很强的「传染性」。那么 Google 为什么可以采用和 GPL v2不兼容的 Apache 2.0 协议来发布 Android 而不会受到 GPL 的影响呢？

Android 与 GNU/Linux 操作系统非常不同，因为它包含很少的 GNU。事实上，Android 和 GNU/Linux 之间唯一的共同之处就是 Linux 内核。那些错误地认为 “Linux” 指的是整个 GNU/Linux 组合的人被这些事实弄得很纠结，并做出诸如 “Android包含Linux，但它不是Linux” 这样自相矛盾的陈述。因此，Android 和 GNU/Linux 在很大程度上是不同的，因为它们的共同点就是 Linux。

在 Android 中，Linux 内核仍然是一个独立的程序，其源代码在 GNU GPL v 2 下。

最关键点是 Linus Torvalds 在 Linux 内核版权最前的一段话，保证了 Linux 内核GPLv2 不传染。

NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.

Also note that the only valid version of the GPL as far as the kernel
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.

Linus Torvalds

五、组合部分是否受开源协议影响

组合软件是指由开源部件与专有部件相结合所形成的软件，常见安装包形式为专有软件与开源软件共存于同一文件夹。如数字公司的 HBuilder 软件，既包含专有部件如涉案插件，又包含开源插件如软件Aptana，涉案插件与开源Aptana 插件共存于同一个文件中;拓尔思公司的“TRS 内容协作平台”软件，专有部件的页面与开源软件 FCKeditor 编辑器共存于同一的文件夹中。在软件行业中，存在“组合软件就是开源软件”的看法。在拓尔思公司软件侵权案中，原告拓尔思公司承认涉案软件为组合软件，其中存有小部分开源代码。被告捷报公司便以涉案软件为组合软件为开源抗辩理由，主张不侵权。该案的一审法院，结合原告举证不能的事实，驳回了被告的开源抗辩。。二审法院认为，虽然涉案软件为组合软件，但是被告的开源抗辩不具有针对性，过于模糊笼统。可以看出，一二审法院以默示的方式认定组合软件为开源软件。这种做法是否正确呢?本文认为以软件的表现形式一刀切地判定软件的开源属性过于草率。组合软件中存有开源许可协议，所以需分析该开源许可协议能否规制专有部件的许可协议，换言之，组合软件的专有部件是否继受开源协议。而认定组合软件是否为开源演绎作品，同样需要比照开源演绎行为的认定标准。

数据调用是软件之间常见的联系方式，其目的是共享信息。当调用的信息为开源信息时，就需判断数据调用行为是否为开源演绎行为。HBuilder 软件与外部软件 Aptana 都是集成开发环境(DLL)，故需考虑二者在联系方式上是否采用了动态链接。根据插件运行的原理可知，当开发人员使用于 Eclipse 开发工具时，总有同时运行 HBuilder 插件与 Aptana 插件的需求，而只有这两个集成开发环境能互相调取彼此的信息时才同时运行，为开发工作服务，因此行 HBuilder 软件中必然存有开源软件 Aptana 的信息。

HBuilder 软件与外部 Aptana 软件都属于 Eclipse 开发平台的整合型插件。整合型插件互相独立的，程序通过相互调用实现共享数据库。插件主要分为对象插件以及动态性 DLL 插件。HBuilder 软件与外部 Aptana 软件的管道、套接和命令行参数通常为同一个通信的机制，它们的通信的语义密切，插件在与主程序进行技术上的沟通和联系时，是通过 API 与主程序进行数据注入或数据信息交换来实现其功能的。通过 API，HBuilder 软件获取了 Aptana 软件的数据。因此，HBuilder 软件涉案插件对外部 Aptana 插件实施了整理行为，是外部 Aptana 插件的演绎作品。根据外部软件 Aptana 的开源许可协议(GPL)规定，HBuilder 软件有义务继受同样的开源许可协议。

插件的定位是开发实现原纯净系统平台、应用软件平台不具备的功能的程序，因为插件需要调用原纯净系统提供的函数库或者数据，所以不能脱离指定的平台单独运行。必然要和本体软件进行一些数据交换。1第三方插件对宿主软件有很强的依赖性，如果宿主软件不运行，则第三方插件就无法实现其针对宿主软件的功能。涉案插件与 Aptana 插件共存于宿主软件 HBuilder 中，如同网站中的文本框植入技术，通过静态链接产生画中画电视屏幕效果。

涉案插件与 Aptana 插件都扩展了宿主软件的功能，则这两个插件具有调用、通信、依赖关系。虽然 Aptana 插件与涉案插件都独立存放在宿主软件 HBuilder 的根目录的子文件中，但并不能说明其没有任何关联。任意删除 HBuilder 软件下的“org.eclipse、org.apache、com.aptana”为前缀的文件或目录 JAR 文件，将得出涉案插件无法运行的结论。这就表明在 HBuilder 软件内部，涉案插件与 Aptana 插件是有关联度的。因此涉案插件是内部 Aptana 插件的演绎作品，根据内部插件 Aptana 的开源许可协议(GPL)规定，涉案插件也有继受开源许可协议的义务。

综上所述，拓尔思公司案对组合软件开源认定有误。存放于同一个文件夹的程序并不一定就相互依赖，存放于不同文件夹的程序也并不一定就相互独立，组合软件是否为开源演绎作品，应综合分析程序的调用、通信、依赖关系。

总结

开源许可协议是著作权许可合同，具有一般合同和著作权许可合同的双重属性。协议的内容具备合同特征。开源协议属于发生私法上效果的意思表示，而意思表示是民事法律行为的核心要素，因此开源协议是一种民事法律行为。用户在对源代码进行复制、修改或发布时许可证成立，同时许可证发生法律效力。开源协议以电子文本方式表现其内容，而电子文本是一种有形的表现形式，属于以书面形式订立的合同。开源协议具有合同性质，可认定为授权人与用户间订立的著作权协议，属于我国《合同法》调整的范围。

在处理开源许可协议兼容问题的上，应倾向保护被许可人的利益，根据开源许可协议的理念，采纳“从旧兼从严”方法，即优先采纳版本较旧、开源继受义务较严格的开源许可协议。

组合的情况下应当综合分析程序的调用、通信、依赖关系，只有单一协议的应当在有调用依赖等关系时遵守这个相应协议，如果多个协议则需要兼容处理。