開源協議概談

  之前對開源協議沒有什麼清晰的概念，總以為開源就是免費甚至為所欲為。前些天花了一天時間，看了些關於開源協議的資料。

常用開源協議解析

看‘談談open source '有感！

常用開源協議討論

sun 炮轟GPL開源協議

開源協議List

也詳細查閱了一些關於 CPL1.0 的資料： Common Public License (CPL) Frequently asked questions

                                                         Common Public License Version 1.0

                                                         What open source license is OpenLaszlo available under?

算是對開源協議有了大概的瞭解。下面談談我對開源協議的一些粗淺的認識，如有不當之處，請大家指教。

      首先，要對幾個概念有所瞭解：

（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）Derivative Module 和 Separate Module

Derivative Module 指的是，依託或包含“最初的”或者“從別人處擷取的”開原始碼而產生的代碼，是原“原始碼”的增強（不等於增加）、改善和延續的模組，意為“衍生模組”。

Separate Module 指的是，參考或藉助原“原始碼”，開發出的獨立的，不包含、不依賴於原“原始碼模組”，意為“獨立的模組”。

理解這兩個概念的目的在於，很多協議對涉及到商業發布的時候，會有哪些是衍生的，哪些是獨立的，有著明確的商業發布規定。

      接下來，說說常見的幾種協議吧。其實上面我給出的幾篇文章的連結裡面對一些常見的開源協議已經有比較清晰的描述了，我這裡也只是加人了個人的一些理解，希望對接觸得少的人有一定的協助吧。

GPL（Gun General Public License） vesion 2.0  1991

      最常見的開源協議，使用它作為授權協議的有大名鼎鼎的 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是針對軟體原始碼的著作權，而不是針對軟體編譯後二進位版本的著作權。你有權免費獲得軟體的原始碼，但是你沒有權力免費獲得軟體的二進位發行版本。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 Derivative Works a copy of this License）
2． 如果你修改了代碼，需要在被修改的檔案中進行說明。

      （You must cause any modified files to carry prominent notices stating that You changed the files）
3． 在Derivative Module中（修改和包含原始碼而衍生的代碼）需要帶有原來代碼中的協議，商標，專利聲明和其他原來作者規定需要包含的說明。

       （You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works）
4． 如果再發布的產品中包含一個Notice檔案，則在Notice檔案中需要帶有Apache Licence。你可以在Notice中增加自己的許可，但不可以表現為對Apache Licence構成更改。

       （If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.）

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  的 授權。

          （Does the CPL allow me to take the Source Code for a Program licensed under it and include all or part of it in another program licensed under the GNU General Public License (GPL), Berkeley Software Distribution (BSD) license or other Open Source license?
No. Only the owner of software can decide whether and how to license it to others. Contributors to a Program licensed under the CPL understand that source code for the Program will be made available under the terms of the CPL. Unless you are the owner of the software or have received permission from the owner, you are not authorized to apply the terms of another license to the Program by including it in a program licensed under another Open Source license. By the way, the same answer applies if you want to include source code licensed under another Open Source license in a program licensed under the CPL ）

       2.CPL協議下，你可以將源碼不做任何修改來商業發布。但如果你要將修改後的源碼其開源，而且當你再發布的是Object Code 的時候，你必須聲明 它的Source Code 是可以擷取的，而且要告知擷取方法

       （ Can I take a Program licensed under the CPL, compile it without modification, and commercially license the result?
Yes. You may compile a Program licensed under the CPL without modification and commercially license the result in accordance with the terms of the CPL.    Do I need to include the source code for such Program with the object code distribution?
No. But you do need to include a statement that the source code is available from you and information on how to obtain it.   What happens if I make a modification to the platform under the CPL but choose not to distribute it to anyone else?Under the CPL, in this circumstance you do not need to make the source code available to others.  If I modify a Program licensed under the CPL and distribute the object code of the modified Program for free, must I make the source code available?
Yes. By distributing the modified Program, even if it is only a free version of the object code, you are obligated to make the source code to the modified Program available to others. ）             3.當你需要將 CPL 下的源碼作為一部分跟其他私人的源碼混和著成為一個 Project 發布的時候，你可以將整個Project/Product 以私人的協議發布，但要聲明哪一部分代碼是CPL下的，而且聲明那部分代碼繼續遵循CPL。 （ When I incorporate a portion of a Program licensed under the CPL into my own proprietary product distributed in object code form, can I use a single license for the full product, in other words, covering the portion of the Program plus my own code?
Yes. The object code for the product may be distributed under a single license as long as it references the CPL portion and complies, for that portion, with the terms of the CPL.
）       4.獨立的模組（Separate Module），不需要開源

（If I write a module to add to a Program licensed under the CPL and distribute the object code of the module along with the rest of the Program, must I make the source code to my module available in accordance with the terms of the CPL?
No, as long as the module is not a derivative work of the Program.）

      綜上所述，看見我對開源的協議的瞭解也只是達到一個初步的認識。特別是對 CPL 還有著一些困惑。另外我自己一直也覺得 Derivative Module 和 Separate Module 很難有個清晰的界限，在某種程度上總感覺他們有個模稜兩可地段。但既然是有所心得，就先寫下來吧。衷心歡迎大家指正、討論。