一、开源协议是什么？

上个世纪 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)规矩，涉案插件也有继受开源答应协 议的职责。

综上所述，拓尔思公司案对组合软件开源确定有误。存放于同一个文件夹的程序并不一定就彼此依靠，存放于不同文件夹的程序也并不一定就彼此独立，组合软件是否为开源演绎著作，应归纳剖析程序的调用、通讯、依靠联络。

总结

开源答应协议是著作权答应合同，具有一般合同和著作权答应合同的两层特色。协议的内容具有合同特征。开源协议归于产生私法上作用的意思标明，而意思标明是民事法令行为的中心要素，因而开源协议是一种民事法令行为。用户在对源代码进行仿制、修正或发布时答应证建立，一起答应证产生法令效能。开源协议以电子文本办法体现其内容，而电子文本是一种有形的体现办法，归于以书面办法缔结的合同。开源协议具有合同性质，可确定为授权人与用户间缔结的著作权协议，归于我国《合同法》调整的范围。

在处理开源答应协议兼容问题的上，应倾向维护被答应人的利益，依据开源答应协议的理念，采用“从旧兼从严”办法，即优先采用版别较旧、开源继受职责较严厉的开源答应协议。

组合的情况下应当归纳剖析程序的调用、通讯、依靠联络，只要单一协议的应当在有调用依靠等联络时恪守这个相应协议，假如多个协议则需求兼容处理。

更多优质文章能够拜访：

QIN.NEWS