开源许可协议

1 目的

为了让开发人员能够正确合法的使用开源软件，避免因为不小心而触犯到相关法律法规，产生不必要的法律纠纷，现对开源界的几大开原协议进行了翻译和整理。

2 开源许可协议定义

自由软件/开源软件是自由的，免费的，源代码开放的，我们可自由下载安装和使用。同时，为了维护作者和贡献者的合法权利，保证这些软件不被一些商业机构或个人窃取，影响软件的发展，开源社区开发出了各种的开源许可协议。其中主要分三大类。

OSI-Approved Open Source：被开放源码组织（www.opensource.org）所批准的开放源码授权协议。如常见的Apache，GPL，LGPL，MIT Licence，都属于OSI-Approved的授权协议，OSI 的要求之一是二进制文件和源代码的自由发放。

Other/Proprietary License：其他的，私有的授权协议。指软件作者提供源代码，但是对软件的分发和发布有其他的限制。

Public Domain：公共域授权。将软件授权为公共域，表示作者完全放弃版权，任何人都可以随意使用。

大部分开源工程都属于OSI-Approved Open Source，下面对常见的License做简单的介绍。

3 开源许可协议介绍

3.1 GNU GPL

GNU有两种协议其中一种为 General Public Licence (GPL) ，该协议有可能是开源界最常用的许可模式。GPL 保证了所有开发者的权利，同时为使用者提供了足够的复制，分发，修改的权利。主要条款如下：

使用者可以将软件自由的复制到任何地方。
使用者可以以任何方式自由的分发，下载。注意分发的时候需要提供源代码和二进制文件。
使用者可以盈利，基于 GPL 的软件允许商业化销售，但不允许封闭源代码。
如果使用者对遵循 GPL 的软件进行任何改动和/或再次开发并予以发布，则使用者的产品必须继承 GPL 协议，不允许封闭源代码。

GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。但对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。GPL3.0详见附录4.1GPL3.0协议。

3.2 GNU LGPL

GNU 还有另外一种协议，叫做LGPL（Lesser General Public Licence），它对产品所保留的权利比GPL少，总的来说，LGPL适合那些用于非GPL或非开源产品的开源类库或框架。因为GPL要求，使用了GPL代码的产品必须也使用GPL协议，开发者不允许将GPL代码用于商业产品。而LGPL绕过了这一限制。

基于LGPL的软件也允许商业化销售，但不允许封闭源代码。
如果您对遵循LGPL的软件进行任何改动和/或再次开发并予以发布，则您的产品必须继承LGPL协议，不允许封闭源代码。但是如果您的程序对遵循LGPL 的软件进行任何连接、调用而不是包含，则允许封闭源代码。

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

3.3 BSD

BSD授权许可证(FreeBSD Copyright Information)具有多种授权许可证。其中BSD 在软件分发方面的限制比别的开源协议（如GNU GPL）要少。该协议有多种版本，最主要的版本有两个，新BSD协议与简单BSD协议，这两种协议经过修正，都和 GPL 兼容，并为开源组织所认可。简单BSD协议主要条款如下：

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

新版（也称“三句版”）BSD许可证规定，只要软件的版权申明和许可证的免责条款得以保存，软件可以以任何目的不受限制地分发。该许可证还包含如下条款：即未经许可，不得以软件贡献者的名字为软件的衍生产品做代言。这一条款正是新版BSD许可证与简版BSD许可证之间的主要区别。

3.4 Apache license. 2.0

Apache Licence是著名的非盈利开源组织Apache采用的协议。Apache协议 2.0和别的开源协议相比，除了为用户提供版权许可之外，还有专利许可，对于那些涉及专利内容的开发者而言，该协议最适合。以下为Apache Licence的详细介绍：

需要授予使用代码的用户一份Apache Licence。一旦被授予许可，使用者可以无限期的使用。
如果使用者修改了代码，需要再被修改的文件中说明。
在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。

以下是该授权关于对工作中使用的说明和限制：

如果在工作中需要应用该授权，请附上如下样板式说明，以[]围起来，来替换你自己的说明信息。（不要包含括弧）文本通常被适当的文件语法格式所包围。我们也建议，一个文件或者类名和特定目的的描述，一起被包含在印刷页上，该印刷页作为一个简单的第三方文档授权证明。下为授权的文档格式。

dreamcamp by Francis Jiang is licensed under a Creative Commons 署名-非商业性使用-相同方式共享 3.0 Unported License. 基于github.com上的作品创作。 ## License (The MIT License) Copyright © 2009-2012 Francis Jiang Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the ‘Software’), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED ‘AS IS’, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. #### If you want to be awesome. - Proudly display the ‘Powered by Francis Jiang’ credit in the footer. - Add your site to the wiki so we can watch the communi

3.5 MIT许可协议（MIT License）

在所有常用的开源许可协议中，MIT许可协议最为简短，可能也最为广泛。它的条款非常松散，比起大部分其它许可协议来说更加宽松。其基本条款如下：

使用者可以随意使用，复制，修改这个软件。没有人能够阻止你在任何工程里使用它，你可以复制任意次数、以任何形式，或按你的愿望修改它。
使用者可以向外免费发放，或出售。你可以随意的分发它，没有任何限制。
唯一的限制是使用者必须接受协议条款。即软件必须附带版权和许可协议。
MIT 协议是目前最少限制的协议。它基本上就是任何人可以对这个协议下的软件的做任何的事情，只要你能认可这个协议。

3.6 知识共享协议

知识共享（Creative Commons，简称CC）许可协议并非完全的开源许可协议，但设计类项目也常常使用。有各种不同的CC许可协议可供使用，每种授予特定的权利。一个CC许可证包含四个基本部分，每部分即可单独生效，又可联合使用。简述如下：

署名,使用者必须按照作者指定的方式对作品进行署名。除此之外，作品可被复制、分发、拷贝以及以其它方式使用。
相同方式共享，即只能基于相同的CC许可证对作品进行修改、分发等。
非商业性，作品可被修改、分发等，但不得以商业为目的进行。关于什么构成商业行为，许可证条款并未提供清晰的定义，因此使用者可能需要在自己的项目里给予澄清。比如说，有人认为“非商业”只是简单地意味着你不能出售作品，也有人认为你不能把作品放到一个带广告的网站上，还有人认为只有当牟利发生时才能称为“商业”。
禁止衍生，即使用者可以拷贝和分发授权作品，但不得以任何方式修改、或基于原作进行创作。

如上所述，CC许可证的各个部分可以联合使用。最为严格的许可证为“署名-非商业-禁止衍生”许可证，即使用者可以自由分享作品，但不得修改或收费，同时必须按照作者指定的方式为作品署名。这对那些一方面希望发布作品，另一方面又希望多多少少保留对作品使用方式的控制权的作者来说，颇为不错。限制最少的CC许可证是“署名”许可证，即只要按照作者指定的方式为作品署名，就可以用作品做任何事。

CC许可证在设计类作品中的应用要比在开发中的应用多，但并没有限制你在开发中使用它，只是要清楚各部分条款的细节。

3.7 CPL(Common Public Liecense) vesion 1.0

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

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

当使用者将源码的整体或部分再次开源发布的时候，必须继续遵循CPL 开源协议来发布，而不能改用其他协议发布。除非你得到了原“源码”Owner 的授权。
CPL协议下，使用者可以将源码不做任何修改来商业发布。但如果要将修改后的源码开源，而且当你再发布的是ObjectCode 的时候，你必须声明它的Source Code是可以获取的，而且要告知获取方法。
当使用者需要将 CPL 下的源码作为一部分跟其他私有的源码混和着成为一个项目发布的时候，可以将整个项目/产品以私人的协议发布，但要声明哪一部分代码是CPL下的，而且声明那部分代码继续遵循CPL。独立的模块（Separate Module），不需要开源。

3.8 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允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以MPL许可证的形式对外许可外，源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些，就为借鉴别人的源代码用做自己商业软件开的行为留了一个豁口。
MPL许可证第三条第7款中允许使用者将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。
对软件专利的态度，MPL许可证不像GPL许可证那样明确表示反对软件专利，但是却明确要求源代码的提供者不能提供已经受专利保护的源代码（除非他本人是专利权人，并书面向公众免费许可这些源代码），也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。
MPL许可证第3条有专门的一款是关于对源代码修改进行描述的规定，就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述。

3.9 CDDL协议

CDDL全称Common Development and Distribution License.它是一个开源许可证书，采用著名的Mozilla公共许可证(MPL)，使其在未做任何改动的情况下可重用。CDDL满足 Open Source Definition 的要求并且已经获得开放源码促进会的认可作为开放源代码的许可证。

MPL作为CDDL的基础。除了保留所有所希望的MPL特性以外(参考前面)，CDDL许可证被设计成可重用的，并做了一些改进使其更加通用。
对于任何遵守CDDL许可的源文件，以及使用者所做的任何修改都需要共享。但是不必将私有源文件共享。
CDDL为在此许可下发布的代码提供了清楚的专利许可。这意味着使用者可以使用、修改并且重新发布CDDL授权的代码而不需要担心代码开发者(包括Sun)的任何技术专利。许可证同时包括了一项条款如果有任何人因为他们所提供的代码而对一个开发者进行专利起诉的话，该条款通过废除代码所有权来阻止任何对于开发者的专利指控。
可以修改，然后遵守CDDL许可将代码重新发布，并可以进行收费。但是，需要遵循CDDL的条款，包括遵守CDDL许可将修改的代码共享。

4 附录

4.1 GPL3.0协议

4.1.1 导言

GNU通用公共授权是一份针对软件和其他种类作品的自由的、公共的授权文件。

大多数软件授权申明被设计为剥夺您共享和修改软件的自由。相反地，GNU通用公共授权力图保护您分享和修改自由软件地自由——以确保软件对所有使用者都是自由的。我们，自由软件基金会，对我们的大多数软件使用GNU通用公共授权；本授权同样适用于任何其作者以这种方式发布的软件。您也可以让您的软件使用本授权。

当我们谈论自由软件时，我们指的是行为的自由，而非价格免费。GNU通用公共授权被设计为确保您拥有发布自由软件副本(以及为此收费，如果您希望的话)的自由,确保您能收到源代码或者在您需要时能获取源代码，确保您能修改软件或者将它的一部分用于新的自由软件，并且确保您知道您能做这些事情。

为了保护您的权利，我们需要做出要求，禁止任何人否认您的这些权利或者要求您放弃这些权利。因此，如果您发布此软件的副本或者修改它，您就需要肩负起尊重他人自由的责任。

例如，如果您发布自由软件的副本，无论以免费还是以收费的模式，您都必须把您获得的自由同样的给予副本的接收者。您必须确保他们也能收到或者得到源代码。而且您必须向他们展示这些条款，以使他们知道自己享有这样的权利。

使用GNU通用公共授权的开发者通过两项措施来保护您的权利：（1）声明软件的版权；（2）向您提供本授权文件以给您复制、发布并且/或者修改软件的法律许可。

为了保护软件开发者和作者，通用公共授权明确阐释自由软件没有任何担保责任。如用户和软件作者所希望的，通用公共授权要求软件被修改过的版本必须明确标示，从而避免它们的问题被错误地归咎于先前的版本。

某些设备被设计成拒绝用户安装或运行其内部软件的修改版本，尽管制造商可以安装和运行它们。这从根本上违背了通用公共授权保护用户能修改软件的自由的宗旨。此类滥用本授权的系统模式出现在了最让人无法接受的个人用户产品领域。因此，我们设计了这个版本的通用公共授权来禁止那些产品的侵权行为。如果此类问题在其他领域大量出现，我们准备好了在将来的通用公共授权版本里扩展这项规定，以保护用户的自由。

最后，每个程序都经常受到软件专利的威胁。政府不应该允许专利权限制通用计算机软件的发展和使用，但是在政府确实允许这种事情的地区，我们希望避免应用于自由软件的专利权使该软件有效私有化的危险。为了阻止这样的事情的发生，通用公共授权确保没有人能够使用专利权使得自由软件非自由化。

以下是复制，发布和修改软件的详细条款和条件。

4.1.2 条款和条件

4.1.2.1 定义

“本授权”指GNU通用公共授权第三版。

“版权”一词同样指适用于其他产品如半导体防护罩等的保护版权的法律。

“本程序”指任何在本授权下发布的受版权保护的作品。被授权人称为“您”。“被授权人”和“版权接受者”可以是个人或组织。

“修改”作品是指从软件中拷贝或者做出全部或一丁点儿的修改，这不同于逐字逐句的复制，是需要版权许可的。修改成果被称为先前作品的“修改版本”或者“基于”先前作品的软件。

“覆盖程序”指未被修改过的本程序或者基于本程序的程序。

“传播”程序指使用该程序做任何如果没有许可就会在适用的版权法下直接或间接侵权的事情，不包括在电脑上执行程序或者是做出您不与人共享的修改。传播包括复制，分发（无论修改与否），向公众共享，以及在某些国家的其他行为。

“发布”作品指任何让其他组织制作或者接受副本的传播行为。仅仅通过电脑网络和一个用户交流，且没有发送程序拷贝的行为不是发布。

一个显示“适当的法律通告”的交互的用户接口应包括这样一个方便而显著的可视部件，它具有以下功能：（1）显示一个合适的版权通告；（2）告诉用户对本程序没有任何担保责任（除非有担保明确告知），受权人可以在本授权下发布本程序，以及如果阅读本授权协议的副本。如果该接口显示了一个用户命令或选项列表，比如菜单，该列表中的选项需要符合上述规范。

4.1.2.2 源代码

“源代码”指修改程序常用的形式。“目标代码”指程序的任何非源代码形式。

“标准接口”有两种含义,一是由标准组织分支定义的官方标准；二是针对某种语言专门定义的众多接口中，在该类语言的开发者中广为使用的那种接口。

可执行程序的“系统库”不是指整个程序，而是指任何包含于主要部件但不属于该部件的部分，并且只是为了使能该部件而开发，或者为了实现某些已有公开源代码的标准接口。“主要部件”在这里指的是执行程序的特定操作系统（如果有的话）的主要的关键部件（内核，窗口系统等），或者生成该可执行程序时使用的编译器，或者运行该程序的目标代码解释器。

目标代码中的程序“对应的源代码”指所有生成，安装，（对可执行程序而言）运行该目标代码和修改该程序所需要的源代码，包括控制这些行为的脚本。但是，它不包括程序需要的系统库，通用目的的工具，以及程序在完成某些功能时不经修改地使用的那些不包括在程序中的普遍可用的自由软件。例如，对应的源代码包括与程序的源文件相关的接口定义文件，以及共享库中的源代码和该程序设计需要的通过如频繁的数据交互或者这些子程序和该程序其他部分之间的控制流等方式获得的动态链接子程序。

对应的源代码不需要包含任何拥护可以从这些资源的其他部分自动再生的资源。

源代码形式的程序对应的源代码定义同上。

4.1.2.3 基本的许可

所有在本授权协议下授予的权利都是对本程序的版权而言，并且只要所述的条件都满足了，这些授权是不能收回的。本授权明确的确认您可以不受任何限制地运行本程序的未修改版本。运行一个本授权覆盖的程序获得的结果只有在该结果的内容构成一个覆盖程序的时候才由本授权覆盖。本授权承认您正当使用或版权法规定的其它类似行为的权利。

只要您的授权仍然有效，您可以无条件地制作，运行和传播那些您不发布的覆盖程序。只要您遵守本授权中关于发布您不具有版权的资料的条款，您可以向别人发布覆盖程序，以要求他们为您做出专门的修改或者向您提供运行这些程序的简易设备。那些为您制作或运行覆盖程序的人作为您专门的代表也必须在您的指示和控制下做到这些，请禁止他们在他们和您的关系之外制作任何您拥有版权的程序的副本。当下述条件满足的时候，在任何其他情况下的发布都是允许的。转授许可证授权是不允许的，第10节让它变的没有必要了。

4.1.2.4 保护用户的合法权利不受反破解法侵犯

在任何实现1996年通过的世界知识产权组织版权条约第11章中所述任务的法律，或者是禁止或限制这种破解方法的类似法律下，覆盖程序都不会被认定为有效的技术手段的一部分。

当您发布一个覆盖程序时，您将放弃任何禁止技术手段破解的法律力量，甚至在本授权关于覆盖程序的条款下执行权利也能完成破解。同时，您放弃任何限制用户操作或修改该覆盖程序以执行您禁止技术手段破解的合法权利的企图。

4.1.2.5 发布完整副本

你可以通过任何媒介发布本程序源代码的未被修改过的完整副本，只要您显著而适当地在每个副本上发布一个合适的版权通告；保持完整所有叙述本授权和任何按照第7节加入的非许可的条款；保持完整所有的免责申明；并随程序给所有的接受者一份本授权。

您可以为您的副本收取任何价格的费用或者免费，你也可以提供技术支持或者责任担保来收取费用。

4.1.2.6 发布修改过的源码版本

您可以在第4节的条款下以源码形式发布一个基于本程序的软件，或者从本程序中制作该软件需要进行的修改，只要您同时满足所有以下条件：

制作的软件必须包含明确的通告说明您修改了它，并给出相应的修改日期。
制作的软件必须包含明确的通告，陈述它在本授权下发布并指出任何按照第7节加入的条件。这条要求修改了第4节的“保持所有通知完整”的要求。
您必须把整个软件作为一个整体向任何获取副本的人按照本授权协议授权。本授权因此会和任何按照第7节加入的条款一起，对整个软件及其所有部分，无论是以什么形式打包的，起法律效力。本授权不允许以其他任何形式授权该软件，但如果您个别地收到这样的许可，本授权并不否定该许可。
如果您制作的软件包含交互的用户接口，每个用户接口都必须显示适当的法律通告；但是，如果本程序包含没有显示适当的法律通告的交互接口，您的软件没有必要修改他们让他们显示。如果一个覆盖程序和其他本身不是该程序的扩展的程序的联合体，这样的联合的目的不是为了在某个存储或发布媒体上生成更大的程序，且联合体程序和相应产生的版权没有用来限制程序的使用或限制单个程序赋予的联合程序的用户的合法权利的时候，这样的联合体就被称为“聚集体”。在聚集体中包含覆盖程序并不会使本授权应用于该聚集体的其他部分。

4.1.2.7 发布非源码形式的副本

您可以在第4,5节条款下以目标代码形式发布程序，只要您同时以一下的一种方式在本授权条款下发布机器可读的对应的源代码：

在物理产品（包括一个物理的发布媒介）中或作为其一部分发布目标代码，并在通常用于软件交换的耐用的物理媒介中发布对应的源代码。
在物理产品（包括一个物理的发布媒介）中或作为其一部分发布目标代码，并附上有效期至少3年且与您为该产品模型提供配件或客户服务的时间等长的书面承诺，给予每个拥有该目标代码的人（1）要么在通常用于软件交换的耐用物理媒介中，以不高于您执行这种源码的发布行为所花费的合理费用的价格，一份该产品中所有由本授权覆盖的软件的对应的源代码的拷贝；（2）要么通过网络服务器免费提供这些对应源代码的访问。
单独地发布目标代码的副本，并附上一份提供对应源代码的书面承诺。这种行为只允许偶尔发生并不能盈利，且在您收到的目标代码附有第6节b规定的承诺的时候。
在指定的地点（免费或收费地）提供发布的目标代码的访问并在同样的地点以不增加价格的方式提供对应源代码的同样的访问权。您不需要要求接收者在复制目标代码的时候一道复制对应的源代码。如果复制目标代码的地点是网络服务器，对应的源代码可以在另外一个支持相同复制功能的服务器上（由您或者第三方运作），只要您在目标代码旁边明确指出在哪里可以找到对应的源代码。无论什么样的服务器提供这些对应的源代码，您都有义务保证它在任何有需求的时候都可用，从而满足本条规定。
用点对点传输发布目标代码，您需要告知其他的节点目标代码和对应的源代码在哪里按照第6节d的条款向大众免费提供。

目标代码中可分离的部分，其源代码作为系统库不包含在对应的源代码中，不需要包含在发布目标代码的行为中。

“用户产品”指（1）“消费品”，即通常用于个人的、家庭的或日常目的的有形个人财产；或者（2）任何为公司设计或销售却卖给了个人的东西。在判断一个产品是否消费品时，有疑点的案例将以有利于覆盖面的结果加以判断。对特定用户接收到的特定产品，“正常使用”指该类产品的典型的或通常的使用，无论该用户的特殊情况，或者该用户实际使用该产品的情况，或者该产品要求的使用方式如何。一个产品是否是消费品与该产品是否具有实质的经济上的、工业的或非消费品的用处无关，除非该用处是此类产品唯一的重要使用模式。

用户产品的“安装信息”指从对应源码的修改版本安装和运行该用户产品中包含的覆盖程序的修改版本所需要的任何方法、过程、授权密钥或其他信息。这些信息必须足以保证修改后的目标代码不会仅仅因为被修改过而不能继续运行。

如果您在本节条款下在用户产品中，或随同，或专门为了其中的使用，发布目标代码程序，而在发布过程中用户产品的所有权和使用权都永久地或在一定时期内（无论此项发布的特点如何）传递给了接收者，在本节所述的条款下发布的对应的源代码必须包含安装信息。但是如果您或者任何第三方组织都没有保留在用户产品上安装修改过的目标代码的能力（比如程序被安装在了ROM上），那么这项要求不会生效。

提供安装信息的要求并没有要求为接收者修改或安装过的程序，或者修改或安装该程序的用户产品，继续提供支持服务、担保或升级。当修改本身实际上相反地影响了网络的运行，或者违反了网络通信的规则和协议时，网络访问可以被拒绝。

根据本节发布的对应源代码和提供的安装信息必须以公共的文件格式发布（并附加一个该类型文档的实现方法以源码形式向公众共享），解压缩、阅读或复制这些信息不能要求任何密码。

4.1.2.8 附加条款

“附加许可”是通过允许一些本授权的特例来补充本授权的条款。只要它们在使用法律下合法，对整个程序都生效的附加许可就应当被认为是本授权的内容。如果附加许可只是对本程序的一部分生效，那么该部分可以在那些许可下独立使用，但整个程序是在本授权管理下，无论附加许可如何。

当您发布覆盖程序的副本时，您可以选择删除该副本或其部分的任何附加许可。（当您修改程序时，附加许可可能要求在某些情况下将自身删除）。您可以把附加许可放在材料上，加入到您拥有或能授予版权许可的覆盖程序中。

拒绝担保责任或以与本授权第15和16小节条款不同的方式限制责任；
要求保留特定的合理法律通告，或者该材料中或包含于适当法律通告中的该程序的作者贡献；
禁止误传该材料的来源，或者要求该材料的修改版本以合理的方式标志为与原版本不同的版本；
限制以宣传为目的的使用该材料作者或授权人的姓名；
降低授权级别以在商标法下使用一些商品名称，商标或服务标记；
要求任何发布该材料（或其修改版本）的人用对接收者的责任假设合同对授权人和材料作者进行保护，避免任何这样的假设合同直接造成授权人和作者的责任。

所有其他不许可的附加条款都被认为是第10节中的“进一步的约束”。如果您收到的程序或者其部分，声称自己由本授权管理，并补充了进一步约束，那么您可以删除这些约束。如果一个授权文件包含进一步约束，但是允许再次授权或者在本授权下发布，只要这样的进一步的约束在这样的再次授权或发布中无法保留下来，您就可以在覆盖程序中加入该授权文件条款管理下的材料。

如果您依据本小节向覆盖程序添加条款,您必须在相关的源码文件中加入一个应用于那些文件的附加条款的声明或者指明在哪里可以找到这些条款的通告。

附加的条款，无论是许可的还是非许可的条款，都可以写在一个单独的书面授权中，或者申明为例外情况；这两种方法都可以实现上述要求。

4.1.2.9 终止授权

您只有在本授权的明确授权下才能传播或修改覆盖程序。任何其它的传播或修改覆盖程序的尝试都是非法的，并将自动终止您在本授权下获取的权利（包括依据第11节第三段条款授予的任何专利授权）。

4.1.2.10 获取副本不需要接受本授权

您不需要为了接收或运行本程序的副本而接受本授权协议。仅仅是因为点对点传输获取副本引起传播行为，也不要求您接受本授权协议。然而，除了本授权外，任何授权协议都不能授予您传播或修改覆盖程序的许可。因此，如果您修改或者传播了本程序的副本，那么您就默认地接受了本授权。

4.1.2.11 下游接收者的自动授权

每次您发布覆盖程序，接收者都自动获得一份来自原授权人的依照本授权协议运行、修改和传播该程序的授权。依据本授权，您不为执行任何第三方组织的要求负责。

“实体事务”指转移一个组织的控制权或全部资产，或者拆分组织，或者合并组织的事务。如果覆盖程序的传播是实体事务造成的，该事务中每一个接收本程序副本的组织都将获取一份其前身拥有的或者能够依据前面的条款提供的任何授权，以及从其前身获取程序对应的源代码的权利，如果前身拥有或以合理的努力能够获取这些源代码的话。

您不可以对从本授权协议获取或确认的权利的执行强加任何约束。比如，您不可以要求授权费用，版税要求或对从本授权获取的权利的执行收取任何费用。您不可以发起诉讼（包括联合诉讼和反诉）声称由于制作、使用、销售、批发或者引进本程序或其任何一部分而侵犯了任何专利权。

4.1.2.12 专利权

一个贡献者的“实质的专利申明”是该贡献者所占有和控制的全部专利，无论已经获得的还是在将来获得的，那些可能受到某种方式侵犯的专利权。本授权允许制作、使用和销售其贡献者版本，但不包括那些只会由于对贡献者版本进一步的修改而受到侵犯的专利的申明。为此，“控制”一词包括以同本授权要求一致的方式给予从属授权的权利。

每个贡献者在该贡献者的实质的专利申明下授予您非独家的，全世界的，不需要版税的专利授权，允许您制作、使用、销售、批发、进口以及运行、修改和传播其贡献者版本内容。

在以下三个自然段中，“专利授权”指任何形式表达的不执行专利权的协议或承诺（例如使用专利权的口头许可，或者不为侵犯专利而起诉的契约）。向一个组织授予专利授权指做出这样的不向该组织提出强制执行专利权的承诺。

如果您在自己明确知道的情况下发布基于某个专利授权的覆盖程序，而这个程序的对应的源代码并不能在本授权条款下通过网络服务器或其他有效途径免费地向公众提供访问，您必须做到：（1）使对应的源代码按照上述方法可访问；或者（2）放弃从该程序的专利授权获取任何利益；或者（3）以某种与本授权要求一致的方法使该专利授权延伸到下游的接收者。“在自己明确知道的情况下”指您明确地知道除了获取专利授权外，在某个国家您传播覆盖程序的行为，或者接收者使用覆盖程序的行为，会由于该专利授权而侵犯一个或多个在该国可确认的专利权，而这些专利权您有足够的理由相信它们是有效的。

在依照或者涉及某一次事务或安排时，如果您通过获取发布或传播覆盖程序的传输版本，并给予接收该覆盖程序的某些组织专利授权，允许他们使用，传播，修改或者发布该覆盖程序的特殊版本，那么您赋予这些组织的专利授权将自动延伸到所有该覆盖程序及基于该程序的作品的接收者。

一份专利授权是“有偏见的”，如果它没有在自身所覆盖的范围内包含，禁止行使，或者要求不执行一个或多个本授权下明确认可的权利。以下情况，您不可以发布一个覆盖程序：如果您与软件发布行业的第三方组织有协议，而该协议要求您根据该程序的发布情况向该组织付费，同时该组织在你们的协议中赋予任何从您那里获得覆盖软件的组织一份有偏见的专利授权，要么（a）连同您所发布的副本（或者从这些副本制作的副本）；要么（b）主要为了并连同某个的产品或者包含该覆盖程序的联合体。如果您签署该协议或获得该专利授权的日期早于2007年3月28日，那么您不受本条款约束。

本授权的任何部分不会被解释为拒绝或者限制任何暗含的授权或其他在适用专利权法下保护您的专利不受侵犯的措施。

4.1.2.13 不要放弃别人的自由

如果您遇到了与本授权向矛盾的情况（无论是法庭判决，合同或者其他情况），它们不能使您免去本授权的要求。如果您不能同时按照本授权中的义务和其他相关义务来发布覆盖程序，那么您将不能发布它们。比如，如果您接受了要求您向从您这里或许本程序的人收取版税的条款，您唯一能够同时满足本授权和那些条款的方法是完全不要发布本程序。

4.1.2.14 和GNU Affero通用公共授权一起使用

尽管本协议有其他防备条款，您有权把任何覆盖程序和基于第三版GNU Affero通用公共授权的程序链接起来，并且发布该联合程序。本授权的条款仍然对您的覆盖程序有效，但是GNU Affero通用公共授权第13节关于通过网络交互的要求会对整个联合体有效。

4.1.2.15 本授权的修订版

自由软件基金会有时候可能会发布GNU通用软件授权的修订版本和/或新版本。这样的新版本将会和现行版本保持精神上的一致性，但是可能会在细节上有所不同，以处理新的问题和情况。

每个版本都有一个单独的版本号。如果本程序指出了应用于本程序的一个特定的GNU通用公共授权版本号“以及后续版本”，您将拥有选择该版本或任何由自由软件基金会发布的后续版本中的条款和条件的权利。如果本程序没有指定特定的GNU通用公共授权版本号，那么您可以选择任何自由软件基金会已发布的版本。

如果本程序指出某个代理可以决定将来的GNU通用公共授权是否可以应用于本程序，那么该代理的接受任何版本的公开称述都是您选择该版本应用于本程序的永久认可。

4.1.2.16 免责申明

4.1.2.17 责任范围

4.1.2.18 第15和16节的解释

如果上述免责申明和责任范围不能按照地方法律条款获得法律效力，复审法庭应该采用最接近于完全放弃关于本程序的民事责任的法律，除非随同本程序的责任担保或责任假设合同是收费的。

4.1.3 如何在您的新程序中应用这些条款？

如果您开发了一个新程序，并且希望能够让它尽可能地被大众使用，达成此目的的最好方式就是让它成为自由软件。任何人都能够依据这些条款对该软件再次发布和修改。

为了做到这一点，请将以下声明附加到程序上。最安全的作法，是将声明放在每份源码文件的起始处，以有效传达无担保责任的讯息；且每份文件至少应有「版权」列以及本份声明全文位置的提示。

<用一行描述程序的名称与其用途简述>

本程序为自由软件；您可依据自由软件基金会所发表的GNU通用公共授权条款，对本程序再次发布和/或修改；无论您依据的是本授权的第三版，或（您可选的）任一日后发行的版本。

本程序是基于使用目的而加以发布，然而不负任何担保责任；亦无对适售性或特定目的适用性所为的默示性担保。详情请参照GNU通用公共授权。

您应已收到附随于本程序的GNU通用公共授权的副本；如果没有，请参照<http://www.gnu.org/licenses/>.同时附上如何以电子及书面信件与您联系的资料。

如果程序进行终端交互方式运作，请在交互式模式开始时，输出以下提示：

本程序不负任何担保责任，欲知详情请键入’show w’。

这是一个自由软件，欢迎您在特定条件下再发布本程序；欲知详情请键入’show c’。

所假设的指令’show w’与’show c’应显示通用公共授权的相对应条款。当然，您可以使用’show w’与’show c’以外的指令名称；对于图形用户界面，您可以用“关于”项代实现此功能。

如有需要，您还应该取得您的雇主（若您的工作为程序设计師）或学校就本程序所签署的“版权放弃承诺书”。欲知这方面的详情，以及如何应用和遵守GNU通用公共授权，请参考<http://www.gnu.org/licenses/>

GNU通用公共授权并不允许您将本程序合并到私有的程序中。若您的程序是一个子程序库，您可能认为允许私有的应用程序链接该库会更有用。如果这是您所想做的，请使用GNU松弛通用公共授权代替本授权。但这样做之前，请阅读<http://www.gnu.org/philosophy/why-not-lgpl.html>

4.2 LGPL 2.1协议

4.2.1 导言

大多数软体许可证决意剥夺您共享和修改软体的自由。相反的，GNU 通用公共许可证力图保证您共享和修改自由软体的自由 —— 保证自由软体对所有使用者都是自由的。

这个许可证，较宽松公共许可证，适用于一些由自由软体基金会与其他决定使用此许可证的软体作者，所特殊设计的软体套件 —— 象是函数库。您也可以使用它，但我们建议您事先仔细考虑，基于以下的说明是否此许可证或原来的通用公共许可证在任何特殊情况下均为较好的方案。

当我们谈到自由软体时，我们所指的是自由，而不是价格。我们的 GNU 通用公共许可证是设计用以确保使您有发布自由软体备份的自由（如果您愿意，您可以对此项服务收取一定的费用）；确保您能收到程式原始码或者在您需要时能得到它；确保您能修改软体或将它的一部分用于新的自由软体；而且还确保您知道您可以做上述的这些事情。

为了保护您的权利，我们需要作出限制：禁止任何人否认您上述的权利，或者要求您放弃这些权利。如果您发布软件的副本，或者对之加以修改，这些规定就转化为您的责任。

例如，如果您发布此函数库的副本，不管是免费还是收取费用，您必须将您享有的一切权利给予接受者；您必须确保他们也能收到或得到原始程式码；如果您将此函数库与其他的程式码连结，您必须提供完整的目的对象文件和程序(object file)给接受者，则当他们修改此函数库并重新编译过后，可以重新与目的档连结。您并且要将这些条款给他们看，使他们知道他们有这样的权利。

我们采取两项措施来保护您的权利: （1）用版权来保护函数库。并且，（2）我们提供您这份许可证，赋予您复制，发布和（或）修改这些函数库的法律许可。

为了保护每个发布者，我们需要非常清楚地让每个人明白，自由函数库是没有担保责任的。如果由于某人修改了函数库，并继续加以传播，我们需要它的接受者明白：他们所得到的并不是原始的版本。故由其他人引入的任何问题，对原作者的声誉将不会有任何的影响。

最后，由于软体专利不断地威胁自由软体的存在，我们希望商业公司无法藉由自专利持有者取得一个受限的许可证，而有效地限制自由软体的使用者。因此，我们坚持一个函数库所能取得的任何专利，必须与本许可证所声明的“完全自由使用”一致。

大部分的 GNU 软体，包括一些函数库，是受到原来的 GNU 通用公共许可证的保护。本许可证， GNU 较宽松通用公共许可证，适用于特殊设计的函数库，且与原来的通用公共许可证有很大的不同。我们在特定的函数库中使用它，以准许非自由的程式可以与这些函数库连结。当一个程式与一个函数库连结，不论是静态连结或使用共享函数库，二者的结合可以合理地说是结合的作品，一个原来的函数库的衍生品。因此，原来的通用公共许可证只有在整个结合品满足其自由的标准时，才予许连结。较宽松通用公共许可证则以更宽松的标准允许其他程式码与本函数库连结。

我们称此许可证 “较宽松” 通用公共许可证，是因为它比起原来的通用公共许可证对使用者的自由做到较少的保护。在与非自由软体竞争时，它也提供其他自由软体的写作者较少的优势。这些不利之处正是我们使用原来的通用公共许可证于许多函数库的理由。然而，较宽松的许可证可在某些特殊场合下带来好处。例如，在少数情况下，可能会有特殊的需要而鼓励大家尽可能广泛地使用特定的函数库，因而使它成为实际上的标准。为了达到此目标，必须允许非自由的程式使用此函数库。一个较常发生的情况是一个自由的函数库与一个被广泛使用的非自由函数库做相同的工作，在此情况下，限制只有自由软体可以使用此自由函数库不会有多少好处，故我们如用了较宽松通用公共许可证。

在其他情况下，允许非自由程式使用特定的函数库，可以让更多的人们使用自由软体的大部分。例如，允许非自由程式使用 GNU C 函数库可以让更多的人们使用整个 GNU 作业系统，以及它的变形，GNU/Linux 作业系统。

尽管较宽松通用共公许可证对使用者的自由是较少的保护的，它却能确保与此函数库连结的程式的使用者拥有自由，而且具有使用修改过的函数库版本来执行该程式的必要方法。

以下是复制、发布、以及修改的精确条款与条件。请注意 “基于函数库的作品” 以及 “使用函数库的作品” 之间的差异：前者包含来自函数库修改过的原始码；而后者则必须与函数库结合才能执行。

4.2.2 条款和条件

4.2.2.1 定义

一个 “函数库” 意指一些软体函数的集合，以及或准备好的资料以方便与应用程式 (其使用了其中某些函数与资料) 连结形成可执行的程式。以下，”函数库” 一词指的是任何在本条款下发布的这一类软体函数库或作品，个 “基于本函数库的作品” 意指函数库或任何在版权法下的衍生作品：也就是说，一个包含了本函数库或其一部分的作品，可以是原封不动的，或经过修改的，和/或直接翻译成其他语言的。 (在下文中，翻译是不受限地包含在 “修改” 的条款中。)
作品的 “原始码” 意指对作品进行修改最优先择取的形式。对函数库而言，完整的原始码意指所有模组的所有原始程式，加上有关的介面的定义，加上控制函数库的安装和编译的 script。
本许可证条款不适用于复制，发布和修改以外的活动。这些活动超出这些条款的范围。使用本函数库来执行本程式的动作不受条款的限制，而程式的输出只有在其内容所构成的作品是基于本函数库时 (与在什么样的工具中使用本函数库来输出无关) ，这一条款才适用。以上是否为真则取决于本函数库具体用来做什么。
只要您在每一程式副本上明显和恰当地宣告版权声明和不承担担保的声明，并保持此许可证的声明和没有担保的声明完整无损，并和程式一起给其他每位程式接受者一份许可证的副本，您就可以用任何媒体复制和发布您收到的函数库的完整原始码。您可以为转让副本的实际行动收取一定费用。您也可以选择提供担保以换取一定的费用。
只要您同时满足下面的所有条件，您就可以按前面第一款的要求修改函数库的一个或几个副本或它的任何部分，以此形成基于此函数库的作品，并且复制和发布这一经过修改的程式或作品:

4.2.2.2 条款

1) 被修改的作品本身必须是一个软体函数库。

2) 您必须在修改过的档案中附有明确的说明：

3) 您修改了此一档案及任何修改的日期。您必须让整个作品允许第三方在此许可证条款下可以免费使用。

4) 如果修改过的函数库其某个设备使用到了「使用本函数库的应用程式」所提供的函数或资料表格，却不是当此设备被呼叫时以参数列传入时，则您必须确实做到，当应用程式不提供这样的函数或表格时，则此设备依旧能工作，且其执行的任何目的仍然有意义。

5) (例如，一个函数库的函数用来计算平方根，其目的是有完整的定义且与应用程式是无关的。因此， 2d 小节要求任何本函数会使用的，由应用程式所提供的函数或表格必须是选择性的：如果应用程式不提供的话，则计算平方根的函数必须依旧能计算平方根)

这些要求适用于整个修改过的作品。如果能够确定作品的一部分并非本函数库的衍生产品，且可以合理地单独考虑并将它与原作品分开的话，则当您将它作为独立的作品发布时，它不受此许可证和其条款的约束。但是当您将这部分与基于本函数库的作品一同发布时，则整个套件将受到本许可证条款约束，其对于其他许可证持有人的使用范围扩大到整个产品，也就是套件的每个部分，不管它是谁写的。

因此，本条款的意图不在于索取权利，或剥夺完全由您完成的作品的权利，而是履行权利来控制基于本函数库的集体作品或衍生作品的发布。此外，将与本函数库无关的作品和本函数库 (或基于本函数库的作品) 一起放在贮存媒体或发布媒体的同一卷上，并不导致将其他作品置于此许可证的约束范围之内。

对于一个函数库的副本，您可以选择性地使用原来的 GNU 通用公共许可证上的条款来取代本许可证上的条款。如果您要这么做，您必须修改所有的参考到本许可证的注意事项，使它们指向原来的 GNU 通用公共许可证，第二版，以取代本许可证(如果有比第二版的原来的 GNU 通用公共许可证更新的版本出现的话，则如果您愿意的话可以特别指明使用新版)。请不要对这些注意事项做出其他的改变。一旦在一个副本上做了这样的改变，则该副本就无法撤回这样的改变，故原来的 GNU 通用公共许可证将适用于所有后续的副本以及由此副本衍生出来的作品。此一选择性适用于当您想要将一部分的函数库原始码复制到一个非函数库的程式使用时。
您可以以目标码或可执行形式复制或发布本函数库 (或符合第 2 款，基于本函数库的作品)，只要您遵守前面的第 1、2 款，并同时提供完整的相关机器可读的原始码，而这些原始码必须在前面的第 1 与第 2 款条件下，在一般习惯上用来做软体交换的媒体上发布。如果所发布的目标码是由指定的地点提供拷贝索取，那么由同一地点所提供等价的原始码拷贝索取可以算作原始码的发布，即使第三方不强求与目标码一起复制原始码。
一个程式若包含不经任何部分修改的函数库，但却是设计经由编译或连结的方式与本函数库一同工作者，称之为 “使用函数库的作品”。这样的一个作品，严格地说，并非本函数库的衍生作品，因而不在本许可证的范围之内。然而，将 “使用函数库的作品” 与本函数库连结而产生可执行程式，则是本函数库的衍生品 (因为它包函了本函数库的一部分)，而不是 “使用函数库的作品”，因此其可执行程式包含在本许可证的范围内。第 7 款说明了发布此可执行程式的条款。

当 “使用函数库的作品” 使用了函数库部分的标头档内容时，则此作品即使其原始码不属于本函数库的衍生品，但其目标码仍然是。这一点是否为真特别在是否本作品可以在不需要本函数库即可连结，或者是否该作品本身也是一个函数库时特别明显。

如果这样的目标档只使用数字参数、资料结构层级与附属品、以及小巨集和小内□式 (小于或等于十行) ，则此目标档的使用是不受限的，不论是否它是合法的衍生作品。 (但可执行程式若包函此目标档以及一部分的函数库，仍然将在第 7款的规定下)

否则的话，如果本作品是本函数库的衍生品，您必须在第 6 款的规定下发布该作品的目标码。任何包含该作品的可执行程式也在第 6 款的范围内，不论它们是否直接与本函数库连结。

做为上述条款的例外情况，您也可以将 “使用函数库的作品” 与本函数库结合或连结，以产生包含部分本函数库的作品，并在允许使用者自身使用时可以修改该作品，以及在对修改进行反组译除错的情况下，您可以依照您的选择发布该作品。

必须将完整的机器可读的函数库原始码包含在该作品中，包括任何该作品使用到的改变 (这些改变必须在前述第 1 与第 2 款的要求下发布)；而且，如果该作品是一个与函数库连结的「完整的、机器可□的 “使用函数库的作品”」，则要有目标码和/或原始码，如此使用者可以修改本函数库且可以重新连结，以产生包函修改过的函数库的修改过的可执行程式。 (理所当然的若使用者修改了函数库的档案定义内容时，则该作品不必然可以重新编译以使用修改过的定义。)

在与函数库连结时使用适当的分享函数库连结机制。一个适当的机制是： (1) 在执行时使用已存在于使用者的电脑中的函数库副本，而不是将函数库的函数复制到可执行程式里，以及 (2) 如果使用者安装了一份修改过的函数库，只要修改过的版本在介面上与该作品在编译连结时所用的版本是相容的，则该执行程式可以与修改过的函数库运作良好。

在该作品内提供书面报价，有效期不少于三年，以提供同样的使用者上述第 7a 款中的内容，费用不得超过该程式发布的实际成本。如果所发布的作品是由指定的地点提供拷贝索取，则由同一地点提供上述内容的等价拷贝索取。

确定使用者已经收到该作品的一份复制，或是您已经寄给该使用者一份复制品。

对于一个可执行程式，其所需的 “使用函数库的作品” 的形式必须包括任何要从中再产生可执行程式时所需的资料与工具程式。然而，有一个特殊例外，其所发布的内容不需要包括任何一般与「可执行本程式的作业系统」的主要部分 (如编译器、核心等) 一起发布的部分 (不论是原始码或可执行码)，除非这些组成部分和可执行作品结合在一起。

有一个可能情况是，这些要求与其他通常不与作业系统在一起的私有函数库的版权限制相抵触，这样的抵触表示您不能将它们与本函数库一起用于您发布的可执行程式中。

您可以将使用本函数库的函数库设备，以及其他不在本许可证范围内的函数库，对等地放入一个单独的函数库中，并在基于本函数库的作品以及其他函数库在其他状态下同意可以个别发布，以及您做到以下两点的情况下，您可以发布此结合的函数库：将基于本函数库的作品单独不与其他函数库设备结合地，与此结合的函数库一同发布。该作品必须在上述条款的规定下发布。在此结合的函数库中明显地指出其中一部分的作品是基于本函数库，并且说明那里可以找到同样不具结合形式的作品。
除非您明确按许可证提出的要求去做，否则您不能复制、修改、转发许可证、与本函数库连结、和发布本函数库。任何试图用其他方式复制、修改、转发许可证、与本函数库连结、和发布本函数库是无效的，而且将自动结束许可证赋予您的权利。然而，对那些从您那里按许可证条款得到副本和权利的人们，只要他们继续全面履行条款，许可证赋予他们的权利仍然有效。
您没有在许可证上签字，因而您没有必要一定接受此一许可证。然而，没有任何其他东西赋予您修改和发布本函数库及其衍生作品的权利。如果您不接受许可证，这些行为是法律禁止的。因此，如果您修改或发布函数库 (或任何基于函数库的作品) ，您就表明您接受这一许可证以及它的所有有关复制、发布和修改本函数库或基于它的作品的条款和条件。
每当您重新发布函数库 (或任何基于函数库的作品) 时，接受者自动从原始许可证颁发者那里接到受这些条款和条件支配的复制、发布、连结或修改本函数库的许可。您不可以强迫接受者履行除了这里赋予他们的权利之外的其他限制。您也没有强求第三方履行许可证条款的义务。
如果由于法院判决或违反专利的指控或任何其他原因 (不限于专利问题) 的结果，使得强加于您的条件 (不管是法院判决，协议书或其他) 和许可证的条件有冲突时，他们也不能令您背离许可证的条款。在您不能同时满足本许可证规定的义务及其他相关的义务来发布函数库时，则结果您只能够根本不发布函数库。例如，如果某一专利许可证不允许所有直接或间接从您那里接受副本的人们，在不付专利费的情况下重新发布函数库，唯一能同时满足两方面要求的办法是停止发布函数库。

如果本条款的任何部分在特定的环境下无效或无法实施，就使用条款的其余部分，并将这部分条款作为整体用于其他环境。本条款的目的不在于引诱您侵犯专利或其他财产权的要求，或争论这种要求的有效性。本条款的主要目的在于保护自由软体发布系统的完整性。它是通过公共许可证的应用来实现的。许多人已依赖同是出自此系统的应用程式，经由此系统发布大量自由软体而做出慷慨的供献。作者/捐献者有权决定他/她是否通过任何其他系统发布软体，许可证持有人不能强加这种选择。

本节的目的在于明确说明许可证其余部分可能产生的结果。

如果由于专利或者由于有版权的介面问题使函数库在某些国家的发布和使用受到限制，则在许可证约束下的原始版权拥有者可以增加发布地区的限制条款，将这些国家明确排除在外，并在这些国家以外的地区发布函数库。在这种情况下，许可证套件含的限制条款和许可证正文一样有效。 13. 自由软体基金会可能随时出版较宽松通用公共许可证的修改版或新版。新版和当前的版本在原则上保持一致，但在提到新问题时或有关事项时，在细节上可能出现差别。

每一版本都有不同的版本号。如果函数库指定可适用的许可证版本号以及 “任何更新的版本” ，您有权选择遵循指定的版本或自由软体基金会以后出版的新版本。如果函数库未指定许可证版本，您可选择自由软体基金会已经出版的任何版本。

如果您愿意将函数库的一部分结合到其他自由程式中，而它们的发布条件不同，请写信给作者，要求准予使用。如果是自由软体基金会加以版权保护的软体，写信给自由软体基金会，我们有时会作为例外的情况处理。我们的决定受两个主要目标的指导，这两个主要目标是：我们的自由软体的衍生作品继续保持自由状态，以及从整体上促进软体的共享和重复利用。
没有担保