基本概念瞭解:
1. Contributors 和 Recipients
Contributors 指的是對某個開源軟件或項目提供了代碼(包括最初的或者修改過的)發佈的人或者實9999999體(團隊、公司、組織等),Contributors 按照參與某個軟件開源的時間先後,可以分為 an initial Contributor 和 subsequent Contributors .
Recipients指的是開源軟件或項目的獲取者,顯然,subsequent Contributors 也屬於 Recipients之列.
2. Source Code 和 Object Code
Source Code 指的是各種語言寫成的源代碼,通過Source Code,結合文檔, 可以瞭解到整個軟件的體系結構及具體到某個功能函數的實現方法等.
Object Code 指的是Source Code 經過編譯之後,生成的類似於“類庫”一樣的,提供各種接口供他人使用的目標碼,按我的理解,它就是像常見的DLL、ActiveX、OCX控件性質的東西.(不知道這樣理解對不對)
分清楚這兩個概念的目的在於,有些開源,只發布Object Code ,當然,大多數發佈的是Source Code.很多協議也對 “你發佈的是哪種Code的時候應該怎樣”,有著明確的約束.
3. Derivative Module 和 Separate Module
Derivative Module 指的是,依託或包含“最初的”或者“從別人處獲取的”開源代碼而產生的代碼,是原“源代碼”的增強(不等於增加)、改善和延續的模塊,意為“衍生模塊”.
Separate Module 指的是,參考或藉助原“源代碼”,開發出的獨立的,不包含、不依賴於原“源代碼模塊”,意為“獨立的模塊”.理解這兩個概念的目的在於,很多協議對涉及到商業發佈的時候,會有哪些是衍生的,哪些是獨立的,有著明確的商業發佈規定.
現今存在的開源協議很多,而經過Open Source Initiative組織通過批准的開源協議目前有58種.我們在常見的開源協議如BSD, GPL, LGPL,MIT等都是OSI批准的協議.如果要開源自己的代碼,最好也是選擇這些被批准的開源協議.
這裡我們來看四種最常用的開源協議及它們的適用範圍,供那些準備開源或者使用開源產品的開發人員/廠家參考.
BSD開源協議(Berkeley Software Distribution )
BSD開源協議是一個給予使用者很大自由的協議.基本上使用者可以“為所欲為”可以自由的使用,修改源代碼,也可以將修改後的代碼作為開源或者專有軟件再發布.但“為所欲為”的前提當你發佈使用了BSD協議的代碼,或則以BSD協議代碼為基礎做二次開發自己的產品時,需要滿足三個條件:
1. 如果再發布的產品中包含源代碼,則在源代碼中必須帶有原來代碼中的BSD協議.
2. 如果再發布的只是二進制類庫/軟件,則需要在類庫/軟件的文檔和版權聲明中包含原來代碼中的BSD協議.
3. 不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣.
其實這幾個規則約定的目的也只是達到一個目的:是他人的東西,別人以BSD開源了,你就不能不做任何聲明而佔為己有,更不能用他人的名義來做商業推廣.你只對你自己的東西擁有絕對控制權.
舉個例子,你用開源代碼(A)修改或做其他增添之後,產生了產品B,這時候,你對B的控制由你自己決定,你可以用任何協議再開源,也可以閉源商業發佈.但,因為如果B中包含了A或A的一部分(一點都不包含就不叫修改了),那你在B產品的版權聲明中,必須有提到你有使用到 A ,並且附帶上 A 的開源協議.而且不能做商業推廣的時候將B 冠以原開源作者的名義以促進商業推廣.
BSD代碼鼓勵代碼共享,但需要尊重代碼作者的著作權.BSD由於允許使用者修改和重新發布代碼,也允許使用或在BSD代碼上
開發商業軟件發佈和銷售,因此是對商業集成很友好的協議.而很多的公司企業在選用開源產品的時候都首選BSD協議,因為可以完全控制這些第三方的代碼,在必要的時候可以修改或者二次開發.
Apache Licence 2.0
Apache Licence是著名的非盈利開源組織Apache採用的協議.該協議和BSD類似,同樣鼓勵代碼共享和尊重原作者的著作權,同樣允許代碼修改,再發布(作為開源或商業軟件).需要滿足的條件也和BSD類似:
1. 需要給代碼的用戶一份Apache Licence
2. 如果你修改了代碼,需要再被修改的文件中說明.
3. 在延伸的代碼中(修改和有源代碼衍生的代碼中)需要帶有原來代碼中的協議,商標,專利聲明和其他原來作者規定需要包含的說明.
4. 如果再發布的產品中包含一個Notice文件,則在Notice文件中需要帶有Apache Licence.你可以在Notice中增加自己的許可,但不可以表現為對Apache Licence構成更改.
Apache Licence也是對商業應用友好的許可.使用者也可以在需要的時候修改代碼來滿足需要並作為開源或商業產品發佈/銷售.
GPL (Gun General Public License)vesion 2.0 1991
我們很熟悉的Linux就是採用了GPL.GPL協議和BSD, Apache Licence等鼓勵代碼重用的許可很不一樣.GPL的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用,但不允許修改後和衍生的代碼做為閉源的商業軟件發佈和銷售.這也就是為什麼我們能用免費的各種linux,包括商業公司的linux和linux上各種各樣的由個人,組織,以及商業軟件公司開發的免費軟件了.
GPL協議的主要內容是隻要在一個軟件中使用(“使用”指類庫引用,修改後的代碼或者衍生代碼)GPL協議的產品,則該軟件產品必須也採用 GPL協議,既必須也是開源和免費.這就是所謂的“傳染性”.GPL協議的產品作為一個單獨的產品使用沒有任何問題,還可以享受免費的優勢.
由於GPL嚴格要求使用了GPL類庫的軟件產品必須使用GPL協議,對於使用GPL協議的開源代碼,商業軟件或者對代碼有保密要求的部門就不適合集成/採用作為類庫和二次開發的基礎.
最常見的開源協議,使用它作為授權協議的有大名鼎鼎的 Linux .GPL最顯著的兩個特點就是網上稱為的“病毒性傳播”和“不允許閉源的商業發佈”.
所謂的“病毒性傳播”,指的是,GPL規定,所有從GPL協議授權的源碼衍生出來的(即上面提到的Derivative Module),或者要跟GPL授權的源碼混著用的Project,都要遵循GPL協議,就像病毒一樣,粘上了關係,就“中毒”了.GPL這樣規定的目的是,保證在GPL協議保護下的產品,不會再受到其他協議或者授權的約束.即讓跟GPL有關係的源碼都能免費獲取.舉個例子,如果你的改進的Linux中使用了GPL授權下的開源模塊(也必須使用,你不可能自己重新去做個內核吧,如果做出來了,你也沒必要叫Linux了.),那麼你整個Linux產品也必須遵循GPL協議去開源,不能以其他方式去開源發佈,更不允許閉源發佈.這樣一來,就不會出現這樣一個Linux--這個功能是GPL協議授權的,可以免費獲取源碼,而另外一個功能是其他協議下的,拿不到源碼.這點規定對使用或者研究該產品的人來說,是一個極大的便利.
而“不允許閉源商業發佈”指的是,在GPL授權下,你的軟件產品可以商業發佈,拿去賣錢,但是在這同時,你也必須將該產品的源碼以GPL協議方式開源發佈出去,供他人免費獲取.也許有人會迷惑,拿去賣,又同時開源,那誰來買阿?這個產品怎麼賺錢呢??這就涉及到開源產品的商業模式的問題了,想了解相關一些信息的話,可以看看以上我給出鏈接的一些文章.至於後面,可能會寫一篇關於開源項目的商業模式的隨筆.
GPL協議下的商業發佈的一個關鍵點就像 Java 視線論壇的 Robbin所說的,GPL是針對軟件源代碼的版權,而不是針對軟件編譯後二進制版本的版權.你有權免費獲得軟件的源代碼,但是你沒有權力免費獲得軟件的二進制發行版本.GP對軟件發行版本唯一的限制就是:你的發行版本必須把完整的源代碼一同提供.
它細節如再發布的時候需要伴隨GPL協議等和BSD/Apache等類似.
LGPL
LGPL是GPL的一個為主要為類庫使用設計的開源協議.和GPL要求任何使用/修改/衍生之GPL類庫的的軟件必須採用GPL協議不同. LGPL允許商業軟件通過類庫引用(link)方式使用LGPL類庫而不需要開源商業軟件的代碼.這使得采用LGPL協議的開源代碼可以被商業軟件作為類庫引用併發布和銷售.
但是如果修改LGPL協議的代碼或者衍生,則所有修改的代碼,涉及修改部分的額外代碼和衍生的代碼都必須採用LGPL協議.因此LGPL協議的開源代碼很適合作為第三方類庫被商業軟件引用,但不適合希望以LGPL協議代碼為基礎,通過修改和衍生的方式做二次開發的商業軟件採用.
GPL/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協議下,你可以將源碼不做任何修改來商業發佈.但如果你要將修改後的源碼其開源,而且當你再發布的是Object Code的時候,你必須聲明它的Source Code 是可以獲取的,而且要告知獲取方法.
3. 當你需要將CPL下的源碼作為一部分跟其他私有的源碼混和著成為一個 Project 發佈的時候,你可以將整個Project/Product 以私人的協議發佈,但要聲明哪一部分代碼是CPL下的,而且聲明那部分代碼繼續遵循CPL.
4. 獨立的模塊(Separate Module),不需要開源.
MIT
MIT是和BSD一樣寬範的許可協議,作者只想保留版權,而無任何其他了限制.也就是說,你必須在你的發行版裡包含原許可協議的聲明,無論你是以二進制發佈的還是以源代碼發佈的.
閱讀更多 銀行小馬農的日常 的文章
