看QT License了解 License協議

      一直對這些License協議糾結著，自己學習自己弄弄，都不會去註意它，但和商業扯上關系，那就麻煩了。還是了解下比較好。所以，看下QT是怎麽做的。

      在QT的LICENSE FAQ下面這麽說的

https://www.qt.io/faq/#_Toc453700682

Qt is a commercial and open source licensed product developed by The Qt Company, together with the Qt project under the open source governance model.

In order to develop and distribute your product with Qt, you must adhere to obligations and definitions enforced by the licensing agreements.

1.2.      What are the licensing options for Qt?

Starting from Qt 5.7, Qt is licensed under
?  Commercial license
?  LGPL3 open source license
?  GPL2 or GPLv3 open source license

The general Qt toolkit, consisting of Qt Essential code libraries, the Qt add-on APIs, and the Qt Creator IDE are available dual-licensed for commercial and GPL licenses. Most of the Qt APIs are available also under LGPLv3 license but not all of the Qt Add-on modules.

In addition, the commercial Qt license includes additional tools and solutions for embedded development.

      QT是聲明在商業license和LGPL GPL下。

商業協議

      這個應該是按照一定協議格式做出該軟件的一些相關聲明，相關內容http://www.qt.io/terms-conditions/

開源協議

      這個就是由相關組織指定好的協議說明。

      關於這個，網上有文章寫得不錯，

引文：

    最近一直在學習 Qt。Qt 有兩個許可證：LGPL 和商業協議。這兩個協議在現在的 Qt 版本中的代碼是完全一致的（潛在含義是，Qt 的早期版本，商業版的 Qt 通常包含有一些開源版本所沒有的庫，比如 QtSingleApplication 這個庫）。所以現在對於普通開發人員和部分商業公司來說，使用 LGPL 版本的 Qt 可以節省很大的開銷。這兩個版本最大的區別在於，前者是免費的，後者是收費的。既然代碼都是一致的，所以費用就要是用來購買 Qt 的售後服務和培訓等等相關服務。

    現在我們是來說一下版權的問題。LGPL 是一個開源協議，因此，有人會擔心 LGPL 能否用於開發閉源程序，能夠拿來賣錢。盡管現在國內有些公司不是很重視這方面的問題，不過，如果你違反了協議，某一天被別人發來一紙律師函的時候，真的是欲哭無淚了哦。所以，我們還是先來研究一下這個協議，LGPL 究竟能不能用於開發閉源程序。

    以下內容是我查找了 N 多網站總結出來的，因為豆子不是律師，所以 LGPL 協議基本看不懂。究竟怎樣去理解這個協議，還是希望能夠有專業人士說出來。這裏就算做是一種拋磚引玉吧！盡管沒有十分的確定，但是這裏所說的理解基本也是八九不離十的了。

    至於什麽是 LGPL 協議，這裏就不再多說了，我們關心的是，如果使用 LGPL 協議開發商業程序。請註意，這裏所說的閉源程序，是指不以某種形式開放源代碼，也就是說，用戶（包括其他開發者）不能獲取其源代碼的程序。首先說明一點，LGPL協議是一個商業友好的協議。這裏的含義是，你可以用 LGPL協議開發商業程序，當然也可以是非商業的閉源程序。但是，它是有一些限制的。這就是我們要討論的重點。

    既然我們已經對其定性，那麽我們直接進入主題：使用 LGPL 協議開發閉源程序，如果你使用動態鏈接的形式，那麽，你可以以任何形式發布你的應用程序，商業的、非商業的、開源的、非開源的，隨你。如果你因某種原因必須靜態鏈接一個基於 LGPL 協議發布的庫（一下我們簡稱為 LGPL 庫），那麽，你有義務進行下面的工作：

    是不是很難理解呢？我們詳細的說一下。

    第一條很容易理解；第二條也很容易理解，你可以在這裏找到 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，最終重新鏈接。一個新的可執行程序誕生啦！

引文二：

    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

      還有一篇

現今存在的開源協議很多，而經過Open Source Initiative組織通過批準的開源協議目前有58種（http://www.opensource.org/licenses /alphabetical）。我們在常見的開源協議如BSD, GPL, LGPL,MIT等都是OSI批準的協議。如果要開源自己的代碼，最好也是選擇這些被批準的開源協議。

這裏我們來看四種最常用的開源協議及它們的適用範圍，供那些準備開源或者使用開源產品的開發人員/廠家參考。

BSD開源協議（original BSD license、FreeBSD license、Original BSD license）

BSD開源協議是一個給於使用者很大自由的協議。基本上使用者可以”為所欲為”,可以自由的使用，修改源代碼，也可以將修改後的代碼作為開源或者專有軟件再發布。

但”為所欲為”的前提當你發布使用了BSD協議的代碼，或則以BSD協議代碼為基礎做二次開發自己的產品時，需要滿足三個條件：

   1. 如果再發布的產品中包含源代碼，則在源代碼中必須帶有原來代碼中的BSD協議。
   2. 如果再發布的只是二進制類庫/軟件，則需要在類庫/軟件的文檔和版權聲明中包含原來代碼中的BSD協議。
   3. 不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣。

BSD 代碼鼓勵代碼共享，但需要尊重代碼作者的著作權。BSD由於允許使用者修改和重新發布代碼，也允許使用或在BSD代碼上開發商業軟件發布和銷售，因此是對商業集成很友好的協議。而很多的公司企業在選用開源產品的時候都首選BSD協議，因為可以完全控制這些第三方的代碼，在必要的時候可以修改或者二次開發。

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

Apache Licence是著名的非盈利開源組織Apache采用的協議。該協議和BSD類似，同樣鼓勵代碼共享和尊重原作者的著作權，同樣允許代碼修改，再發布（作為開源或商業軟件）。需要滿足的條件也和BSD類似：

   1. 需要給代碼的用戶一份Apache Licence
   2. 如果你修改了代碼，需要再被修改的文件中說明。
   3. 在延伸的代碼中（修改和有源代碼衍生的代碼中）需要帶有原來代碼中的協議，商標，專利聲明和其他原來作者規定需要包含的說明。
   4. 如果再發布的產品中包含一個Notice文件，則在Notice文件中需要帶有Apache Licence。你可以在Notice中增加自己的許可，但不可以表現為對Apache Licence構成更改。

Apache Licence也是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要並作為開源或商業產品發布/銷售。

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等類似。

關於開源協議GPL　V2和V3

單從開源行業的GPL協議上來看，似乎開源linux產品上的一切是可以無條件的開放和共享的，但是從實際的操作來看，在GPL相對的許可授權之下，又有其相對封閉的一面，就這次的GPL v2到GPL v3的修訂改版來說，正是GPL協議“封閉”一面的具體體現。

根據GPL v2的相關規定：只要這種修改文本在整體上或者其某個部分來源於遵循GPL的程序，該修改文本的整體就必須按照GPL流通，不僅該修改文本的源碼必須向社會公開，而且對於這種修改文本的流通不準許附加修改者自己作出的限制。而在GPL v3的修訂草案中，不僅要求用戶公布修改的源代碼，還要求公布相關硬件，恰恰是這一條，由於觸及和其他相關數字版權管理(DRM)及其產品的關系，並且也由於有和開源精神相違的地方，所以備受爭議，甚至因此也遭到了有著“LINUX之父”之稱的托瓦爾茲的反對。

從表面上看，GPL v2到GPL v3的升級之困只不過是對協議修訂過程中某一條款的分歧，而更為嚴重的是在兩種協議都合法存在的前提下，具體的開源軟件或者開源產品的所有者有權選擇是遵循GPL v2協議還是恪守GPL v3協議，因此沖突也就來了，這種沖突正如中科紅旗的CTO鄭忠源描述的那樣：“世界有如此多軟件都在GPL v2的約束之下，而自由軟件是集合全世界程序員勞動，即使是貢獻一行代碼，如果該程序員只同意這一代碼只遵循GPL v2之下，就不能隨便去修改協議。如果計劃將軟件轉移到GPL v3之下，理論上講，必須征得所有代碼人的同意。但是目前還很難確定有多少開發人員願意轉移到新版本之下，如果有的人願意轉，有的人不願意轉，這其中就有很多的麻煩；而如果多數人都不願意改變，那這一事情也許就無聲無息……”

通過業內人士的精辟描述，相信大家一定對開源行業和開源軟件產品有了一個全新的認識吧，就那熟悉的LINUX系統來說，雖然表面上看起來大家有權按照自己的需要和目的進行任意的改寫重組，但是在諸多的獨立程序面前，別人是只能共享使用，而無權修改的，當然獲得授權就另當別論了。而就GPL v2到GPL v3的協議升級來說，這種協議的選擇上的分歧實際上也是開源行業裏一種觀念認知上的相左，到底誰的選擇是正確的？絕對不是一兩句話能說得清的，尤其是在各種利益交織之下。

情勢之下，開源社區的GPL v2與GPL v3選擇之困很現實的會在相當一段時間內給這個行業及其產品造成“兼容問題”，說白了就是兩種協議以及兩種協議之下的矛盾，不管是人的還是產品的都將會持續下去，而這種僵持對整個開源行業來說未必是一件好事，最起碼從“精神”方面來說這個行業已經在開始分道揚鑣。

LGPL（GNU Lesser General Public License）

LGPL是GPL的一個為主要為類庫使用設計的開源協議。和GPL要求任何使用/修改/衍生之GPL類庫的的軟件必須采用GPL協議不同。 LGPL 允許商業軟件通過類庫引用(link)方式使用LGPL類庫而不需要開源商業軟件的代碼。這使得采用LGPL協議的開源代碼可以被商業軟件作為類庫引用並發布和銷售。

但是如果修改LGPL協議的代碼或者衍生，則所有修改的代碼，涉及修改部分的額外代碼和衍生的代碼都必須采用LGPL協議。因此LGPL協議的開源代碼很適合作為第三方類庫被商業軟件引用，但不適合希望以LGPL協議代碼為基礎，通過修改和衍生的方式做二次開發的商業軟件采用。

GPL/LGPL都保障原作者的知識產權，避免有人利用開源代碼復制並開發類似的產品

MIT（MIT）

文章來源：