開源介紹

一、什麼是開源 

          開源（Open Source，開放源碼)被非赢利軟體組織(美國的Open Source Initiative協會)注冊為認證标記，并對其進行了正式的定義，用于描述那些源碼可以被公衆使用的軟體，并且此軟體的使用、修改和發行也不受許可證的限制。

          開放源碼軟體通常是有版權 ( copyright ) 的.它的許可證可能包含這樣一些限制：着意地保護它的開放源碼狀态，著者身份的公告，或者開發的控制。實際上，開源軟體同時涉及源碼本身和開發過程，涵蓋了三個方面的意義：免費分發的源代碼、子產品化的體系和集市式的開發–在這種開發方式中，任何地方的任何人都可以參與最終産品的制造，三個方面互相之間有密切的聯系，集市式的開發過程給開源軟體以強大的改錯能力，因為它将程式中的錯誤公開給了數量巨大的觀衆，他們都是潛在的改錯者。另一方面，任何人都可以複用和發行開源軟體的代碼這一事實又支援了公衆利益，因為創新的觀念被整個集市所共享。另外，”open source”這一術語還被延伸到其他智力團體中，指那些可通過公開手段獲得的智力資源，比如報紙、教學課件等。

        美國一些進步的評論家指出，在象網絡這樣的虛拟環境中，驅動系統的底層代碼，尤其是廣為人知的那些應用程式之間的通信協定，它們在某種意義上很象現實社會中的法規。換句話說，這些代碼對網上的行為給出了一些規範，它鼓勵某些行為，而限制其他行為，就像現實社會的法律一樣。是以，開放源碼帶來了一個更民主的開發方式，在這種方式下，好的主意将被集體分享，而不是作為智力資本被個人秘藏着。在這種意義上，開放源碼實質上成為一種政治哲學。

        開放源碼的精神在于使用者可以使用、複制、散布、研究、改進軟體。最早可以回朔到1960年代。當時，售賣大型計算機的廠商如IBM，把一些軟體及原始碼一并送給客戶，讓客戶能夠因不同需求而自行更改軟體。在 1991-1992 年期間，住在芬蘭的 Linus Torvald制造了第一版的 Linux 作業系統。在一群熱心的程式人員努力下，把 Linux 作業系統以及外圍的應用程式逐一打造。

          出名的作品除了趨于成熟的Linux 作業系統外，還有 Apache網頁伺服器、Perl 程式語言、MySQL 資料庫、Mozilla 浏覽器、OpenOffice等等。

          但是開源在今天的軟體業已經很普遍,但開源是否意味着使用者可以對開源後的代碼為所欲為呢?答案是否定的.開源運動同樣有自己的遊戲規則和道德準則.不遵行這些規則不但損害開源運動的健康發展,也會對違規者造成名譽和市場上的損失,更可能陷入法律糾紛和賠償.

二、開源相關的幾個概念          

　　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、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準許的協定.如果要開源自己的代碼,最好也是選擇這些被準許的開源協定.

　　這裡我們來看四種最常用的開源協定及它們的适用範圍,供那些準備開源或者使用開源産品的開發人員/廠家參考.

　　1.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協定,因為可以完全控制這些第三方的代碼,在必要的時候可以修改或者二次開發.

　 2.Apache Licence 2.0

　　Apache Licence是著名的非盈利開源組織Apache采用的協定.該協定和BSD類似,同樣鼓勵代碼共享和尊重原作者的著作權,同樣允許代碼修改,再釋出(作為開源或商業軟體).需要滿足的條件也和BSD類似:

　　1. 需要給代碼的使用者一份Apache Licence

　　2. 如果你修改了代碼,需要再被修改的檔案中說明.

　　3. 在延伸的代碼中(修改和有源代碼衍生的代碼中)需要帶有原來代碼中的協定,商标,專利聲明和其他原來作者規定需要包含的說明.

　　4. 如果再釋出的産品中包含一個Notice檔案,則在Notice檔案中需要帶有Apache Licence.你可以在Notice中增加自己的許可,但不可以表現為對Apache Licence構成更改.

　　Apache Licence也是對商業應用友好的許可.使用者也可以在需要的時候修改代碼來滿足需要并作為開源或商業産品釋出/銷售.

　 3.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等類似.

　　4.LGPL

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

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

　　GPL/LGPL都保障原作者的知識産權,避免有人利用開源代碼複制并開發類似的産品.

　　5.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),不需要開源.

 6.MIT（MIT）

MIT是和BSD一樣寬範的許可協定,作者隻想保留版權,而無任何其他了限制.也就是說,你必須在你的發行版裡包含原許可協定的聲明,無論你是以二進制釋出的還是以源代碼釋出的.

     7.MPL

MPL是The Mozilla Public License的簡寫，是1998年初Netscape的 Mozilla小組為其開源軟體項目設計的軟體許可證。MPL許可證出現的最重要原因就是，Netscape公司認為GPL許可證沒有很好地平衡開發者對 源代碼的需求和他們利用源代碼獲得的利益。同著名的GPL許可證和BSD許可證相比，MPL在許多權利與義務的約定方面與它們相同（因為都是符合OSIA 認定的開源軟體許可證）。但是，相比而言MPL還有以下幾個顯著的不同之處:

◆ MPL雖然要求對于經MPL許可證釋出的源代碼的修改也要以MPL許可證的方式再許可出來，以保證其他人可以在MPL的條款下共享源代碼。但是，在MPL 許可證中對“釋出”的定義是“以源代碼方式釋出的檔案”，這就意味着MPL允許一個企業在自己已有的源代碼庫上加一個接口，除了接口程式的源代碼以MPL 許可證的形式對外許可外，源代碼庫中的源代碼就可以不用MPL許可證的方式強制對外許可。這些，就為借鑒别人的源代碼用做自己商業軟體開發的行為留了一個 豁口。 

◆ MPL許可證第三條第7款中允許被許可人将經過MPL許可證獲得的源代碼同自己其他類型的代碼混合得到自己的軟體程式。 

◆ 對軟體專利的态度，MPL許可證不像GPL許可證那樣明确表示反對軟體專利，但是卻明确要求源代碼的提供者不能提供已經受專利保護的源代碼（除非他本人是 專利權人，并書面向公衆免費許可這些源代碼），也不能在将這些源代碼以開放源代碼許可證形式許可後再去申請與這些源代碼有關的專利。 

◆ 對源代碼的定義 

而在MPL（1.1版本）許可證中，對源代碼的定義是:“源代碼指的是對作品進行修改最優先擇 取的形式，它包括:所有子產品的所有源程式，加上有關的接口的定義，加上控制可執行作品的安裝和編譯的‘原本’（原文為‘Script’），或者不是與初始 源代碼顯著不同的源代碼就是被源代碼貢獻者選擇的從公共領域可以得到的程式代碼。” 

◆ MPL許可證第3條有專門的一款是關于對源代碼修改進行描述的規定，就是要求所有再釋出者都得有一個專門的檔案就對源代碼程式修改的時間和修改的方式有描述。

總結

                            是否适合商用         修改/衍生代碼是否需公開

BSD                              Y                                N

Apache Licence 2.0       Y                                N

GPL                              N                                Y

LGPL                            Y                                 Y  （适合作為類庫使用）

MIT                              Y                                 N