开源软件软件著作权执照详细研究和实例分析

前言：LGPL大约是开源库商用绕不开的一条，如何使用LGPL,要实现LGPL的开源软件，作为开发者，使用者和商用者我们需要做哪些工作，需要注意哪些问题呢，文章希望通过实例来说明这些问题。

1 开源许可证GPL、BSD、MIT、Mozilla、Apache和LGPL的区别图例：

1.1 BSD开源协议（original BSD license、FreeBSD license、Original BSD license）

BSD开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”,可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。但”为所欲为”的前提当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：
a 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
b 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
c 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
BSD 代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。

1.2 Apache Licence 2.0（Apache License, Version 2.0、Apache License, Version 1.1、Apache License, Version 1.0）

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

1.3 GPL（GNU General Public License）

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

1.4  LGPL的定义：

The GNU Lesser General Public License (LGPL) is a free software license published by the Free Software Foundation (FSF). The license allows developers and companies to use and integrate software released under the LGPL into their own (even proprietary) software without being required by the terms of a strong copyleft license to release the source code of their own components. The license only requires software under the LGPL be modifiable by end users via source code availability. For proprietary（私有） software, code under the LGPL is usually used in the form of a shared library such as a DLL, so that there is a clear separation（清晰的分界） between the proprietary and LGPL components. The LGPL is primarily used for software libraries, although it is also used by some stand-alone （独立）applications.

The LGPL was developed as a compromise between the strong copyleft of the GNU General Public License (GPL) and more permissive licenses such as the BSD licenses and the MIT License. The word "Lesser" in the title（ GNU Lesser General Public License (LGPL)） shows that the LGPL does not guarantee the end user's complete freedom in the use of software; it only guarantees the freedom of modification for components licensed under the LGPL, but not for any proprietary components.

1.5 LGPL的中文简介

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

读书笔记：采用LGPL的代码，一般情况下它本身就是一个第三方库（别忘了LGPL最早的名字就是Library GPL），这时候开发人员仅仅用到了它的功能，而没有对库本身进行任何修改，那么开发人员也不必公布自己的商业源代码。但是如果你修改了这个库的代码，那么对不起，你修改的代码必须全部开源，并且协议也是LGPL，但除了库源码之外的商业代码，仍不必公布。我是这样理解的，呵呵。以前一直以为LGPL就是商业用的时候要购买，个人用就不必购买，原来搞错了。

1.6 MIT

MIT是和BSD一样宽范的许可协议,作者只想保留版权,而无任何其他了限制.也就是说,你必须在你的发行版里包含原许可协议的声明,无论你是以二进制发布的还是以源代码发布的.

1.7 MPL

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.8 CDDL 

CDDL，是MPL（Mozilla Public License）的扩展协议。
CDDL（Common Development and Distribution License，通用开发与发行许可）开源协议，是MPL（Mozilla Public License）的扩展协议，它允许公共版权使用，无专利费，并提供专利保护，可集成于商业软件中，允许自行发布许可。CDDL 的产生CDDL协议由Sun创造, 基于MPL（Mozilla Public License）协议1.1版本(MPL)。基于CDDL许可的软件：
目前，Sun公司将正在开发中的Solaris 11的源代码以CDDL许可开放，这一开放版本就是OpenSolaris。

1.9 EULA

最终用户许可协议（End User Licence Agreement，EULA），指的是一家公司的软件与软件的使用者所达成的协议，此协议一般出现在软件安装时。如果使用者拒绝接受这家公司的EULA，那么便不能安装此软件。最终用户许可协议是软件应用程序作者或者发布者与应用程序使用者之间的合法合同。最终用户许可协议（EULA），通常是指“软件许可”，它与租赁协议类似；用户同意支付软件的使用费用，并且向软件作者或者发行者承诺遵守EULA中规定的所有约束条件。用户被告知，当他们打开软件包的包装、打开CD盒的封条、将卡片寄回给软件发行者、安装应用程序、执行下载文件或者简单的使用应用程序的时候就意味着他们已经“接受”了EULA中的条款。用户可以寄回软件产品或者在安装过程中当EULA提示接受按钮的时候点击“我不接受”来拒绝这个协议。[1] 
一般情况下EULA最少有2000字，而且软件安装的时候，显示EULA的方框并不是很大，所以绝大多数人都是直接接受EULA的。

实例：

本文给出了一些指导性的意见和建议，用于帮助用户在产品开发中遵循自由软件的许可证条款，并避免出现违反自由软件许可证的情况发生。
1．如果您不接受 GPL/LGPL 许可证，请勿使用任何遵循该许可证条款发布的软件。如果您在自己的产品中使用了 GPL/LGPL 软件，则说明您已经接受了 GPL/LGPL 许可证中定义的所有条款，并有义务向产品的最终用户提供源代码——无论该源代码是否经过您的修改。如果经过了您自己的修改，则必须公开“衍生作品”的源代码，并以相同的许可证条款发布。

2．当您从 GPL/LGPL 软件中拿出 10 行以上的源代码用于自己的作品中时，则您的作品将成为该 GPL/LGPL 软件的衍生作品，无论您的作品的整体代码规模有多大。因此，如果您不打算将自己的作品作为自由软件发布，则应该远离自由软件代码，以免因为受到自由软件代码的影响而编写出和这些软件相类似的代码。

3．如果在您的作品中使用了 GPL/LGPL 软件，但没有对这些软件做任何修改，则可以在产品手册或者其他类似的文档中、程序界面上或者帮助信息中指明您使用的自由软件名称、版权拥有者以及能够获取该自由软件全部源代码的公共网站或第三方。如果因为某种原因，最终用户无法从您提到的第三方或者公共网站上获得该自由软件的源代码，您应该担负提供源代码的责任和义务。

4．GPL/LGPL 条款赋予您修改作品的权利，经修改之后的作品称为“衍生作品”。当您的衍生作品以某种方式发布时（典型情况就是用于您的产品中），您必须依照 GPL/LGPL 许可证发布您的衍生作品。当然，一种更加可取的办法是，将自己所做的修改提交给原始作品的维护者，并由该维护者负责发布，而您在产品中始终使用由维护者发布的作品。

5．自由软件不等于免费。提供自由软件的人可以要求您支付一定的费用，该费用通常有两层含义：第一，自由软件以某种介质发行时，该介质的制作、发布等费用；第二，当您希望获得对某自由软件的技术支持、缺陷修正等服务，要求某个人或组织提供相应的产品质量担保时，该组织或个人可以要求您就质量担保收取服务费用，甚至是专有软件产品惯用的使用许可费用。这里提到的组织或个人是任何遵循上述自由软件许可证条款发布自由软件、并向您提供质量担保的组织或个人，并不限于自由软件作品的作者或主要的版权拥有人。

6．对 LGPL 条款的自由软件（通常是函数库）的“正常使用”，通常的理解是，始终以动态链接的形式链接这个函数库——如果以静态的方式链接，将使该函数库成为您作品的一部分，从而使之成为该函数库的衍生作品。但实质上，LGPL 许可证的宗旨和精神是禁止将自由软件成为专用和独享的软件，而至少应该确保其他软件也能通过某种途径使用这个函数库的接口。当然，静态链接显然违背了上述精神和宗旨，从而是不允许将私有作品和 LGPL 函数库静态链接在一起。但如果您的产品没有提供任何扩展功能，而只能由您自己的私有作品使用其中包含的某 LGPL 函数库，这无异于将该函数库静态链接到您自己的私有作品中。因此，我们认为这种情况下，您的作品是该函数库的“衍生作品”——无论您的作品通过静态链接还是通过动态链接的方式链接该 LGPL 函数库。

上述这种情况经常会出现在嵌入式系统中。在这种情况下，您可以有如下选择：

 * 以动态链接方式链接 LGPL 函数库，并为您的产品提供扩展接口及程序上载接口，
    以便用户或者其他人能够对该产品进行扩展。

 * 最简单的方式：将衍生作品置于 LGPL 条款下发布。

 * 和 LGPL 条款的版权拥有人联系，看看是否能够以其他许可证方式授权您
    在自己的产品中使用该函数库，而不必遵循 LGPL 条款使自己的作品成为
    衍生作品。许多自由软件为商业用户提供另外一种可选的许可方式。

 * 当然，如果您觉得麻烦，可以选择不使用任何自由软件。

7．具体到由北京飞漫软件技术有限公司（简称“飞漫软件”）拥有版权并负责维护的 MiniGUI 和 MDE，请注意如下问题：

 * 如果您的产品符合第 6 条中提到的嵌入式产品，即 MiniGUI 成为您产品的
    专有和独享软件组件时，但您又不想使自己的软件作品成为 MiniGUI 的衍生
    作品，则您一定要主动联系飞漫软件以取得合法授权。

 * 如果您需要对 MiniGUI 进行修改以满足您的硬件环境（典型情况是为自己的
    硬件产品编写 MiniGUI 图形和/或输入引擎），您必须在产品发布时，一同
    发布修改后的 MiniGUI 源代码。一种可选的方式是，将修改后的代码提交给
    飞漫软件，由飞漫软件负责发布，而您始终使用由飞漫发布的 MiniGUI。

 * 请勿在自己的产品中随意使用 MDE 中的源代码。当您使用 MDE 中的源代码
    超过 10 行时，您的作品将成为 MDE 的衍生作品，也就是说，您的作品应该
    以 GPL 许可证方式发布。如果您的确想使用 MDE 中的某段代码，请主动和
    飞漫软件取得联系以取得合法授权。

Ref：

1 GNU_Lesser_General_Public_License

https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License

2 GNU Lesser General Public License （英文版）

http://www.gnu.org/copyleft/lesser.html

3 GNU 较宽松公共许可证 (简体中文翻译版)

http://www.thebigfly.com/gnu/lgpl/

4 软件授权协议：LGPL

http://www.leadbbs.com/a/a.asp?B=230&ID=2445884&ac=nxt&rd=877769

5 

http://www.cnblogs.com/findumars/p/3556883.html

6 开源许可证GPL、BSD、MIT、Mozilla、Apache和LGPL的区别

http://blog.csdn.net/woshihaiyong168/article/details/53026210?locationNum=13&fps=1

7 重要开源协议的比较(BSD,Apache,GPL,LGPL,MIT) – 整理

http://blog.csdn.net/epeaktop/article/details/53432618?locationNum=14&fps=1