（1）Contributors??和??Recipients
Contributors? ? 指的是對某個開源軟件或項目提供了代碼（包括最初的或者修改過的）發布的人或者實體（團隊、公司、組織等），Contributors??按照參與某個軟 件開源的時間先后，可以分為an??initial??Contributor??和??subsequent??Contributors??。
Recipients指的是開源軟件或項目的獲取者，顯然，subsequent??Contributors??也屬于??Recipients之列。

（2）Source??Code??和??Object??Code
Source??Code??指的是各種語言寫成的源代碼，通過Source??Code，結合文檔，??可以了解到整個軟件的體系結構及具體到某個功能函數的實現方法等。
Object??Code??指的是Source??Code??經過編譯之后，生成的類似于“類庫”一樣的，提供各種接口供他人 使用 的目標碼，按我的理解，它就是像常見的DLL、AtiveX、OCX控件性質的東西。（不知道這樣理解對不對）
分清楚這兩個概念的目的在于，有些開源，只發布Object??Code??，當然，大多數發布的是Source??Code。很多協議也對??“你發布的是哪種Code的時候應該怎樣”，有著明確的約束。

（3）Deriv ati ve??Module??和??Separate??Module
Derivative??Module??指的是，依托或包含“最初的”或者“從別人處獲取的”開源代碼而產生的代碼，是原“源代碼”的增強（不等于增加）、改善和延續的模塊，意為“衍生模塊”。
Separate??Module??指的是，參考或借助原“源代碼”，開發出的獨立的，不包含、不依賴于原“源代碼模塊”，意為“獨立的模塊”。
理解這兩個概念的目的在于，很多協議對涉及到商業發布的時候，會有哪些是衍生的，哪些是獨立的，有著明確的商業發布規定。
? ?? ?接下來，說說常見的幾種協議吧。其實上面我給出的幾篇文章的鏈接里面對一些常見的 開源協議 已經有比較清晰的描述了，我這里也只是加人了個人的一些理解，希望對接觸得少的人有一定的幫助吧。
GPL（Gun??General??Public??License）??vesion??2.0? ? 1991
? ?? ?最常見的開源協議，使用它作為授權協議的有大名鼎鼎的??Linux??。GPL最顯著的兩個特點就是網上稱為的“病毒性傳播”和“不允許閉源的商業發布”。
? ?? ? 所謂的“病毒性傳播”，指的是，GPL規定，所有從GPL協議授權的源碼衍生出來的（即上面提到的DerivativeModule），或者要跟GPL授 權的源碼混著用的Project，都要遵循GPL協議，就像病毒一樣，粘上了關系，就“中毒”了。GPL這樣規定的目的是，保證在GPL協議保護下的產 品，不會再受到其他協議或者授權的約束。即讓跟GPL有關系的源碼都能 免費 獲 取。舉個例子，如果你的改進的Linux中使用了GPL授權下的開源模塊（也必須使用，你不可能自己重新去做個內核吧，如果做出來了，你也沒必要叫 Linux了。），那么你整個Linux產品也必須遵循??GPL協議去開源，不能以其他方式去開源發布，更不允許閉源發布。這樣一來，就不會出現這樣一 個Linux－－這個功能是GPL協議授權的，可以 免費 獲取源碼，而另外一個功能是其他協議下的，拿不到源碼。這點規定對使用或者研究該產品的人來說，是一個極大的便利。
? ?? ? 而“不允許閉源商業發布”指的是，在??GPL授權下，你的軟件產品可以商業發布，拿去賣錢，但是在這同時，你也必須將該產品的源碼以GPL協議方式開源 發布出去，供他人免費獲取。也許有人會迷惑，拿去賣，又同時開源，那誰來買阿？這個產品怎么賺錢呢？？這就涉及到開源產品的商業模式的問題了，想了解相關 一些信息的話，可以看看以上我給出鏈接的一些文章。至于后面，可能會寫一篇關于開源項目的商業模式的隨筆。
? ?? ?GPL協議下的商業發布的一個關鍵點就像??Java??視線論壇的??Robbin所說的，GPL是針對軟件源代碼的版權，而不是針對軟件編譯后二進 制版本的版權。你有權免費獲得軟件的源代碼，但是你沒有權力免費獲得軟件的二進制發行版本。GPL對軟件發行版本唯一的限制就是：你的發行版本必須把完整 的源代碼一同提供。

BSD（Berkeley??Software??Distribution）
? ?? ?跟GPL有很大的不同，BSD協議是給予人很大的自由的一種開源協議。其最大的特點是，Recipients??幾乎可以對源碼“為所欲為”，可以自由 地修改，自由地使用，修改后再以其他方式再發布（商業或者開源）。但，你做這些事情的時候，還是得遵循以下規則：
? ?? ? 1．??如果再發布的產品中包含原“源代碼”，則在原“源代碼”中必須帶有原來代碼中的BSD協議。??
? ?? ? 2．??如果再發布的只是二進制類庫/軟件（Object??Code??/??Product），則需要在類庫/軟件的文檔和版權聲明中包含原來代碼中的BSD協議。??
? ?? ? 3．??不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣。??
? ?? ? 其實這幾個規則約定的目的也只是達到一個目的：是他人的東西，別人以BSD開源了，你就不能不做任何聲明而占為己有，更不能用他人的名義來做商業推廣。你只對你自己的東西擁有絕對控制權。
? ?? ? 舉個例子，你用開源代碼（A）修改或做其他增添之后，產生了產品B，這時候，你對B的控制由你自己決定，你可以用任何協議再開源，也可以閉源商業發布。 但，因為如果B中包含了A或A的一部分（一點都不包含就不叫修改了），那你在B產品的版權聲明中，必須有提到你有使用到A??，并且附帶上??A??的開 源協議。而且不能做商業推廣的時候??將??B??冠以??原開源作者的名義以促進商業推廣。
? ?? ?BSD代碼鼓勵代碼共享，但需要尊重代碼作者的著作權。BSD由于允許使用者修改和重新發布代碼，也允許使用或在BSD代碼上開發商業軟件發布和銷售， 因此是對商業集成很友好的協議。而很多的公司企業在選用開源產品的時候都首選BSD協議，因為可以完全控制這些第三方的代碼，在必要的時候可以修改或者二 次開發。??

Apache??Licence? ? vesion??2.0??
Apache??Licence??是著名的非盈利開源組織??Apache??采用的協議。該協議和BSD類似，同樣鼓勵代碼共享和尊重原作者的著作 權，同樣允許代碼修改，再發布（作為開源或商業軟件）。需要滿足的條件也和BSD類似：（配備英文原文，方便更準確理解）??
1．??需要給??Recipients??一份Apache??Licence??
? ???（You??must??give??any??other??recipients??of??the??Work??or??DerivativeWorks??a??copy??of??this??License）
2．??如果你修改了代碼，需要在被修改的文件中進行說明。
? ? （You??must??cause??any??modified??files??to??carry??prominent??noticesstating??that??You??changed??the??files）??
3．??在Derivative??Module中（修改和包含源代碼而衍生的代碼）需要帶有原來代碼中的協議，商標，專利聲明和其他原來作者規定需要包含的說明。??
? ? （You??must??retain,??in??the??Source??form??of??any??DerivativeWorks??that??You??distribute,? ? all??copyright,??patent,??trademark,??and??attribution??noticesfrom??the??Source??form??of??the??Work,? ? excluding??those??notices??that??do??not??pertain??to??anypart??of??the??Derivative??Works）
4．??如果再發布的產品中包含一個Notice文件，則在Notice文件中需要帶有Apache??Licence。你可以在Notice中增加自己的許可，但不可以表現為對ApacheLicence構成更改。
? ?Apache??Licence也是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要并作為開源或商業產品發布/銷售。??

? ? LGPL??
? ???LGPL??是GPL的一個為主要為類庫使用設計的開源協議。和GPL要求任何使用/修改/衍生之GPL類庫的的軟件必須采用GPL協議不同。 LGPL允許商業軟件通過類庫引用(link)方式使用LGPL類庫而不需要開源商業軟件的代碼。這使得采用LGPL協議的開源代碼可以被商業軟件作為類 庫引用并發布和銷售。??
? ???但是如果修改LGPL協議的代碼或者衍生，則所有修改的代碼，涉及修改部分的額外代碼和衍生的代碼都必須采用LGPL協議。因此LGPL協議的開源 代碼很適合作為第三方類庫被商業軟件引用，但不適合希望以LGPL協議代碼為基礎，通過修改和衍生的方式做二次開發的商業軟件采用。

? ? CPL(Common??Public??Liecense)??vesion??1.0
? ? CPL? ? 是??IBM??提出的并通過了OSI（Open??Source??Initiative）批準的開源協議。主要用于一些IBM??或跟??IBM?? 相關的開源軟件??/項目中。如??很著名的Java開發環境??Eclipse??、RIA開發平臺Open??Laszlo等。

? ???CPL也是一項對商業應用友好的協議。它允許??Recipients??對源碼進行任意的使用、復制、分發、傳播、展示、修改以及改后做閉源的二次商業發布，這點跟BSD??很類似，也屬于自由度比較高的開源協議。但是，需要遵循：
? ???1.當一個Contributors? ? 將源碼的整體或部分再次開源發布的時候，必須繼續遵循CPL??開源協議來發布，而不能改用其他協議發布。除非你得到了原“源碼”Owner? ? 的??授權。
? ???2.CPL協議下，你可以將源碼不做任何修改來商業發布。但如果你要將修改后的源碼其開源，而且當你再發布的是ObjectCode??的時候，你必須聲明??它的Source??Code??是可以獲取的，而且要告知獲取方法
? ???3.當你需要將??CPL??下的源碼作為一部分跟其他私有的源碼混和著成為一個??Project發布的時候，你可以將整個Project/Product??以私人的協議發布，但要聲明哪一部分代碼是CPL下的，而且聲明那部分代碼繼續遵循CPL。

? ?4.獨立的模塊（Separate??Module），不需要開源

開源license總結