www.9778.com 1

中国 GPL 诉讼第一案:关于 GPL 问题的探讨

2019 年 11
月初,数字天堂(北京)网络技术有限公司(下称:数字天堂)诉柚子(北京)科技有限公司、柚子(北京)移动技术有限公司(下称:两柚子)侵犯计算机软件著作权纠纷案,由北京高级人民法院二审作出终审判决。笔者曾密切关注该案,终审判决生效前,囿于关联代理关系的利益冲突,不便多谈。现将本案相关若干问题梳理成文,愿与各位探讨之。

     
最近博客园上对开源的讨论比较多,开源作为一种文化,和传统的专利一样,需要了解各种开源协议,正好看到一篇介绍开源协议的blog,转载如下:
原文地址       
     
之前对开源协议没有什么清晰的概念,总以为开源就是免费甚至为所欲为。前些天花了一天时间,看了些关于开源协议的资料。

一、常用开源协议汇总图

首先从一张图开始,介绍几种主流的开源协议,以及决定选用哪种框架的思路。
使用哪种开源协议,决定了你发布的开源项目被别人使用了之后,别人的项目是否受到你的项目的开源协议的约束、受到哪种约束。
同理,采用别人的开源项目时,也要留意开源协议,这直接影响到日后你的项目是否需要开源、是否需要采用同样的许可证、是否需要对修改的源码进行文档说明、是否需要再修改过的文件中放置版权说明、衍生软件的广告等。

www.9778.com 1

常用开源协议汇总图

本案之所以受关注,是因为本次计算机软件著作权侵权案涉及开源软件和 GPL
许可证,本案的判决对未来开源软件诉讼实践有重要意义。本案一审法院对 GPL
相关条款作了阐述,二审法院回避了 GPL
问题。本文,笔者基于本案事实和法院判决做些思考,分享给大家讨论。本文将仅对涉及开源软件及
GPL 许可证的内容进行论述,其他法律问题不作探讨。

常用开源协议解析

二、常用开源协议简介

现今存在的开源协议很多,而经过Open Source
Initiative组织通过批准的开源协议目前有83种:https://opensource.org/licenses/alphabetical

那么,要如何从这么多的开源协议中选取适合自己项目的协议呢?
在这里我们参考:Open Source Licenses by
Category(开源协议分类)
中的:Licenses that are “popular and widely-used or with strong
communities”(被广泛应用或被大社区使用的开源协议)中所列出的几个协议作简要说明:(中文简介摘录参考文章[1])

  1. Apache License 2.0
    (Apache-2.0)

Apache
Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似,同样鼓励代码共享和尊重原作者的著作权,同样允许代码修改,再发布(作为开源或商业软件)。需要满足的条件也和BSD类似:
1)需要给代码的用户一份Apache Licence
2)如果你修改了代码,需要再被修改的文件中说明。
3)在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议,商标,专利声明和其他原来作者规定需要包含的说明。
4)如果再发布的产品中包含一个Notice文件,则在Notice文件中需要带有Apache
Licence。你可以在Notice中增加自己的许可,但不可以表现为对Apache
Licence构成更改。
Apache
Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。

  1. 3-clause BSD license
    (BSD-3-Clause)

BSD (3-Clause) License
BSD允许使用者修改和重新发布代码(以其他协议形式),允许闭源商业发布和销售。
BSD鼓励代码共享的同时,要求尊重代码作者的著作权。
使用BSD协议,需要遵守以下规则:
1
再发布的产品中包含源代码,则在源代码中必须带有原来代码中的BSD协议;
2
如果再发布的只是二进制类库/软件,则需要在类库/软件的文档那个和版权声明中包含原来代码中的BSD协议;
3 不可以用开源代码的“作者/机构的名字”或“原来产品的名字”做市场推广。

  1. 2-clause BSD license
    (BSD-2-Clause)

与 “3-clause BSD license (BSD-3-Clause)” 的内容形似。

  1. GNU General Public License
    (GPL)

GPL v2
我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache
Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux,包括商业公司的linux和linux上各种各样的由个人,组织,以及商业软件公司开发的免费软件了。
GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用,修改后的代码或者衍生代码)GPL
协议的产品,则该软件产品必须也采用GPL协议,既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题,还可以享受免费的优势。
由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议,对于使用GPL协议的开源代码,商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。
GPL v3
GPL v3与GPL
v2类似。区别在于,不仅要求用户公布修改的源代码,还要求公布相关硬件。

  1. GNU Lesser General Public License
    (LGPL)

LGPL v2.1
LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。
但是如果修改LGPL协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用,但不适合希望以LGPL协议代码为基础,通过修改和衍生的方式做二次开发的商业软件采用。
GPL/LGPL都保障原作者的知识产权,避免有人利用开源代码复制并开发类似的产品
LGPL v3
相对于LGPL v2,不仅要求用户公布修改的源代码,还要求公布相关硬件。

  1. MIT license
    (MIT)

MIT License
MIT许可证之名源自麻省理工学院(Massachusetts Institute of Technology,
MIT),又称「X条款」(X License)或「X11条款」(X11 License)
MIT内容与三条款BSD许可证(3-clause BSD
license)内容颇为近似,但是赋予软体被授权人更大的权利与更少的限制。
被授权人有权利使用、复制、修改、合并、出版发行、散布、再授权及贩售软体及软体的副本。
被授权人可根据程式的需要修改授权条款为适当的内容。
在软件和软件的所有副本中都必须包含版权声明和许可声明。
此授权条款并非属copyleft的自由软体授权条款,允许在自由/开放源码软体或非自由软体(proprietary
software)所使用。
此亦为MIT与BSD(The BSD license, 3-clause BSD
license)本质上不同处。
MIT条款可与其他授权条款并存。另外,MIT条款也是自由软体基金会(FSF)所认可的自由软体授权条款,与GPL相容。

  1. 中国 GPL 诉讼第一案:关于 GPL 问题的探讨。Mozilla Public License 2.0
    (MPL-2.0)

Mozilla Public License Version 2.0
MPL是The Mozilla Public License的简写,是1998年初Netscape的
Mozilla小组为其开源软件项目设计的软件许可证。MPL许可证出现的最重要原因就是,Netscape公司认为GPL许可证没有很好地平衡开发者对
源代码的需求和他们利用源代码获得的利益。同著名的GPL许可证和BSD许可证相比,MPL在许多权利与义务的约定方面与它们相同(因为都是符合OSIA
认定的开源软件许可证)。但是,相比而言MPL还有以下几个显著的不同之处:

MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来,以保证其他人可以在MPL的条款下共享源代码。但是,在MPL
许可证中对“发布”的定义是“以源代码方式发布的文件”,这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口,除了接口程序的源代码以MPL
许可证的形式对外许可外,源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些,就为借鉴别人的源代码用做自己商业软件开发的行为留了一个
豁口。

MPL许可证第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。

对软件专利的态度,MPL许可证不像GPL许可证那样明确表示反对软件专利,但是却明确要求源代码的提供者不能提供已经受专利保护的源代码(除非他本人是
专利权人,并书面向公众免费许可这些源代码),也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。
• 对源代码的定义

而在MPL(1.1版本)许可证中,对源代码的定义是:“源代码指的是对作品进行修改最优先择
取的形式,它包括:所有模块的所有源程序,加上有关的接口的定义,加上控制可执行作品的安装和编译的‘原本’(原文为‘Script’),或者不是与初始
源代码显著不同的源代码就是被源代码贡献者选择的从公共领域可以得到的程序代码。”

MPL许可证第3条有专门的一款是关于对源代码修改进行描述的规定,就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述。

  1. Common Development and Distribution License version 1.0
    (CDDL-1.0)

  2. Eclipse Public License version
    2.0

Eclipse Public License v1.0
EPL允许使用者任意使用、复制、分发、传播、展示、修改以及改后闭源的二次商业发布。
使用EPL协议,需要遵守以下规则:
1
当一个代码贡献者将源码的整体或部分再次开源发布的时候,必须继续遵循EPL开源协议来发布,而不能改用其他协议发布.除非你得到了原“源码”拥有者的授权;
2
EPL协议下,你可以将源码不做任何修改来商业发布.但如果你要发布修改后的源码,或者当你再发布的是二进制文件的时候,你必须声明它的源代码是可以获取的,而且要告知获取方法;
3
当你需要将EPL下的源码作为一部分跟其他私有的源码混和着成为一个Project发布的时候,你可以将整个Project/Product以私人的协议发布,但要声明哪一部分代码是EPL下的,而且声明那部分代码继续遵循EPL;
4 独立的模块(Separate Module),不需要开源。

参考地址:
1.
简书:关于开源的一些注意事项
2.
如何选择开源许可证?

案情简介

为节省篇幅,以下对案情进行摘要和总结,详细案情可见一审链接和二审链接。

经过一审和二审对事实的调查和确认,两柚子认可:

  1. 数字天堂是 HBuilder 软件的著作权人;
  2. 数字天堂拥有 HBuilder
    软件中的代码输入法功能插件、真机运行功能插件、边改边看功能插件源代码著作权;
  3. 两柚子的 APICloud
    软件中对应插件源代码部分与涉案的三个插件具有同一性。

基于此,针对本著作权侵权控诉,两柚子抗辩理由只有 GPL
开源许可协议这一个突破口。而二审中对涉案代码量、侵权产品数量的认定,以及基于此对赔偿额的认定,只是量的维度问题。 

看‘谈谈open source
‘有感!

开源许可证是法律文件

一审法院虽未明确 GPL 许可证的法律效力,但在论述涉案三个插件是否受 GPL
协议限制时,默认了 GPL
许可证具有法律约束力。这一点虽然是意料之中,但毕竟开源理念和大部分开源协议来源于国外,且应用于开源社区特定人群,这一认定给未来涉及开源软件的诉讼消除了部分不确定性。为了强调协议内容,下文涉及
GPL 许可证的除特指许可证本身外,都以 GPL 协议指代。

法院虽然默认了 GPL
协议具有约束力,即类似于协议或合同的法律效果,但并未进一步将 GPL
协议条款基于我国著作权法进行解释。社区内关于 GPL 协议的解释,特别是关于
GPL
传染性的解释是基于美国版权法,其能否为国内法院认可,依然存在不确定性。

随着开源理念的深入以及开源软件在世界范围内的普及,本案作为中国 GPL
第一案,对未来开源软件相关的诉讼意义重大。稍有遗憾的是,两审法院并未就开源软件以及
GPL 协议的关键问题进行阐述。当然,也不可能期待 GPL
问题通过一次诉讼案件完全解决,未来还需要更多的法律、学术、技术等人士贡献智慧。 

常用开源协议讨论

关于一审认定的思考

既然法院确认了 GPL 协议的法律约束力,那么对 GPL
协议的解释要么采取社区通说解释,要么基于我国著作权法作独立解释。否则很容易出现矛盾或模糊,以至于增加企业开源实践中的法律不确定性。

关于 GPL
协议约束力范围(传染性),一审法院以涉案的三个插件可以独立运行,分别存放在三个独立的文件夹中且三个独立文件夹中无
GPL 许可证,据此认为涉案三个插件不属于 GPL
协议中所指应被开源的衍生产品或修改版本

GPL 许可证中有关的原文如下:

The “Program”, below, refers to any such program or work, and a “work
based on the Program” means either the Program or any derivative work
under copyright law: that is to say, a work containing the Program or
a portion of it, either verbatim or with modifications and/or
translated into another language. (Hereinafter, translation is
included without limitation in the term “modification”.)——GPL
3.0

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.

A “covered work” means either the unmodified Program or a work based
on the Program.——GPL
2.0

结合 GPL 协议条款和 GNU 官网对于 GPL
传染性的解释,一审法院这一认定是值得商榷的,就像你不能认为总部在西城的 A
公司与其在昌平拥有独立办公场所的分公司 B 是完全独立的,这需要从 A 和 B
之间的财务、人事、业务等是否独立为基础判断。

同理,GPL 模块 A 与模块 B
之间是否独立,绝对不能以A和B是否位于独立的文件夹中来判断,还是需要从 A
和 B 之间的功能关系、通信关系、调用关系、依赖关系等来判断。

插件相对于主程序是否独立,需要看:

  1. 插件的使命,是否为该主程序而存在;
  2. 插件与主程序的交互方式,如管道、队列、函数调用;
  3. 交换消息的密切性(intimate communication);
  4. 是否有例外声明等。

一审法院在确定赔偿额的时候又一次指出三个涉案插件是三个独立软件作品。一审法院从审判认定到赔偿衡量是一致的。这里,两柚子并没有就涉案三个插件的独立性进行抗辩,而这一点对
GPL 是否构成传染非常关键,在一审中被告代理律师对 GPL
许可证条款的理解也存在局限。

sun 炮轰GPL开源协议

关于二审认定的思考

首先,二审中两柚子再次提出司法鉴定来否定涉案三个插件独立性,可能是准备利用GPL传染性中关于独立作品的认定来抗辩。不过,法院认为二审诉讼中再次提出第三次鉴定申请,有违司法程序公正和司法程序效率,即二审法院基于程序公正的角度考量不予准许。同时,二审法院认为两柚子提出的新的司法鉴定申请内容与本案待证事实之间无直接关联性,这一点是值得商榷的,因为
GPL
中作品是否独立直接影响作品是否受GPL约束,进而直接影响本案关于侵权的认定。二审法院的否决理由,直接回避了可能对
GPL 传染性问题的讨论。

其次,二审法院认定数字天堂现有证据不足以证明涉案三个插件可以独立于
HBuilder
开发工具软件中的其他程序独立运行,但针对不独立的插件却没有进一步讨论这种不独立是否能够进行
GPL 开源抗辩。也就是说,一审法院基于作品的独立认定 GPL
抗辩无效,二审法院采取了一审对 GPL
抗辩的意见,但却否定了作品的独立性这一前提。

是否为独立作品的认定直接决定作品是否属于衍生作品(derivative
work)或修改作品(modified version),进而直接影响是否受 GPL 约束。

当然,我们可以这样解读二审法院对于作品独立的认定,即 GPL
许可证里所说的作品的独立性,和一审、二审法院判决赔偿额对插件独立的认定是不同维度/层次,这是说的通的。但仔细阅读一审判决可知,法院在否决
GPL 抗辩中和赔偿额判定中对独立的认定是一致的,二审认可了一审对 GPL
抗辩部分的认定,却否决了赔偿额中对独立作品的认定,本身前后有矛盾嫌疑

笔者认为,如果按照上述:GPL
传染性中独立性判定和对侵权作品数量中独立性判定是不同维度的独立性判定的假设,至少二审中需要重新认定
GPL 传染性的问题,从而将两个维度的独立性认定区分开来。

开源协议List

关于两柚子诉求理由的思考

两柚子在二审中再次申请司法鉴定:

  1. 涉案三个插件是否可以脱离 Eclipse 主体软件在 Windows 环境中独立运行;
  2. 将涉案三个插件源代码编译为插件以验证插件能否在 Eclipse
    主体软件中独立运行;
  3. 任意删除 Hbuilder
    软件目录下的一个或多个以“org.eclipse”、“org.apache”、“com.aptana”为前缀的文件或目录
    JAR 文件以验证涉案三个插件能否正常运行……

关于这三个补充鉴定事项,首先,笔者认为两柚子或者其律师在开源上做足了工作,但其中依然存在问题。首先,插件独立于
Eclipse 主程序,并不一定需要插件可以脱离 Eclipse 主程序在 Windows
中独立运行。插件的独立性在于:插件有明确的功能,可用于特定的主程序,但不依赖于特定的主程序。最后,主程序脱离插件,应当且必须可以独立运行,并且不损失主程序本身的所有功能。 

也详细查阅了一些关于 CPL1.0 的资料:
 Common Public License (CPL) Frequently asked quest
 Common Public License (CPL) Frequently asked
questions
 Common Public License Version
1.0
  What open source license is OpenLaszlo available
under?

再看诉讼本身

基于以上认识,我们再回头看看案件本身。首先说明,因本案需要进行多处技术鉴定,笔者无法也没有精力一一取证,仅仅基于几个假设,再捋一下
GPL 相关的问题。笔者认为,关于本案 GPL 传染性的认定需要从 3 个方面来看:

  1. Eclipse 主程本身;
  2. 基于 Eclipse 主程序的 GPL 插件;
  3. 涉案插件与主程序,以及涉案插件与上述 GPL 插件的关系。

为方便读者理解,引用数字天堂代理律所对一审结果评述的一张图。

www.9778.com 2 

算是对开源协议有了大概的了解。下面谈谈我对开源协议的一些粗浅的认识,如有不当之处,请大家指教。

(1)从 Eclipse 主程序看

APICloud 和 HBuilder 都是基于主程序 Eclipse
平台,包含第三方开源插件+各自自研插件组成的集成开发环境 IDE。

首先,主程序 Eclipse 是采用 EPL(Eclipse Public License)许可证公开,EPL
与 GPL 不兼容。即便是 2017 年 8
月发布的 EPL-2.0 版本虽然添加了次级许可证选项,但其与
GPL 依然是不兼容的。因此,HBuilder 作为下游产品,其对 Eclipse
的包装分发不能变更 Eclipse
许可证。

其次,针对插件来说,无非是拓展 Eclipse 某一特定的功能,任何非 Eclipse
本身的第三方插件,可以说对于 Eclipse
主程序来说都是非必须的。其第三方公司开发的 Eclipse 主程序的插件,按照
EPL 传染性的规定,一般不视为 EPL 的衍生作品,不受 EPL 约束。

最后,需要强调的是 EPL 虽然是弱 Copyleft 许可证,但其依然是类似于 GPL
的具有“传染性”的许可证,其在给予用户更大使用方便的同时,对自身软件的
Copyleft 保护依然很强。因此,下游软件开发者在处理 EPL 软件和 GPL
软件时,需要认真对待它们的兼容性问题。 

      首先,要对几个概念有所了解:
(1)Contributors 和 Recipients
      Contributors
指的是对某个开源软件或项目提供了代码(包括最初的或者修改过的)发布的人或者实体(团队、公司、组织等),Contributors
按照参与某个软件开源的时间先后,可以分为 an initial Contributor 和
subsequent Contributors 。
      Recipients指的是开源软件或项目的获取者,显然,subsequent
Contributors 也属于 Recipients之列。

(2)从 Aptana 插件看

Aptana 在 2006 年推出时,以 EPL 1.0 发布,并于 2017 年 9 月 21 日修改为
GPL3.0 和 APL(Aptana Public License )双许可。APL
不是开源/自由软件许可证,可以认为是商业许可,但对于非分发的内部使用是免费的。

Aptana 作为主程序 Eclipse 的插件,由于 EPL 和 GPL 不兼容,Aptana 中的
GPL 插件要和以 EPL 许可的 Eclipse 主程序连接,必须在 GPL
许可证里作例外声明。毫无疑问,笔者在 Aptana
官网找到了例外声明,即关于独立作品的 GPL 传染性例外声明,以及聚合程序的
GPL
传染性例外声明。部分内容如下:

GPL Section 7 Exception

……which are conveyed to you by Appcelerator, Inc. and licensed under
one or more of the licenses identified in the Excepted License List
below (each an “Excepted License”), as long as:

  1. you obey the GPL in all respects for the Program and the modified
    version, except for Excepted Works which are identifiable sections
    of the modified version, which are not derived from the Program,
    and which can reasonably be considered independent and separate
    works in themselves,
  2. all Excepted Works which are identifiable sections of the modified
    version, which are not derived from the Program, and which can
    reasonably be considered independent and separate works in
    themselves,
  3. are distributed subject to the Excepted License under which they
    were originally licensed, and
  4. are not themselves modified from the form in which they are
    conveyed to you by Appcelerator, and
  5. the object code or executable form of those sections are
    accompanied by the complete corresponding machine-readable source
    code for those sections, on the same medium as the corresponding
    object code or executable forms of those sections, and are
    licensed under the applicable Excepted License as the
    corresponding object code or executable forms of those sections,
    and
  6. any works which are aggregated with the Program, or with a
    modified version on a volume of a storage or distribution medium
    in accordance with the GPL, are aggregates (as defined in Section
    5 of the GPL) which can reasonably be considered independent and
    separate works in themselves and which are not modified versions
    of either the Program, a modified version, or an Excepted Work.

If the above conditions are not met, then the Program may only be
copied, modified, distributed or used under the terms and conditions
of the GPL or another valid licensing option from Appcelerator, Inc.
Terms used but not defined in the foregoing paragraph have the
meanings given in the GPL

从以上 GPL 例外中可以看出,Aptana
只是部分限定了“衍生作品”解释,也就是运行采用 GPL 许可证的 Aptana 与像
Eclipse 这样独立的程序交互不会发生传染,仅此而已。而如果修改
Aptana,将其他程序并入 Aptana Studio,或者将 Aptana
与其他程序进行整合的作品依然受到 GPL 协议约束。简单的说,加入 GPL 例外的
GPL 程序依然是 GPL 程序,这一点必须强调。关于这一点,Aptana
官网还专门有问题解答:

Can I add EPL’d plugins to Aptana Studio package and redistribute
it?

No. You can only redistribute the unmodified binary versions of the
EPL’d plugins that are part of Aptana Studio when distributing any of
the GPL’d code. Adding any files to Aptana Studio package creates a
derivative work, and since all derivative works need to be made GPL’d,
you will not be able to add EPL’d (or any other license) plugins
without contacting us for a commercial license.

What if I want to make changes to some of Aptana Studio’s EPL’d
plugins?

You are free to make changes to any of Aptana Studio EPL’d code under
the terms of the EPL. To get those redistributed as part of Aptana
Studio, we encourage you to contribute those back to Aptana so that we
may evaluate your changes for inclusion back into the product.

Can I take unmodified Aptana Studio binaries and combine them with
an Eclipse distribution?

No. Combining our GPL’d licensed code with any other product requires
that the entire product be GPL’d, and therefore you cannot include any
Eclipse distribution.

数字天堂认为,其 HBuilder 是包含 Eclipse
平台框架和众多插件的聚合体软件包,但其基于 Eclipse 开发且打包了 Aptana
中的 GPL 插件。从 GPL 协议对独立程序和聚合程序的规定来看,HBuilder
不被感染很难成立。一旦这种潜在传染可能性成立,数字天堂的 HBuilder
发行版就不满足合规性,其内部 EPL 和 GPL
软件不兼容。直白的说,就是整个发行版都可能受到 GPL 的约束。同时,这对于
Eclipse 是不可接受的,哪怕 EPL 是弱 Copyleft 许可证。这些问题,多是对
EPL 和 GPL 的 Copyleft 性质认识不到位导致。

(2)Source Code 和 Object Code

(3)涉案插件与主程序及 Aptana 插件的关系

其实,以上两步分析一旦得出受 GPL
约束的结论,就不需要下面的分析了。为了完整,同时供未来类似案例参考,简单介绍。

进一步分析 Aptana 与数字天堂的涉案三个插件之间的关系,若涉案三个插件与
Aptana 有调用、通信、依赖关系,那么涉案三个插件必然会被 GPL
传染,也即是受 GPL 约束。

从以上三步的分析可见,在 GPL
传染性判断时,是否为独立作品是非常关键的。
这也是我在前面法院判决部分要强调一审法院对独立的认定虽未必符合
GPL 本身解释,但至少前后一致。而二审法院对作品独立的认定甚至前后矛盾。

当然,笔者没太多精力去调查技术细节,点到为止,有兴趣的读者可以进行深入研究。

以上分析,是基于 Eclipse 作为中立主程序(即 Eclipse
主程序著作权人非诉讼参与人),GPL 插件与非 GPL
插件判定的情况,换一种场景以上判断完全或者大部分不成立。关于开源软件和
GPL
的问题还有很多需要注意的,限于篇幅不再进一步说明,对本案或对开源感兴趣的朋友可以找我单独讨论。

作者: Linux中国 付钦伟

转载自:Linux中国

        Source Code 指的是各种语言写成的源代码,通过Source
Code,结合文档,
可以了解到整个软件的体系结构及具体到某个功能函数的实现方法等。

        Object Code 指的是Source Code
经过编译之后,生成的类似于“类库”一样的,提供各种接口供他人使用的目标码,按我的理解,它就是像常见的DLL、AtiveX、OCX控件性质的东西。(不知道这样理解对不对www.9778.com 3

分清楚这两个概念的目的在于,有些开源,只发布Object Code
,当然,大多数发布的是Source Code。很多协议也对
“你发布的是哪种Code的时候应该怎样”,有着明确的约束。

(3)Derivative Module 和 Separate Module

       Derivative Module
指的是,依托或包含“最初的”或者“从别人处获取的”开源代码而产生的代码,是原“源代码”的增强(不等于增加)、改善和延续的模块,意为“衍生模块”。

         Separate Module
指的是,参考或借助原“源代码”,开发出的独立的,不包含、不依赖于原“源代码模块”,意为“独立的模块”。

理解这两个概念的目的在于,很多协议对涉及到商业发布的时候,会有哪些是衍生的,哪些是独立的,有着明确的商业发布规定。

     
接下来,说说常见的几种协议吧。其实上面我给出的几篇文章的链接里面对一些常见的开源协议已经有比较清晰的描述了,我这里也只是加人了个人的一些理解,希望对接触得少的人有一定的帮助吧。

GPL(Gun General Public
License) vesion 2.0 
1991

      最常见的开源协议,使用它作为授权协议的有大名鼎鼎的 Linux
。GPL最显著的两个特点就是网上称为的“病毒性传播”和“不允许闭源的商业发布”。

     
所谓的“病毒性传播”,指的是,GPL规定,所有从GPL协议授权的源码衍生出来的(即上面提到的Derivative
Module),或者要跟GPL授权的源码混着用的Project,都要遵循GPL协议,就像病毒一样,粘上了关系,就“中毒”了。GPL这样规定的目的是,保证
在GPL协议保护下的产品,不会再受到其他协议或者授权的约束。即让跟GPL有关系的源码都能免费获取。举个例子,如果你的改进的Linux中使用了GPL授权下的开源模块(也必须使用,你不可能自己重新去做个内核吧,如果做出来了,你也没必要叫Linux了。),那么你整个Linux产品也必须遵循GPL协议去开源,不能以其他方式去开源发布,更不允许闭源发布。这样一来,就不会出现这样一个Linux--这个功能是GPL协议授权的,可以免费获取源码,而另外一个功能是其他协议下的,拿不到源码。这点规定对使用或者研究该产品的人来说,是一个极大的便利。

     
而“不允许闭源商业发布”指的是,在GPL授权下,你的软件产品可以商业发布,拿去卖钱,但是在这同时,你也必须将该产品的源码以GPL协议方式开源发布出去,供他人免费获取。也许有人会迷惑,拿去卖,又同时开源,那谁来买阿?这个产品怎么赚钱呢??这就涉及到开源产品的商业模式的问题了,想了解相关一些信息的话,可以看看以上我给出链接的一些文章。至于后面,可能会写一篇关于开源项目的商业模式的随笔。

     GPL协议下的商业发布的一个关键点就像 Java 视线论坛的
Robbin所说的,GPL是针对软件源代码的版权,而不是针对软件编译后二进制版本的版权。你有权免费获得软件的源代码,但是你没有权力免费获得软件的二进制发行版本。GPL对软件发行版本唯一的限制就是:你的发行版本必须把完整的源代码一同提供。

BSD(Berkeley Software
Distribution )

    
跟GPL有很大的不同,BSD协议是给予人很大的自由的一种开源协议。其最大的特点是,Recipients
几乎可以对源码“为所欲为”,可以自由地修改,自由地使用,修改后再以其他方式再发布(商业或者开源)。但,你做这些事情的时候,还是得遵循以下规则:

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

     
其实这几个规则约定的目的也只是达到一个目的:是他人的东西,别人以BSD开源了,你就不能不做任何声明而占为己有,更不能用他人的名义来做商业推广。你只对你自己的东西拥有绝对控制权。

     
举个例子,你用开源代码(A)修改或做其他增添之后,产生了产品B,这时候,你对B的控制由你自己决定,你可以用任何协议再开源,也可以闭源商业发布。但,因为如果B中包含了A或A的一部分(一点都不包含就不叫修改了),那你在B产品的版权声明中,必须有提到你有使用到
A ,并且附带上 A 的开源协议。而且不能做商业推广的时候 将 B 冠以
原开源作者的名义以促进商业推广。

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

Apache Licence  vesion
2.0

Apache Licence 是著名的非盈利开源组织 Apache
采用的协议。该协议和BSD类似,同样鼓励代码共享和尊重原作者的著作权,同样允许代码修改,再发布(作为开源或商业软件)。需要满足的条件也和BSD类似:(配备英文原文,方便更准确理解)
1. 需要给 Recipients 一份Apache Licence

      (You must give any other recipients of the Work or Derivative
Works a copy of this License)
2. 如果你修改了代码,需要在被修改的文件中进行说明。

      (You must cause any modified files to carry prominent notices
stating that You changed the files)
3. 在Derivative
Module中(修改和包含源代码而衍生的代码)需要带有原来代码中的协议,商标,专利声明和其他原来作者规定需要包含的说明。

       (You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and attribution
notices from the Source form of the Work, excluding those notices that
do not pertain to any part of the Derivative Works)
4. 如果再发布的产品中包含一个Notice文件,则在Notice文件中需要带有Apache
Licence。你可以在Notice中增加自己的许可,但不可以表现为对Apache
Licence构成更改。

       (If the Work includes a “NOTICE” text file as part of its
distribution, then any Derivative Works that You distribute must include
a readable copy of the attribution notices contained within such NOTICE
file, excluding those notices that do not pertain to any part of the
Derivative Works, in at least one of the following places: within a
NOTICE text file distributed as part of the Derivative Works; within the
Source form or documentation, if provided along with the Derivative
Works; or, within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents of the
NOTICE file are for informational purposes only and do not modify the
License. You may add Your own attribution notices within Derivative
Works that You distribute, alongside or as an addendum to the NOTICE
text from the Work, provided that such additional attribution notices
cannot be construed as modifying the License.)

Apache
Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。

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

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

CPL(Common Public Liecense)www.9778.com,
vesion 1.0

      CPL 是 IBM 提出的并通过了OSI(Open Source
Initiative)批准的开源协议。主要用于一些 IBM 或跟 IBM
相关的开源软件/项目中。如 很著名的Java开发环境 Eclipse 、RIA开发平台Open
Laszlo等。

       CPL也是一项对商业应用友好的协议。它允许 Recipients
对源码进行任意的使用、复制、分发、传播、展示、修改以及改后做闭源的二次商业发布,这点跟
BSD 很类似,也属于自由度比较高的开源协议。但是,需要遵循:

       1.当一个Contributors 
将源码的整体或部分再次开源发布的时候,必须继续遵循 CPL
开源协议来发布,而不能改用其他协议发布。除非你得到了原“源码”Owner  的
授权。

          (Does the CPL allow me to take the Source Code for a
Program licensed under it and include all or part of it in another
program licensed under the GNU General Public License (GPL), Berkeley
Software Distribution (BSD) license or other Open Source license?

No. Only the owner of software can decide whether and how to license it
to others. Contributors to a Program licensed under the CPL understand
that source code for the Program will be made available under the terms
of the CPL. Unless you are the owner of the software or have received
permission from the owner, you are not authorized to apply the terms of
another license to the Program by including it in a program licensed
under another Open Source license. By the way, the same answer applies
if you want to include source code licensed under another Open Source
license in a program licensed under the CPL )

       2.CPL协议下,你可以将源码不做任何修改来商业发布。但如果你要将修改后的源码其开源,而且当你再发布的是Object
Code 的时候,你必须声明 它的Source Code 是可以获取的,而且要告知获取方法

       ( Can I take a Program licensed under the CPL, compile it
without modification, and commercially license the result?

Yes. You may compile a Program licensed under the CPL without
modification and commercially license the result in accordance with the
terms of the CPL. 

   Do I need to include the source code for such Program with the
object code distribution?

No. But you do need to include a statement that the source code is
available from you and information on how to obtain it.

 

What happens if I make a modification to the platform under the CPL
but choose not to distribute it to anyone else?

Under the CPL, in this circumstance you do not need to make the source
code available to others.

 

If I modify a Program licensed under the CPL and distribute the object
code of the modified Program for free, must I make the source code
available?

Yes. By distributing the modified Program, even if it is only a free
version of the object code, you are obligated to make the source code to
the modified Program available to others. )   

 

        3.当你需要将 CPL
下的源码作为一部分跟其他私有的源码混和着成为一个 Project
发布的时候,你可以将整个Project/Product
以私人的协议发布,但要声明哪一部分代码是CPL下的,而且声明那部分代码继续遵循CPL。

 

When I incorporate a portion of a Program licensed under the CPL
into my own proprietary product distributed in object code form, can I
use a single license for the full product, in other words, covering the
portion of the Program plus my own code?

Yes. The object code for the product may be distributed under a single
license as long as it references the CPL portion and complies, for that
portion, with the terms of the CPL.

       4.独立的模块(Separate Module),不需要开源

If I write a module to add to a Program licensed under the CPL and
distribute the object code of the module along with the rest of the
Program, must I make the source code to my module available in
accordance with the terms of the CPL?

No, as long as the module is not a derivative work of the Program.)

     
综上所述,看见我对开源的协议的了解也只是达到一个初步的认识。特别是对 CPL
还有着一些困惑。另外我自己一直也觉得 Derivative Module 和 Separate
Module
很难有个清晰的界限,在某种程度上总感觉他们有个模棱两可地段。但既然是有所心得,就先写下来吧。衷心欢迎大家指正、讨论。