精华内容
下载资源
问答
  • GPL协议,LGPL协议,MPL协议

    万次阅读 2019-05-07 19:52:34
    GPL协议,LGPL协议,MPL协议GPL协议LGPLMPL GPL协议 强开源约束授权1 GPL(GNU General Public License) 我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。 GPL...

    GPL协议

    强开源约束授权
    GPL(GNU General Public License)1

    我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。

    GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代码做为闭源的商业软件发布和销售

    这也就是为什么我们能用免费的各种linux,包括商业公司的linux和linux上各种各样的由个人,组织,以及商业软件公司开发的免费软件了。

    GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用,修改后的代码或者衍生代码)GPL 协议的产品,则该软件产品必须也采用GPL协议,既必须也是开源和免费

    这就是所谓的”传染性”。

    GPL协议的产品作为一个单独的产品使用没有任何问题,还可以享受免费的优势。

    由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议,对于使用GPL协议的开源代码,商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。

    其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。

    LGPL

    LGPL(GNU Lesser General Public License)1

    LGPL是GPL的一个为主要为类库使用设计的开源协议。

    和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同

    LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。

    这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。

    但是如果修改LGPL协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议

    因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用,但不适合希望以LGPL协议代码为基础,通过修改和衍生的方式做二次开发的商业软件采用。

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

    MPL

    弱开源约束授权
    MPL License(Mozilla Public License)1

    允许免费重发布、免费修改,但要求修改后的代码版权归软件的发起者。

    这种授权维护了商业软件的利益,,它要求基于这种软件的修改无偿贡献版权给该软件。

    这样,围绕该软件的所有代码得版权都集中在发起开发人得手中。

    但MPL是允许修改,无偿使用的。

    MPL软件对链接没有要求。(要求假如你修改了一个基于MPL协议的源代码,则必须列入或公开你所做的修改,假如其他源代码不是基于MPL则不需要公开其源代码)
    在这里插入图片描述

    参考链接

    各种开源协议:https://wenku.baidu.com/view/70df4f7402768e9951e738dc.html
    https://my.oschina.net/wxf/blog/63339
    http://www.gnu.org/licenses/
    http://www.thebigfly.com/gnu/gpl/
    https://www.cnblogs.com/pengdai/p/9227404.html

    如果使用Qt来开发商业软件,是否需要付费?:https://blog.csdn.net/zheng_zhiwei/article/details/23394061

    GPL 与 LGPL 扫盲:
    http://www.cnblogs.com/findumars/p/3496807.html

    下载各种开源协议:https://www.gnu.org/licenses/gpl-3.0.txt
    如何选择协议:https://www.jianshu.com/p/fabcf532ecd6

    协议疑问

    关于这个问题,先要对开源协议有个基本了解
    QT开源版有GPL与LGPL协议
    如果使用QT的开源版,就要遵守开源协议
    关于LGPL与GPL想了解更多的话,看下面的连接。下面我会将其中重点写出来。
    http://www.cnblogs.com/findumars/p/3496807.html

    其中,GPL协议是严格的
    简单说,GPL软件的使用者有权力得到软件的代码,只要使用了GPL,在发布(redistribution)的时候,整个项目也必须是GPL的,即主程 序和静态链接的库(Linux的.a和Windows的.lib)必须是GPL的,动态链接库(Linux的.so,Windows的.dll)必须是比 GPL兼容的。所谓GPL兼容,也就是GPL软件中可以使用的库,这些许可证必须比GPL弱(如LGPL,BSD),而不能是某个商业许可证。这里有一个 兼容列表 List of FSF approved software licenses。正因如此,GPL是带有很强的传染性,只要你的软件使用了GPL的代码,那么就请以GPL开放源代码吧,并且你的项目中也不能有任何和GPL不兼容的库。

    只要你的软件使用了GPL的代码,那么就请以GPL开放源代码吧。
    梳理一下:
    如果你遵守QT的GPL开源协议,使用了开源的QT库,那么你的软件也应该开源。没法商用。

    如果你想用QT的开源版库,还想让使用了QT开源版库的软件闭源,商用。
    那么你需要了解一下QT的LGPL。
    想了解更多的话,下面这个博客。
    http://www.cnblogs.com/findumars/p/5553490.html

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

    使用 LGPL 协议开发闭源程序,如果你使用动态链接的形式,那么,你可以以任何形式发布你的应用程序,商业的、非商业的、开源的、非开源的,随你。

    也就是说

    闭源商业软件可以免费使用LGPL的开源版Qt。

    关于发布:
    http://bbs.csdn.net/topics/350224093 ←看这个帖子的42L-45L

    GPL 是 GNU General Public License (GNU 通用公共许可证)的缩写形式;LGPL 是 GNU Lesser General Public License (GNU 宽通用公共许可证)的缩写形式,旧称 GNU Library General Public License (GNU 库通用公共许可证);GFDL 是 GNU Free Documentation License (GNU 自由文档许可证)的缩写形式。它们是自由软件(Free Software)的通用版权认证协议,由自由软件基金会(FSF)制定和发布。

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

    大概就是这样了,根据我查的各种资料来看,应该就是以上结论

    如何选择协议?

    例如Qt的QNetworkRequest类头文件遵循三种协议,如果你依赖的软件包来自不同的协议你可以在头文件中都标注出来:
    在这里插入图片描述

    展开全文
  • 详细介绍 LGPL 协议

    千次阅读 2019-09-13 02:05:55
    它不是自由软体基金会所发布,并且不能适用于使用 GNU LGPL 的软体 —— 只有GNU LGPL 英文原文的版本才行。然而,我们希望这份翻译能帮助中文的使用者更了解 GNU LGPL。 GNU 较宽松公共许可证 1999.2,...

    这是一份 GNU 较宽松公共许可证非正式的中文翻译。它不是自由软体基金会所发布,并且不能适用于使用 GNU LGPL 的软体 —— 只有 GNU LGPL 英文原文的版本才行。然而,我们希望这份翻译能帮助中文的使用者更了解 GNU LGPL。

    GNU 较宽松公共许可证

    1999.2, 第 2.1 版

    版权所有 (C) 1991, 1999 Free Software Foundation, Inc.
    59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

    允许每个人复制和发布本授权文件的完整副本,
    但不允许对它进行任何修改。

    [这是第一次发表的较宽松公共许可证 (Lesser GPL) 版本。它同时也可视为 GNU 函数库公共许可证 (GNU Library Public License) 第 2 版的后继者,故称为 2.1 版]

    本版本由 Leo-Hong (leohca (at) yahoo.com) 翻译整理, Chao-Hong Liu 校正.


    导言


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

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

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

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

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

    我们采取两项措施来保护您的权利: (1)用版权来保护函数库。并且,(2)我们提供您这份许可证,赋予您复制,发布和(或)修改这些函数库的法律许可。
    为了保护每个发布者,我们需要非常清楚地让每个人明白,自由函数库是没有担保责任的。如果由于某人修改了函数库,并继续加以传播,我们需要它的接受者明白:他们所得到的并不是原始的版本。故由其他人引入的任何问题,对原作者的声誉将不会有任何的影响。

    最后,由于软体专利不断地威胁自由软体的存在,我们希望商业公司无法藉由自专利持有者取得一个受限的许可证,而有效地限制自由软体的使用者。因此,我们坚持一个函数库所能取得的任何专利,必须与本许可证所声明的“完全自由使用”一致。
    <20040222> 
    大部分的 GNU 软体,包括一些函数库,是受到原来的 GNU 通用公共许可证的保护。本许可证, GNU 较宽松通用公共许可证,适用于特殊设计的函数库,且与原来的通用公共许可证有很大的不同。我们在特定的函数库中使用它,以准许非自由的程式可以与这些函数 库连结。 当一个程式与一个函数库连结,不论是静态连结或使用共享函数库,二者的结合可以合理地说是结合的作品,一个原来的函数库的衍生品。因此,原来的通用公共许 可证只有在整个结合品满足其自由的标准时,才予许连结。较宽松通用公共许可证则以更宽松的标准允许其他程式码与本函数库连结。

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

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

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

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


    有关复制,发布和修改的条款和条件


    0. 本许可证适用于任何软体函数库,或其他包含了由版权所有者加入的注意事项的程式,或其他有公信力的团体宣称其程式可以在较宽松通用公共许可证 (也称之为 "本许可证") 的条款下发布。每一位许可证接受者以 "您" 来称呼。

    一个 "函数库" 意指一些软体函数的集合,以及或准备好的资料以方便与应用程式 (其使用了其中某些函数与资料) 连结形成可执行的程式。

    以下,"函数库" 一词指的是任何在本条款下发布的这一类软体函数库或作品,一个 "基于本函数库的作品" 意指函数库或任何在版权法下的衍生作品:也就是说,一个包含了本函数库或其一部分的作品,可以是原封不动的,或经过修改的,和/或直接翻译成其他语言 的。(在下文中,翻译是不受限地包含在 "修改" 的条款中。)

    作品的 "原始码" 意指对作品进行修改最优先择取的形式。对函数库而言,完整的原始码意指所有模组的所有原始程式,加上有关的介面的定义,加上控制函数库的安装和编译的 script。

    本许可证条款不适用于复制,发布和修改以外的活动。这些活动超出这些条款的范围。使用本函数库来执行本程式的动作不受条款的限制,而程式的输出只有在其内容所构成的作品是基于本函数库时 (与在什么样的工具中使用本函数库来输出无关) ,这一条款才适用。以上是否为真则取决于本函数库具体用来做什么。

    1. 只要您在每一程式副本上明显和恰当地宣告版权声明和不承担担保的声明,并保持此许可证的声明和没有担保的声明完整无损,并和程式一起给其他每位程式接受者一份许可证的副本,您就可以用任何媒体复制和发布您收到的函数库的完整原始码。

    您可以为转让副本的实际行动收取一定费用。您也可以选择提供担保以换取一定的费用。

    2. 只要您同时满足下面的所有条件,您就可以按前面第一款的要求修改函数库的一个或几个副本或它的任何部分,以此形成基于此函数库的作品,并且复制和发布这一经过修改的程式或作品:


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

    您必须在修改过的档案中附有明确的说明:您修改了此一档案及任何修改的日期。

    您必须让整个作品允许第三方在此许可证条款下可以免费使用。

    如果修改过的函数库其某个设备使用到了「使用本函数库的应用程式」所提供的函数或资料表格,却不是当此设备被呼叫时以参数列传入时,则您必须确实做到,当应用程式不提供这样的函数或表格时,则此设备依旧能工作,且其执行的任何目的仍然有意义。
    (例如,一个函数库的函数用来计算平方根,其目的是有完整的定义且与应用程式是无关的。因此, 2d 小节要求任何本函数会使用的,由应用程式所提供的函数或表格必须是选择性的:如果应用程式不提供的话,则计算平方根的函数必须依旧能计算平方根)

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

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

    3. 对于一个函数库的副本,您可以选择性地使用原来的 GNU 通用公共许可证上的条款来取代本许可证上的条款。如果您要这么做,您必须修改所有的参考到本许可证的注意事项,使它们指向原来的 GNU 通用公共许可证,第二版,以取代本许可证(如果有比第二版的原来的 GNU 通用公共许可证更新的版本出现的话,则如果您愿意的话可以特别指明使用新版)。请不要对这些注意事项做出其他的改变。

    一旦在一个副本上做了这样的改变,则该副本就无法撤回这样的改变,故原来的 GNU 通用公共许可证将适用于所有后续的副本以及由此副本衍生出来的作品。

    此一选择性适用于当您想要将一部分的函数库原始码复制到一个非函数库的程式使用时。

    4. 您可以以目标码或可执行形式复制或发布本函数库 (或符合第 2 款,基于本函数库的作品),只要您遵守前面的第 1、2 款,并同时提供完整的相关机器可读的原始码,而这些原始码必须在前面的第 1 与第 2 款条件下,在一般习惯上用来做软体交换的媒体上发布。

    如果所发布的目标码是由指定的地点提供拷贝索取,那么由同一地点所提供等价的原始码拷贝索取可以算作原始码的发布,即使第三方不强求与目标码一起复制原始码。

    5. 一个程式若包含不经任何部分修改的函数库,但却是设计经由编译或连结的方式与本函数库一同工作者,称之为 "使用函数库的作品"。这样的一个作品,严格地说,并非本函数库的衍生作品,因而不在本许可证的范围之内。

    然而,将 "使用函数库的作品" 与本函数库连结而产生可执行程式,则是本函数库的衍生品 (因为它包函了本函数库的一部分),而不是 "使用函数库的作品",因此其可执行程式包含在本许可证的范围内。第 6 款说明了发布此可执行程式的条款。

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

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

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

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

    您必须在每个作品的副本突显出如下的注意事项:本函数库在作品中被使用,以及本函数库以及它的使用是在本许可证的规定下。您必须提供本许可证的副本。如果 该作品在执行时显示版权声明,您必须在其中包含本函数库的版权声明,以及指引使用者取得本许可证的副本。同时,您必须做到以下其中一件事: 


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

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

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

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

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

    7. 您可以将使用本函数库的函数库设备,以及其他不在本许可证范围内的函数库,对等地放入一个单独的函数库中,并在基于本函数库的作品以及其他函数库在其他状态下同意可以个别发布,以及您做到以下两点的情况下,您可以发布此结合的函数库:


    将基于本函数库的作品单独不与其他函数库设备结合地,与此结合的函数库一同发布。该作品必须在上述条款的规定下发布。

    在此结合的函数库中明显地指出其中一部分的作品是基于本函数库,并且说明那里可以找到同样不具结合形式的作品。 
    8. 除非您明确按许可证提出的要求去做,否则您不能复制、修改、转发许可证、与本函数库连结、和发布本函数库。任何试图用其他方式复制、修改、转发许可证、与 本函数库连结、和发布本函数库是无效的,而且将自动结束许可证赋予您的权利。然而,对那些从您那里按许可证条款得到副本和权利的人们,只要他们继续全面履 行条款,许可证赋予他们的权利仍然有效。

    9. 您没有在许可证上签字,因而您没有必要一定接受此一许可证。然而,没有任何其他东西赋予您修改和发布本函数库及其衍生作品的权利。如果您不接受许可证,这些行为是法律禁止的。因此,如果您修改或发布函数库 (或任何基于函数库的作品) ,您就表明您接受这一许可证以及它的所有有关复制、发布和修改本函数库或基于它的作品的条款和条件。

    10. 每当您重新发布函数库 (或任何基于函数库的作品) 时,接受者自动从原始许可证颁发者那里接到受这些条款和条件支配的复制、发布、连结或修改本函数库的许可。您不可以强迫接受者履行除了这里赋予他们的权利之外的其他限制。您也没有强求第三方履行许可证条款的义务。

    11. 如果由于法院判决或违反专利的指控或任何其他原因 (不限于专利问题) 的结果,使得强加于您的条件 (不管是法院判决,协议书或其他) 和许可证的条件有冲突时,他们也不能令您背离许可证的条款。在您不能同时满足本许可证规定的义务及其他相关的义务来发布函数库时,则结果您只能够根本不发 布函数库。例如,如果某一专利许可证不允许所有直接或间接从您那里接受副本的人们,在不付专利费的情况下重新发布函数库,唯一能同时满足两方面要求的办法 是停止发布函数库。

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

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

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

    每一版本都有不同的版本号。如果函数库指定可适用的许可证版本号以及 "任何更新的版本" ,您有权选择遵循指定的版本或自由软体基金会以后出版的新版本。如果函数库未指定许可证版本,您可选择自由软体基金会已经出版的任何版本。 14. 如果您愿意将函数库的一部分结合到其他自由程式中,而它们的发布条件不同,请写信给作者,要求准予使用。如果是自由软体基金会加以版权保护的软体,写信给 自由软体基金会,我们有时会作为例外的情况处理。我们的决定受两个主要目标的指导,这两个主要目标是:我们的自由软体的衍生作品继续保持自由状态,以及从 整体上促进软体的共享和重复利用。

    没有担保
    15. 由于函数库准予免费使用,在适用法准许的范围内,对函数库没有担保。除非另有书面说明,版权所有者和/或其他提供函数库的人们 "一样" 不提供任何类型的担保,不论是明确的,还是隐含的,包括但不限于可销售和适合特定用途的隐含保证。全部的风险,如函数库的质量和性能问题都由您来承担。如果函数库出现缺陷,您应当承担所有必要的服务、修复和改正的费用。

    16. 除非适用法或书面协议的要求,在任何情况下,任何版权所有者或任何按许可证条款修改和发布函数库的人们都不对您的损失负有任何责任。包括由于使用或不能使用函数库引起的任何一般的、特殊的、偶然发生的或重大的损失 (包括但不限于数据的损失,或者数据变得不精确,或者您或第三方的持续的损失,或者函数库不能和其他软体协调运行等) 。即使版权所有者和其他人提到这种损失的可能性也不例外。

    如何将这些条款用到您新的函数库


    如果您开发了新函数库,而且您需要它得到公众最大限度的利用,要做到这一点的最好办法是将它变为自由软体,使得每个人都能在遵守本条款 (或者是在原来的通用公共许可证的条款) 的基础上对它进行修改和重新发布。

    为了做到这一点,请将函数库附上下列声明。最安全的方式是将它放在每个原始码档案的开头,以便最有效地传递拒绝担保的信息。每个文件至少应有 "版权所有" 行以及在什么地方能看到声明全文的说明。

    用一行空间描述函数库的名称和它的用途简单说明
    版权所有 (C) 19XX 作者姓名
    这一函数库是自由软体,您可以遵照自由软体基金会出版的 GNU 较宽松通用公共许可证条款来修改和重新发布这一程式,或者用许可证的第二版,或者 (根据您的选择) 用任何更新的版本。

    发布这一函数库的目的是希望它有用,但没有任何担保。甚至没有适合特定目的而隐含的担保。更详细的情况请参阅 GNU 较宽松通用公共许可证。

    您应该已经和函数库一起收到一份 GNU 较宽松通用公共许可证的副本。如果还没有,写信给:

    Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

    此外还应加上如何藉由电子邮件或一般信件与您保持联系的信息。 
    如果需要,您应该取得您的上司 (如果您是程式员) 或您的学校签署放弃函数库版权的声明。下面只是一个例子,您应该改变相应的名称:

    Yoyodyne 公司以此方式放弃 James Random Hacker 所写的 `Frob' 函数库 (用以扭转 knobs 的函数库) 的全部版权利益。
    Ty coon 签名,1990.4.1
    Ty coon 副总裁

    转载于:https://my.oschina.net/gal/blog/200214

    展开全文
  • qt的LGPL协议开发商业软件

    千次阅读 2017-04-01 11:32:20
    查过很多资料了,将商业软件与Qt LGPL的关系归结如下: 1. 必须使用Qt的LGPL许可版本; ...2. Qt的库必须是动态...3. Qt的库最好不与产品同时发布[QT官方建议Qt软件从Qt官方网站下载Qt库,否则会违反为GLPL协议]。

    现转载http://blog.csdn.net/ojoe/article/details/6283082的文章

    查过很多资料了,将商业软件与Qt LGPL的关系归结如下:

    1. 必须使用Qt的LGPL许可版本;

    2. Qt的库必须是动态链接,否则会有不必要的麻烦;

    3. Qt的库最好不与产品同时发布[QT官方建议Qt软件从Qt官方网站下载Qt库,否则会违反为GLPL协议]。

        但你会发现Qt提供的下载地址很难打得开。个人觉得这一条基本可以忽略,仅需遵循第2条即可;或者你可以用2张光盘,一张用来发布,另一张用来提供Qt的共享库。

     

    下面是转载的别人的3篇文章,在此感谢他们的知识共享精神。

    文章1:

    QT的LGPL与闭源程序【转载】
    发表于135 天前  ⁄ C/C++  ⁄ 暂无评论

    最近一直在学习 Qt。Qt 有两个许可证:LGPL 和商业协议。这两个协议在现在的 Qt 版本中的代码是完全一致的(潜在含义是,Qt 的早期版本,商业版的 Qt 通常包含有一些开源版本所没有的库,比如 QtSingleApplication 这个库)。所以现在对于普通开发人员和部分商业公司来说,使用 LGPL 版本的 Qt 可以节省很大的开销。这两个版本最大的区别在于,前者是免费的,后者是收费的。既然代码都是一致的,所以费用就要是用来购买 Qt 的售后服务和培训等等相关服务。

    现在我们是来说一下版权的问题。LGPL 是一个开源协议,因此,有人会担心 LGPL 能否用于开发闭源程序,能够拿来卖钱。尽管现在国内有些公司不是很重视这方面的问题,不过,如果你违反了协议,某一天被别人发来一纸律师函的时候,真的是欲哭无泪了哦。所以,我们还是先来研究一下这个协议,LGPL 究竟能不能用于开发闭源程序。

    以下内容是我查找了 N 多网站总结出来的,因为豆子不是律师,所以 LGPL 协议基本看不懂。究竟怎样去理解这个协议,还是希望能够有专业人士说出来。这里就算做是一种抛砖引玉吧!尽管没有十分的确定,但是这里所说的理解基本也是八九不离十的了。

    至于什么是 LGPL 协议,这里就不再多说了,我们关心的是,如果使用 LGPL 协议开发商业程序。请注意,这里所说的闭源程序,是指不以某种形式开放源代码,也就是说,用户(包括其他开发者)不能获取其源代码的程序。首先说明一点,LGPL协议是一个商业友好的协议。这里的含义是,你可以用 LGPL协议开发商业程序,当然也可以是非商业的闭源程序。但是,它是有一些限制的。这就是我们要讨论的重点。

    既然我们已经对其定性,那么我们直接进入主题:使用 LGPL 协议开发闭源程序,如果你使用动态链接的形式,那么,你可以以任何形式发布你的应用程序,商业的、非商业的、开源的、非开源的,随你。

    如果你因某种原因必须静态链接一个基于 LGPL 协议发布的库(一下我们简称为 LGPL 库),那么,你有义务进行下面的工作:

    1. 你必须在你的文档中说明,你的程序中使用了 LGPL 库,并且说明这个库是基于 LGPL 发布的;
    2. 你必须在你的应用程序发布中包含一份 LGPL协议,通常就是那个文本文件;
    3. 你必须开放使用了 LGPL 库代码的所有代码,例如某些封装器。但是,其他使用这些封装器的代码就不需要开放了;
    4. 你必须包含你的应用程序的余下部分的目标文件(通常就是我们所说的 .o 等等),或者是其他等价的文件。源代码并不是必须的。

    是不是很难理解呢?我们详细的说一下。

    第一条很容易理解;第二条也很容易理解,你可以在这里找到 LGPL 协议的内容,复制下来随你的程序一起发布就可以了。第三条就不那么好理解了。简单来说,LGPL协议要求,如果你的类使用了LGPL库的代码,那么必须把这个类开源。例如,如果你的程序 app.exe 每个源文件都使用了 LGPL 库的代码,那么你的所有源代码都要开源。为了避免这种情况,我们通常编写一个封装器,把 LGPL库的代码封装起来,这样就只需要开放这个封装器的代码,而其他使用了这个封装器的代码就不需要开放。第四条是对第三条的一种补充:那些使用了封装器的程序不需要开源,但是你必须把你编译的那些中间文件开放出来,Windows 下就是那些 .o 文件。

    你很奇怪,为什么 LGPL协议要这样规定呢?LGPL 所做的工作是,它保证了用户能够有这样一种能力:修改你使用 LGPL 库函数的方式(那些封装器就是你使用 LGPL库的方式,那些已经开源了),重新编译这些代码,然后重新对程序进行连接(连接所需要的目标文件也是包含了的,这是第四条规定的),就可以得到一个新的可执行程序。

    好了,如果你还不明白如何使用,我们来看一个例子。

    假设我们使用一个名为 Lib 的库,这个库是基于 LGPL协议发布的。如果你使用 Lib.dll 做动态链接(Windows 下),好,一切 OK。无论你的程序怎么样,你都可以做你所做的事情。

    我们主要是来看,如果你要使用静态链接,那么你需要如何组织你的代码。如果你有一个 main.cpp(我们假设所有 Lib 库的函数都是用了 lib_ 前缀):

    • // main.cpp 
    • int main() { 
    •     lib_init(); 
    •     lib_do_something(); 
    •     lib_done(); 
    •     lib_close(); 
    •  
    •     return 0; 

    现在你已经完成了 main.cpp,但是你必须把它开源!因为它使用了 LGPL 库的代码。这是上面第三条规定的。我不想把它开源,怎么办呢?好,我们建一个新的文件 lib_wrapper.cpp:

    • void my_lib_init() 
    •     lib_init(); 
    •  
    • void my_lib_do_something() 
    •     lib_do_something(); 
    •  
    • void my_lib_done() 
    •     lib_done(); 
    •  
    • void my_lib_close() 
    •     lib_close(); 

    在 main.cpp 中,我们做相应的修改:

    • int main() { 
    •     my_lib_init(); 
    •     my_lib_do_something(); 
    •     my_lib_done(); 
    •     my_lib_close(); 
    •  
    •     return 0; 

    现在,main.cpp 不再是直接使用了 LGPL 库的代码了,因此它不需要开源,而我们的封装器 lib_wrapper.cpp 必须开源。

    好,编译一下我们的程序,你会得到 main.o(Windows 下)这个目标文件。

    在最终程序的发布中,你需要包含一下文件:

    1. 一份文档,其中声明:这个程序使用了 Lib库,这个库是基于 LGPL 协议发布的;
    2. LGPL.txt;
    3. lib_wrapper.cpp
    4. main.o

    这样,用户可以通过修改 lib_wrapper.cpp  的内容改变你使用 LGPL 库的方式,例如:

    • void my_lib_done() 
    •     lib_done(); 
    •     lib_close(); 
    •  
    • void my_lib_close() 
    •     // lib_close(); 

    然后编译这个 lib_wrapper.cpp,最终重新链接。一个新的可执行程序诞生啦!

    好了,这就是在使用 LGPL库开发闭源程序所需要遵守的东西了。还是建议大家能够遵守协议,尊重作者的劳动成果哦~


    文章2

    2009年06月27日 星期六 13:55
    From:

    http://www.qteverywhere.com/

    Qt 4.5中提供了三种授权协议,分别是GPL, LGPL和Commercial,可能很多人要问,为什么同样的一个产品要提供三种授权协议,什么情况下使用什么的样的授权协议最合适?在这里我就大致解释一下:

    GPL全称是The GNU General Public License,是目前大多数的GNU程序和超过半数的自由软件使用的许可协议。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免 费使用,但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。
    GPL协议的主要内容是只要在一个软件中使用(”使用”指类库引用,修改后的代码或者衍生代码)GPL 协议的产品,则该软件产品必须也采用GPL协议,既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题, 还可以享受免费的优势。

    回到LGPL,LGPL的全称是 GNU Lesser General Public License,GNU 较宽松公共许可证,也是由协议是由自由软体基金会发布的许可证,是一个主要为类库使用设计的开源协议,和GPL要求任何使用/修改/衍生之GPL类库的的 软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的 开源代码可以被商业软件作为类库引用并发布和销售。

    除了GPL和LGPL两种开源协议之外,Qt还提供了Commercial商业协议,Qt的商业协议是由Nokia定义的,由Nokia和购买方签 订的,具有法律效应的Qt产品授权协议。 Commercial License相教与GPL和LGPL,对于商业客户提供了更多的灵活性,客户可以任意的修改Qt的源代码,开发商业软件,而不需要公开任何源代码。并 且,在Commercial License中,我们还提供了技术支持服务。当然,商业授权协议是需要费用的。

    到底什么时候需要选择GPL和LGPL呢?一个最显而易见的理由就是他们都是免费的,使用LGPL和GPL版本的Qt是不需要支付任何费用的,当然 我们也相应的不会提供技术支持。如果你打算开发真正的开源软件,并希望使用者也可以保持开源,那么GPL是更好的选择,因为所有人,不论你自己还是将来基 于你的代码进行再次开发都必须开源。如果你打算开发闭源(不开放源代码)的商业软件,那么LGPL则更适合,但必须满足下面两个条件:
    1. 你的应用程序应该动态链接Qt函数库,并使你的应用程序与未做修改的LGPL库分开发布。同时必须确保使用者(接受者)知道应用程序使用了LGPL版本的Qt;
    2. 如果你对LGPL版本的Qt进行了任何修改,并发布,则必须遵循LGPL 条款发布。任何使用者有权利得到这些修改(通常情况下是源代码),并且确保使用者可以通过这些修改自己生成相应你修改过的Qt版本。

    相信到这里大家已经对Qt提供的这三种协议有了基本的了解,通常大家还会有一个疑问,就是基于这三种授权协议的Qt产品到底由多少功能上的区别,是 不是商业版本的会更完整,性能更好一些?这里我可以负责任的说:99%的代码都是一样的,无论是GPL, LGPL还是Commercial,功能,性能都没有区别,唯一的区别就在于授权协议的不同。

    还有一点需要说明的就是,由于LGPL是在Qt4.5这个版本里面才引入的,所以之前的Qt版本,4.4或者3.x的版本,并不提供LGPL协议,是不可逆的。同时未来发布的Qt版本,就一直会提供三种不同的授权协议版本。

    下面有一些链接,有兴趣想深入了解这些授权协议的同学,可以学习学习

    GPL协议原文 - http://www.gnu.org/copyleft/gpl.html
    GPL协议中文译文 - http://bergwolf.googlepages.com/gplv3_zh
    LGPL协议原文 - http://www.gnu.org/copyleft/lesser.html
    LGPL协议中文译文 - http://www.thebigfly.com/gnu/lgpl/lgpl-v3.php
    58种不同的开源协议 - http://www.fsf.org/licensing/licenses/
    什么是动态链接 -http://zh.wikipedia.org/wiki/%E5%8A%A8%E6%80%81%E9%93%BE%E6%8E%A5%E5%BA%93
    官方声明 - http://www.qtsoftware.com/about/news/lgpl-license-option-added-to-qt
    官方Q&A - http://www.qtsoftware.com/about/licensing/frequently-asked-questions
     


    本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/changsheng230/archive/2010/07/24/5761519.aspx

    Qt GPL, LGPL & Commercial License


    展开全文
  • 3. Qt的库最好不与产品同时发布[QT官方建议Qt软件从Qt官方网站下载Qt库,否则会违反为GLPL协议]。  但你会发现Qt提供的下载地址很难打得开。个人觉得这一条基本可以忽略,仅需遵循第2条即可;或者你可以用2张光盘...


     

    查过很多资料了,将商业软件与Qt LGPL的关系归结如下:

    1. 必须使用Qt的LGPL许可版本;

    2. Qt的库必须是动态链接,否则会有不必要的麻烦;

    3. Qt的库最好不与产品同时发布[QT官方建议Qt软件从Qt官方网站下载Qt库,否则会违反为GLPL协议]。

        但你会发现Qt提供的下载地址很难打得开。个人觉得这一条基本可以忽略,仅需遵循第2条即可;或者你可以用2张光盘,一张用来发布,另一张用来提供Qt的共享库。

     

    下面是转载的别人的3篇文章,在此感谢他们的知识共享精神。

    文章1:

    QT的LGPL与闭源程序【转载】
    发表于135 天前 ⁄ C/C++ ⁄ 暂无评论

    最近一直在学习 Qt。Qt 有两个许可证:LGPL 和商业协议。这两个协议在现在的 Qt 版本中的代码是完全一致的(潜在含义是,Qt 的早期版本,商业版的 Qt 通常包含有一些开源版本所没有的库,比如 QtSingleApplication 这个库)。所以现在对于普通开发人员和部分商业公司来说,使用 LGPL 版本的 Qt 可以节省很大的开销。这两个版本最大的区别在于,前者是免费的,后者是收费的。既然代码都是一致的,所以费用就要是用来购买 Qt 的售后服务和培训等等相关服务。

    现在我们是来说一下版权的问题。LGPL 是一个开源协议,因此,有人会担心 LGPL 能否用于开发闭源程序,能够拿来卖钱。尽管现在国内有些公司不是很重视这方面的问题,不过,如果你违反了协议,某一天被别人发来一纸律师函的时候,真的是欲哭无泪了哦。所以,我们还是先来研究一下这个协议,LGPL 究竟能不能用于开发闭源程序。

    以下内容是我查找了 N 多网站总结出来的,因为豆子不是律师,所以 LGPL 协议基本看不懂。究竟怎样去理解这个协议,还是希望能够有专业人士说出来。这里就算做是一种抛砖引玉吧!尽管没有十分的确定,但是这里所说的理解基本也是八九不离十的了。

    至于什么是 LGPL 协议,这里就不再多说了,我们关心的是,如果使用 LGPL 协议开发商业程序。请注意,这里所说的闭源程序,是指不以某种形式开放源代码,也就是说,用户(包括其他开发者)不能获取其源代码的程序。首先说明一点,LGPL协议是一个商业友好的协议。这里的含义是,你可以用 LGPL协议开发商业程序,当然也可以是非商业的闭源程序。但是,它是有一些限制的。这就是我们要讨论的重点。

    既然我们已经对其定性,那么我们直接进入主题:使用 LGPL 协议开发闭源程序,如果你使用动态链接的形式,那么,你可以以任何形式发布你的应用程序,商业的、非商业的、开源的、非开源的,随你。

    如果你因某种原因必须静态链接一个基于 LGPL 协议发布的库(一下我们简称为 LGPL 库),那么,你有义务进行下面的工作:

    1. 你必须在你的文档中说明,你的程序中使用了 LGPL 库,并且说明这个库是基于 LGPL 发布的;
    2. 你必须在你的应用程序发布中包含一份 LGPL协议,通常就是那个文本文件;
    3. 你必须开放使用了 LGPL 库代码的所有代码,例如某些封装器。但是,其他使用这些封装器的代码就不需要开放了;
    4. 你必须包含你的应用程序的余下部分的目标文件(通常就是我们所说的 .o 等等),或者是其他等价的文件。源代码并不是必须的。

    是不是很难理解呢?我们详细的说一下。

    第一条很容易理解;第二条也很容易理解,你可以在这里找到 LGPL 协议的内容,复制下来随你的程序一起发布就可以了。第三条就不那么好理解了。简单来说,LGPL协议要求,如果你的类使用了LGPL库的代码,那么必须把这个类开源。例如,如果你的程序 app.exe 每个源文件都使用了 LGPL 库的代码,那么你的所有源代码都要开源。为了避免这种情况,我们通常编写一个封装器,把 LGPL库的代码封装起来,这样就只需要开放这个封装器的代码,而其他使用了这个封装器的代码就不需要开放。第四条是对第三条的一种补充:那些使用了封装器的程序不需要开源,但是你必须把你编译的那些中间文件开放出来,Windows 下就是那些 .o 文件。

    你很奇怪,为什么 LGPL协议要这样规定呢?LGPL 所做的工作是,它保证了用户能够有这样一种能力:修改你使用 LGPL 库函数的方式(那些封装器就是你使用 LGPL库的方式,那些已经开源了),重新编译这些代码,然后重新对程序进行连接(连接所需要的目标文件也是包含了的,这是第四条规定的),就可以得到一个新的可执行程序。

    好了,如果你还不明白如何使用,我们来看一个例子。

    假设我们使用一个名为 Lib 的库,这个库是基于 LGPL协议发布的。如果你使用 Lib.dll 做动态链接(Windows 下),好,一切 OK。无论你的程序怎么样,你都可以做你所做的事情。

    我们主要是来看,如果你要使用静态链接,那么你需要如何组织你的代码。如果你有一个 main.cpp(我们假设所有 Lib 库的函数都是用了 lib_ 前缀):

    • // main.cpp 
    • int main() { 
    •     lib_init(); 
    •     lib_do_something(); 
    •     lib_done(); 
    •     lib_close(); 
    •  
    •     return 0; 

    现在你已经完成了 main.cpp,但是你必须把它开源!因为它使用了 LGPL 库的代码。这是上面第三条规定的。我不想把它开源,怎么办呢?好,我们建一个新的文件 lib_wrapper.cpp:

    • void my_lib_init() 
    •     lib_init(); 
    •  
    • void my_lib_do_something() 
    •     lib_do_something(); 
    •  
    • void my_lib_done() 
    •     lib_done(); 
    •  
    • void my_lib_close() 
    •     lib_close(); 

    在 main.cpp 中,我们做相应的修改:

    • int main() { 
    •     my_lib_init(); 
    •     my_lib_do_something(); 
    •     my_lib_done(); 
    •     my_lib_close(); 
    •  
    •     return 0; 

    现在,main.cpp 不再是直接使用了 LGPL 库的代码了,因此它不需要开源,而我们的封装器 lib_wrapper.cpp 必须开源。

    好,编译一下我们的程序,你会得到 main.o(Windows 下)这个目标文件。

    在最终程序的发布中,你需要包含一下文件:

    1. 一份文档,其中声明:这个程序使用了 Lib库,这个库是基于 LGPL 协议发布的;
    2. LGPL.txt;
    3. lib_wrapper.cpp
    4. main.o

    这样,用户可以通过修改 lib_wrapper.cpp  的内容改变你使用 LGPL 库的方式,例如:

    • void my_lib_done() 
    •     lib_done(); 
    •     lib_close(); 
    •  
    • void my_lib_close() 
    •     // lib_close(); 

    然后编译这个 lib_wrapper.cpp,最终重新链接。一个新的可执行程序诞生啦!

    好了,这就是在使用 LGPL库开发闭源程序所需要遵守的东西了。还是建议大家能够遵守协议,尊重作者的劳动成果哦~

    文章2:

    2009年06月27日 星期六 13:55
    From:

    http://www.qteverywhere.com/

    Qt 4.5中提供了三种授权协议,分别是GPL, LGPL和Commercial,可能很多人要问,为什么同样的一个产品要提供三种授权协议,什么情况下使用什么的样的授权协议最合适?在这里我就大致解释一下:

    GPL全称是The GNU General Public License,是目前大多数的GNU程序和超过半数的自由软件使用的许可协议。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免 费使用,但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。
    GPL协议的主要内容是只要在一个软件中使用(”使用”指类库引用,修改后的代码或者衍生代码)GPL 协议的产品,则该软件产品必须也采用GPL协议,既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题, 还可以享受免费的优势。

    回到LGPL,LGPL的全称是 GNU Lesser General Public License,GNU 较宽松公共许可证,也是由协议是由自由软体基金会发布的许可证,是一个主要为类库使用设计的开源协议,和GPL要求任何使用/修改/衍生之GPL类库的的 软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的 开源代码可以被商业软件作为类库引用并发布和销售。

    除了GPL和LGPL两种开源协议之外,Qt还提供了Commercial商业协议,Qt的商业协议是由Nokia定义的,由Nokia和购买方签 订的,具有法律效应的Qt产品授权协议。 Commercial License相教与GPL和LGPL,对于商业客户提供了更多的灵活性,客户可以任意的修改Qt的源代码,开发商业软件,而不需要公开任何源代码。并 且,在Commercial License中,我们还提供了技术支持服务。当然,商业授权协议是需要费用的。

    到底什么时候需要选择GPL和LGPL呢?一个最显而易见的理由就是他们都是免费的,使用LGPL和GPL版本的Qt是不需要支付任何费用的,当然 我们也相应的不会提供技术支持。如果你打算开发真正的开源软件,并希望使用者也可以保持开源,那么GPL是更好的选择,因为所有人,不论你自己还是将来基 于你的代码进行再次开发都必须开源。如果你打算开发闭源(不开放源代码)的商业软件,那么LGPL则更适合,但必须满足下面两个条件:
    1. 你的应用程序应该动态链接Qt函数库,并使你的应用程序与未做修改的LGPL库分开发布。同时必须确保使用者(接受者)知道应用程序使用了LGPL版本的Qt;
    2. 如果你对LGPL版本的Qt进行了任何修改,并发布,则必须遵循LGPL 条款发布。任何使用者有权利得到这些修改(通常情况下是源代码),并且确保使用者可以通过这些修改自己生成相应你修改过的Qt版本。

    相信到这里大家已经对Qt提供的这三种协议有了基本的了解,通常大家还会有一个疑问,就是基于这三种授权协议的Qt产品到底由多少功能上的区别,是 不是商业版本的会更完整,性能更好一些?这里我可以负责任的说:99%的代码都是一样的,无论是GPL, LGPL还是Commercial,功能,性能都没有区别,唯一的区别就在于授权协议的不同。

    还有一点需要说明的就是,由于LGPL是在Qt4.5这个版本里面才引入的,所以之前的Qt版本,4.4或者3.x的版本,并不提供LGPL协议,是不可逆的。同时未来发布的Qt版本,就一直会提供三种不同的授权协议版本。

    下面有一些链接,有兴趣想深入了解这些授权协议的同学,可以学习学习

    GPL协议原文 - http://www.gnu.org/copyleft/gpl.html
    GPL协议中文译文 - http://bergwolf.googlepages.com/gplv3_zh
    LGPL协议原文 - http://www.gnu.org/copyleft/lesser.html
    LGPL协议中文译文 - http://www.thebigfly.com/gnu/lgpl/lgpl-v3.php
    58种不同的开源协议 - http://www.fsf.org/licensing/licenses/
    什么是动态链接 - http://zh.wikipedia.org/wiki/%E5%8A%A8%E6%80%81%E9%93%BE%E6%8E%A5%E5%BA%93
    官方声明 - http://www.qtsoftware.com/about/news/lgpl-license-option-added-to-qt
    官方Q&A - http://www.qtsoftware.com/about/licensing/frequently-asked-questions
     


    本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/changsheng230/archive/2010/07/24/5761519.aspx

    Qt GPL, LGPL & Commercial License

     

    文章3:

    Qt 4.5中提供了三种授权协议,分别是GPL, LGPLCommercial,可能很多人要问,为什么同样的一个产品要提供三种授权协议,什么情况下使用什么的样的授权协议最合适?在这里我就大致解释一下:

    GPL
    全称是The GNU General Public License,是目前大多数的GNU程序和超过半数的自由软件使用的许可协议。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。
    GPL
    协议的主要内容是只要在一个软件中使用(”使用指类库引用,修改后的代码或者衍生代码)GPL 协议的产品,则该软件产品必须也采用GPL协议,既必须也是开源和免费。这就是所谓的传染性GPL协议的产品作为一个单独的产品使用没有任何问题,还可以享受免费的优势。

    回到LGPLLGPL的全称是 GNU Lesser General Public LicenseGNU 较宽松公共许可证,也是由协议是由自由软体基金会发布的许可证,是一个主要为类库使用设计的开源协议,和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。

    除了GPLLGPL两种开源协议之外,Qt还提供了Commercial商业协议,Qt的商业协议是由Nokia定义的,由Nokia和购买方签订的,具有法律效应的Qt产品授权协议。 Commercial License相教与GPLLGPL,对于商业客户提供了更多的灵活性,客户可以任意的修改Qt的源代码,开发商业软件,而不需要公开任何源代码。并且,在Commercial License中,我们还提供了技术支持服务。当然,商业授权协议是需要费用的。

    到底什么时候需要选择GPLLGPL呢?一个最显而易见的理由就是他们都是免费的,使用LGPLGPL版本的Qt是不需要支付任何费用的,当然我们也相应的不会提供技术支持。如果你打算开发真正的开源软件,并希望使用者也可以保持开源,那么GPL是更好的选择,因为所有人,不论你自己还是将来基于你的代码进行再次开发都必须开源。如果你打算开发闭源(不开放源代码)的商业软件,那么LGPL则更适合,但必须满足下面两个条件:
    1. 
    你的应用程序应该动态链接Qt函数库,并使你的应用程序与未做修改的LGPL库分开发布。同时必须确保使用者(接受者)知道应用程序使用了LGPL版本的Qt
    2. 
    如果你对LGPL版本的Qt进行了任何修改,并发布,则必须遵循LGPL 条款发布。任何使用者有权利得到这些修改(通常情况下是源代码),并且确保使用者可以通过这些修改自己生成相应你修改过的Qt版本。

    相信到这里大家已经对Qt提供的这三种协议有了基本的了解,通常大家还会有一个疑问,就是基于这三种授权协议的Qt产品到底由多少功能上的区别,是不是商业版本的会更完整,性能更好一些?这里我可以负责任的说:99%的代码都是一样的,无论是GPL, LGPL还是Commercial,功能,性能都没有区别,唯一的区别就在于授权协议的不同。

    还有一点需要说明的就是,由于LGPL是在Qt4.5这个版本里面才引入的,所以之前的Qt版本,4.4或者3.x的版本,并不提供LGPL协议,是不可逆的。同时未来发布的Qt版本,就一直会提供三种不同的授权协议版本。

     

    Nokia 自从收购了 Qt 之后,改变策略,不鼓励人们使用商业的 Qt 协议。而鼓励人们直接使用 LGPL  Qt 来开发软件。

    由于 Nokia 不想再对 Qt 提供商业支持,因此把 Qt 的价格定得非常高。希望用户都转而去使用社区支持的 Qt

    社区支持的 Qt 也同样可以开发商业软件的

    展开全文
  • LGPL协议的理解

    2015-09-09 17:58:00
    ... 最近一直在学习Qt。Qt有两个许可证:LGPL和商业协议。这两个协议在现在的Qt版本中的代码是完全一致的(潜在含义是,Qt的早期版 本,商业版的Qt通常包含有一些开源版本所没有的库,比如QtS...
  • LGPL 协议详解

    2015-02-11 13:57:00
    这里的含义是,你可以用 LGPL协议开发商业程序,当然也可以是非商业的闭源程序。但是,它是有一些限制的。这就是我们要讨论的重点。 既然我们已经对其定性,那么我们直接进入主题: 使用 LGPL 协议开发闭源程序,...
  • GPL和LGPL协议

    千次阅读 2010-05-17 17:41:00
    一直对GPL、LGPL、GPLV3的细节区别不清楚,今天转了一遍关于GPL和LGPL的文章当做参考资料。原文:http://simplesys.cn/2010/04/02/gpl%E5%92%8Clgpl%E5%8D%8F%E8%AE%AE/参考:...
  • 关于FFmpeg里的GPL和LGPL协议

    万次阅读 2018-07-17 13:54:34
    GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代 码做为闭源的商业软件发布和销售。这...
  • LGPL协议全文翻译

    千次阅读 2009-09-29 23:43:00
    It was not published by the Free Software Foundation, and does not legally state the distribution terms for software that uses the GNU LGPL--only the original English text of the GNU LGPL does that....
  • Qt 许可证(GPL/LGPL/商业协议)

    万次阅读 2019-06-14 15:08:15
    Qt 有两个许可证:LGPL 和商业协议。这两个协议在现在的 Qt 版本中的代码是完全一致的(潜在含义是,Qt 的早期版本,商业版的 Qt 通常包含有一些开源版本所没有的库,比如 QtSingleApplication 这个库)。所以现在...
  • 开源授权协议GPL和LGPL的区别

    千次阅读 2020-08-27 15:05:52
    开源授权协议 这里引用网上查询到的资料: GPL 是 GNU General Public License(GNU 通用公共许可证)的缩写形式;LGPL 是 GNU Lesser General Public License (GNU 宽通用公共许可证)的缩写形式。它们是自由软件...
  • GPL协议 与 LGPL协议

    千次阅读 2016-10-17 12:14:59
    (以下全文引用自博客“朝闻道”,链接...GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代 码做为闭源的
  • 推荐你看一下阮一峰的这篇博客 如何选择开源许可证? 通过图形图片比一大堆文字直观多了
  • 简而言之,GPL协议就是一个开放源代码协议,软件的初始开发者使用了GPL协议并公开软件的源程序后,后续使用该软件源程序开发软件者亦应当根据GPL协议把自己编写的源程序进行公开。GPL协议要求的关键在于开放源程序,...
  • LGPL协议

    千次阅读 2009-11-25 12:20:00
    如果修改了,那么修改的部分也必须遵循LGPL协议。 目前基本可以确定。Openfire方案是可行的。 Openfire服务器端是自用,用户是自己,所以不用公布源码。 而客户端打算重写一个API,看了一下Smack是LGPL的,那么...
  • 本文介绍开源的协议LGPL 是GNU Lesser General Public License(GNU 宽通用公共许可证)的缩写形式,旧称 GNU Library General Public License (GNU 库通用公共许可证),译为:更加宽松的通用公共许可证。 例如...
  • 四种常见软件开源协议介绍-GPL、LGPL、BSD、Apache 软件在发布或销售的时候应当关注软件代码中是否引用/修改/衍生了使用开源协议的源代码以及使用了哪种开源软件协议,满足不同的开源软件协议的使用限制,避免触犯...
  • LGPL与闭源程序

    2018-12-07 10:38:00
    这里的含义是,你可以用 LGPL协议开发商业程序,当然也可以是非商业的闭源程序。但是,它是有一些限制的。这就是我们要讨论的重点。 既然我们已经对其定性,那么我们直接进入主题: 使用 LGPL 协议开发闭源程序,...
  • 整理了一下常见的开源协议,希望大家对开源协议有更进一步的了解。 先看一张总结图 BSD开源协议 BSD是"Berkeley Software Distribution"的缩写,意思是"伯克利软件发行版"。 BSD开源协议:是一个给于使用者很大自由...
  • 但是LGPL, Apache License, BSD就不存在这个问题,后两者只要求你对软件原作者的工作进行必要的认可和尊重就行了,所以这是适合商业应用的。 所以在选择应用开源软件时,一定要明白自己的用途,选择合适许可证下的...
  • LGPL开源软件使用风险说明

    千次阅读 2018-02-11 10:33:11
    【转】http://blog.csdn.net/ojoe/article/details/6283082Qt的LGPL协议是否意味着可以自由用QT开发商业软件?查过很多资料了,将商业软件与Qt LGPL的关系归结如下:1. 必须使用Qt的LGPL许可版本;2. Qt的库必须是...
  • 什么是LGPL开源协议

    千次阅读 2011-04-25 13:56:00
    什么是LGPL开源协议

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 12,231
精华内容 4,892
关键字:

lgpl协议