??想了解更多關于開源的內容，請訪問：??

??51CTO 開源基礎軟件社區??

??https://ost.51cto.com??

開源協議概覽

Apache License

Apache License（Apache許可證），是Apache軟件基金會發布的一個自由軟件許可證。

Apache Licence是著名的非盈利開源組織Apache采用的協議。該協議和BSD類似，同樣鼓勵代碼共享和最終原作者的著作權，同樣允許源代碼修改和再發布。但是也需要遵循以下條件：

• 需要給代碼的用戶一份Apache Licence。
• 如果修改了代碼，需要再被修改的文件中說明。
• 在衍生的代碼中（修改和有源代碼衍生的代碼中）需要帶有原來代碼中的協議，商標，專利聲明和其他原來作者規定需要包含的說明。
• 如果再發布的產品中包含一個Notice文件，則在Notice文件中需要帶有Apache Licence。你可以再Notice中增加自己的許可，但是不可以表現為對Apache Licence構成更改。
• Apache Licence也是對商業應用友好的許可。使用者也可以再需要的時候修改代碼來滿足并作為開源或商業產品發布/銷售。

使用這個協議的好處是:

• 永久權利 一旦被授權，永久擁有。
• 全球范圍的權利 在一個國家獲得授權，適用于所有國家。假如你在美國，許可是從印度授權的，也沒有問題。
• 授權免費 無版稅， 前期、后期均無任何費用。
• 授權無排他性 任何人都可以獲得授權
• 授權不可撤消 一旦獲得授權，沒有任何人可以取消。比如，你基于該產品代碼開發了衍生產品，你不用擔心會在某一天被禁止使用該代碼

BSD

BSD是"Berkeley Software Distribution"的縮寫，意思是"伯克利軟件發行版"。

BSD開源協議：是一個給于使用者很大自由的協議。可以自由的使用，修改源代碼，也可以將修改后的代碼作為開源或者專有軟件再發布。 當你發布使用了BSD協議的代碼，或則以BSD協議代碼為基礎做二次開發自己的產品時，需要滿足三個條件：

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

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

GPL

GPL （GNU General Public License） ：GNU通用公共許可協議。

Linux 采用了 GPL。

GPL協議和BSD, Apache Licence等鼓勵代碼重用的許可很不一樣。GPL的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用，但不允許修改后和衍生的代碼做為閉源的商業軟件發布和銷售。這也就是為什么我們能用免費的各種linux，包括商業公司的linux和linux上各種各樣的由個人，組織，以及商業軟件公司開發的免費軟件了。

LGPL

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

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

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

MIT

MIT是和BSD一樣寬范的許可協議,源自麻省理工學院（Massachusetts Institute of Technology, MIT），又稱X11協議。作者只想保留版權,而無任何其他了限制。MIT與BSD類似，但是比BSD協議更加寬松，是目前最少限制的協議。這個協議唯一的條件就是在修改后的代碼或者發行包包含原作者的許可信息。適用商業軟件。使用MIT的軟件項目有：jquery、Node.js。

MIT與BSD類似，但是比BSD協議更加寬松，是目前最少限制的協議。這個協議唯一的條件就是在修改后的代碼或者發行包包含原作者的許可信息。適用商業軟件。使用MIT的軟件項目有：jquery、Node.js。

MPL (Mozilla Public License 1.1)

MPL協議允許免費重發布、免費修改，但要求修改后的代碼版權歸軟件的發起者 。這種授權維護了商業軟件的利益，它要求基于這種軟件的修改無償貢獻版權給該軟件。這樣，圍繞該軟件的所有代碼的版權都集中在發起開發人的手中。但MPL是允許修改，無償使用得。MPL軟件對鏈接沒有要求。

EPL (Eclipse Public License 1.0)

EPL允許Recipients任意使用、復制、分發、傳播、展示、修改以及改后閉源的二次商業發布。

使用EPL協議，需要遵守以下規則：

• 當一個Contributors將源碼的整體或部分再次開源發布的時候,必須繼續遵循EPL開源協議來發布,而不能改用其他協議發布.除非你得到了原"源碼"Owner 的授權；
• EPL協議下,你可以將源碼不做任何修改來商業發布.但如果你要發布修改后的源碼,或者當你再發布的是Object Code的時候,你必須聲明它的Source Code是可以獲取的,而且要告知獲取方法；
• 當你需要將EPL下的源碼作為一部分跟其他私有的源碼混和著成為一個Project發布的時候,你可以將整個Project/Product以私人的協議發布,但要聲明哪一部分代碼是EPL下的,而且聲明那部分代碼繼續遵循EPL；
• 4.獨立的模塊(Separate Module),不需要開源。

Creative Commons 知識共享協議

Creative Commons (CC) 許可協議并不能說是真正的開源協議，它們大多是被使用于設計類的工程上。 CC 協議種類繁多，每一種都授權特定的權利。 一個 CC 許可協議具有四個基本部分，這幾個部分可以單獨起作用，也可以組合起來。下面是這幾部分的簡介：

• 署名 作品上必須附有作品的歸屬。如此之后，作品可以被修改，分發，復制和其它用途。
• 相同方式共享 作品可以被修改、分發或其它操作，但所有的衍生品都要置于CC許可協議下。
• 非商業用途 作品可以被修改、分發等等，但不能用于商業目的。但語言上對什么是"商業"的說明十分含糊不清 (沒有提供精確的定義)，所以你可以在你的工程里對其進行說明。例如，有些人簡單的解釋"非商業"為不能出售這個作品。而另外一些人認為你甚至不能在有廣告的網站上使用它們。 還有些人認為"商業"僅僅指你用它獲取利益。
• 禁止衍生作品

CC 許可協議的這些條款可以自由組合使用。大多數的比較嚴格的CC協議會聲明 "署名權，非商業用途，禁止衍生"條款，這意味著你可以自由的分享這個作品，但你不能改變它和對其收費，而且必須聲明作品的歸屬。這個許可協議非常的有用，它可以讓你的作品傳播出去，但又可以對作品的使用保留部分或完全的控制。最少限制的CC協議類型當屬 "署名"協議，這意味著只要人們能維護你的名譽，他們對你的作品怎么使用都行。

CC 許可協議更多的是在設計類工程中使用，而不是開發類，但沒有人或妨礙你將之使用與后者。只是你必須要清楚各部分條款能覆蓋到的和不能覆蓋到的權利。

圖解分析

??想了解更多關于開源的內容，請訪問：??

??51CTO 開源基礎軟件社區??

??https://ost.51cto.com??