常用的一些開源協定的詳細解析
2007-03-22 19:16作者：出處：論壇整理責任編輯：webbtob
相關專題：GPLv3引發廣泛争議-開源面臨分裂危機
開源在今天的軟體業已經很普遍，但開源是否意味着使用者可以對開源後的代碼為所欲為呢?答案是否定的。開源運動同樣有自己的遊戲規則和道德準則。不遵行這些規則不但損害開源運動的健康發展，也會對違規者造成名譽和市場上的損失，更可能陷入法律糾紛和賠償。
首先，要對幾個概念有所了解：
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準許的協定。如果要開源自己的代碼，最好也是選擇這些被準許的開源協定。
這裡我們來看四種最常用的開源協定及它們的适用範圍，供那些準備開源或者使用開源産品的開發人員/廠家參考。
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)，不需要開源
您的位置:
Linux時代
>
新聞資訊
>
Google開源“掌門”:如何管理開源代碼
日期：2007-05-28 作者：IT168 來自：linux.chinaunix.net
-->
Google開源項目經理Chris DiBona在Google紐約系列演講活動中發表了一場演講，題目為“Google開源的一年（A
Year of Open Source at
Google）”。在他演講之前，這個Google開源掌門接受了媒體的采訪，談論對開源的一系列問題的看法，諸如微軟最近發表開源侵犯專利權的事件、
Google的開源開發貢獻，以及GPLv3對Google的影響等等，以下是訪談内容。
screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt=\'Click here to open new window\nCTRL Mouse wheel to zoom in/out\';}" onmouseover="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor=\'hand\'; this.alt=\'Click here to open new window\nCTRL Mouse wheel to zoom in/out\';}" onclick="if(!this.resized) {return true;} else {window.open(\'http://linux.chinaunix.net/mirror/image.it168.com/cms/2007-5-25/Image/2007525164351.jpg\');}" onmousewheel="return imgzoom(this);" alt="" />
Google開源項目經理：Chris DiBona
Google是如何使用開源軟體的？
記者：你在Google紐約系列演講活動中将演講什麼内容？
Dibona：我
将對我的觀點進行進一步的闡述，内容包括關于Google是如何使用開源技術、我們内部如何關注開源，還有我們所展現給外界的一些回報開源社群的活動，諸
如Google Summer of Code開源項目夏令營，我們以後将公開許多源代碼到開源社群中。我将圍繞這些問題進行讨論。
記者：你能談一下在Google公司用于軟體開發的開源元件嗎？
Dibona：我講演的内容之一就是關于我們所修正的一些開源項目，我們公司内部正在使用它們。這些包括諸如Linux核心、GNU編譯器集、Python、Wine、Derby、Aspell、DSpace、Autoconf、MySQL等類似的東西。
記者：請談一下在Google用于生産或部署的開源軟體的情況。
Dibona：我們使用Linux核心。每次你使用Google的時候，你都使用了Google的一台安裝了Linux的機器。我們在其上運作了一些常見的開源工具，在其上我們運作了專有軟體來支援Google、Gmail和所有其他不同的服務。
記者：你提到的常用工具都是什麼？
Dibona：像GNU binutils、如OpenSSL、OpenSSH、某些網絡監視工具，一般是作業系統級别的工具。
Google Code項目進行如何？
記者：請問你參與了Google Code項目嗎？
Dibona：是的，這是我們部門管理的網站之一。
記者：Google Code項目進行如何？有什麼方法來評測進展情況嗎？
Dibona： Google Code有兩個方面對我們是非常重要的。其中一個是我們在其上放置了很多與Google無關的開源項目。這樣我們成為繼SourceForge後的第二大開源項目網站。這真的非常有意義。
另一件事情是，我們在其上放置了很多我們的應用程式程式設計接口API的文檔。這使得Google以外的開發者和程式員可以從技術上更深入了解Google，
以及更加清楚他們的程式如何從技術上與Google實作互動，這一方面已經做得非常成功，對于它的進展我們感到非常滿意。
Google Summer of Code項目
記者：在你看來， Google Summer of Code項目所帶來的影響是什麼？
Dibona：SoC所帶來的影響中有兩個是最重要的，第一個是我們為2000名開發者約定了時間和地點來進行一次聚會交流。今年将有1000名開發者參加，去年是600名，而前年是400名。是以，總體來說，我們介紹了2000名開發者到開源軟體開發者中來。
另一方面，通過這些開源項目，以及通過這種方式将更多的機會帶到學生群體當中，這些開源項目現在已經非常容易接受新開發者的加入。是以如果你對比一下今天
和三年前的這些項目的話，你會發現它們現在對沒有經驗的新手具有更大的吸引力和接納力。我認為這對開源軟體來說是一件非常強大和有益處的事情。是以從這兩
方面來說，這個項目是非常成功的。
記者：這也是我希望看到的事情，幫助把更多對計算機科學感興趣的人帶入到開源軟體的世界中來。
Dibona：對，
如果你認真想一下，在開源世界中有很多偉大的軟體，但是讓一個年輕人從一個開源使用者轉變成一個開源開發者并不是一件輕松的事情。因為他們的代碼突然被外界
的每一個人看到，他們不得不與自己的職業技能可能相差很遠人來進行交流。我認為，Google Summer of Code是一個非常有用的方式。
Google給開源社群回報了什麼？
記者：對于Google回報了多少開源軟體給社群，你有什麼資料嗎？
Dibona：我
們已經将我們的一百萬行代碼回報給開源社群。這是評測我們對開源社群共享的一個方法。這是一個非常不錯的數字，它是令人印象深刻的，不是嗎？但是我認為還
有更重要的，假若你看一下每一個主流的開源軟體項目，還有很多相對較小的開源項目，你會發現Google或者對其進行了修補，或者釋出新的功能，或者釋出
了其代碼，或者參與了這些項目。
一個很好的例子是我們最近剛剛釋出的一些讓人們更好的使用MySQL的工具。是以這些都是非常有意義的事情。我們已經釋出了各種各樣的工具，從一些難以讓
人注意的微小修改到讓人難以相信的大的事情，例如Google
Web工具集就是完全開源的。是以我們認為，作為一個公司與外界分享我們的創新成果，這是一個非常好的道路。
記者：有什麼Google技術正在變為開源嗎？
Dibona：你知道，我們從來不讨論我們還沒有釋出的事情。順便說一下，我們不這麼做的理由是我們喜歡确信當我們釋出某個消息或項目的時候，它已經完成了釋出的準備工作。不過可以告訴你，我們将努力在5月31日的Google開發者日推出一些有趣的東西。
GPLv3對Google有什麼影響嗎？
記者：GPLv3對Google有什麼影響嗎？
Dibona：如果你是在9個月前問我這個問題，我會說它意味着我們将不能夠采用一些GPL 3程式，這是因為在最初版中的一些ASP規定限制。不過，那時候我說過，也是我現在想說的，那不是世界末日。我們不用必須使用外界的每一個開源軟體。
但是最近的GPLv3已經去掉了那些規定，是以我們可以很輕松地說，我們歡迎采用GPLv3。
然而在以前，假若人們選擇在開源軟體中加入那種限制，我們隻有在産品中不使用它而且不能使它公開給終端使用者。
是以，無論它們基于什麼規定，對我們來說都無所謂，因為我們非常善于管理進入到公司中的代碼。是以這實際上從來不是一個真正的問題。
最新版的GPLv3實際上是非常不錯的。
微軟的“專利侵權”論和Java開源
記者：對于微軟最近聲稱的開源軟體侵犯了其大量專利的說法，你有什麼看法？
Dibona：是的，我們也看到了這件事情。和大多數人一樣，我們更希望看到微軟能真正列舉出哪些專利權被侵犯。這個事情還要進一步觀察。抛出這樣的說法是一件很容易的事情，而是否有進一步的具體行動是另一回事。
記者：Sun的開源Java舉動會對Google産生一定影響嗎？比如Google會考慮将Java看作一個開發平台？
Dibona：這
不會改變我們對Sun和Java的看法，但是這可能會增加我們對一些Java工具的使用。在Sun作為GPL釋出Java以前，我們就已經與它們簽訂了源
代碼合作協定。按照這個協定，我們能夠給它們提供更新檔、漏洞和所有其他事情，因為我們擁有很進階的Java開發技術。我們擁有像Joshua
Bloch這樣的著名Java開發者，他對Java社群中占有舉足輕重的地位。
是以，我們一直可以獲得更新檔和一些開發的功能，這對于我們是非常不錯的。不過對于Java的開源，在很多方面對我們是很有利的，因為我們可以通過以前不可
能的方式來通路某些特定的代碼部分。我們可以修正它們，并且可以很簡單地送出這些修正更新檔。我們可以說，這是一個開源項目，是以我們可以釋出這些内容。對
我們來說這是一種難以讓人相信的解脫。是以我們很高興看到Java走向GPL。
Google如何管理開源代碼？
記者：你是否對你們的代碼進行過類似Black Duck或Palamida的軟體相容測試？
Dibona：沒有，原因是我們對進入公司的代碼實行了非常嚴密的控制。而且我們非常非常善于教育訓練我們的工程師。這麼和你說吧，我可以檢視公司内的任何代碼，而且我能告訴你在其中使用了什麼開源軟體，這是因為我們管理代碼的方式非常完善。
是以這類工具在收購過程中非常有趣，而我們通常不談論關于收購中的具體細節，它們不會引起我們内部的興趣。我也認為這些代碼工具會比較有用。現在我還不能确信它們對我們會多麼有用。但是，它們是非常好的項目。
記者：既然你說你們有一些專有代碼運作在由開源元件構成的組合之上，我比較好奇你們如何厘清哪些是開源哪些是專有代碼？
Dibona：值得指出的是，這就像你在Linux上運作一個應用程式一樣。按照同樣的方式，我們挑選用來運作我們的Web伺服器和我們的Web應用程式。而且我們将Linux做一個核心和一個底層的作業系統。
當我們使用一個開源庫的時候，我們将代碼納入公司的方式是嚴格控制的。Google公司有很多紀律來規範代碼的進入。
明确的說，當建立了一些代碼并将其送出，在其進入代碼庫前，另一個Google人員會對你的代碼進行代碼審查，假若一個人突然出來送出了25000行代
碼，那麼這可能是值得懷疑的。我們有很多方法來有效地處理這種事情。我們告訴人們你需要将代碼歸入一個目錄，你需要明确的标記代碼，以便我們更能跟蹤分析
它們。是以我們在管理代碼進入方面是非常容易做到的。
——————————————————————————————————————————————————
開源的商業模式設想(2008-08-31 08:25:02)
| 标簽：評賽觀賽 網際網路 開源軟體 開源項目 商業軟體 it | 分類：屎人挨踢 |
當代，網絡把我們每個人連在了一起，越來越多的人融入到網絡這個社會。隻要用電腦，就開始參與進這個虛拟社會，即使是最不參與的人，那些潛水者，即時通訊的隐身者，他們也會偶爾聊聊天，偶爾回篇貼，偶爾在網上打打遊戲。虛拟和現實，也許每個人在其中的地位會有很大的反差，但是我想虛拟和現實社會中的主流是一樣的，都喜歡地位和榮耀，光榮和夢想。兩個世界，邊緣、另類的人也都同樣有，也許現實中被人輕賤，在網上被人追捧，現實中被人追捧，也許就是要在網上嘗試被人罵的滋味；現實中沒有屬于自己一耦之地的人，也許在網上沉迷于自己經營的帝國，現實中的富可敵國，也許在網上津津有味的擺弄着自己一分分賺回來的家當。我們就這樣在幻夢和現實之間遊走，繁累後的放松，昏天昏地後的警醒，宛如隔世。我們總是想去體會和自己現在不一樣的生活，現實中對未來的擔心和很多無奈，我們寄托在網上，看着别人，看着自己，看着很多人的故事，我們就象身處于其中。
又扯遠了，還是回到開源怎麼能維持并賺錢上來吧。開源，我想精心寫出那一行行代碼的人，不是被人強迫所為，不是為了老闆打工，被逼着限期交出去。也許和我一樣，心裡面有點屎不拉出來的話，就很不爽，如坐針氈，不得安甯，一旦把想法慢慢的吐出來就消停了，并且流連于自己拉的屎感覺快樂。我想那些程式員也是類似這樣，過後看自己的一行行代碼，也覺得很舒服。是以這些開源的人，我想他們對自己拉的是否能帶來金錢要求并不高，也許和我一樣，希望有一種認同感，就是希望别人用的時候，能引用一下出處，在開源項目的發展日志中能夠提到他，不需要現實中的名字，網上社群的id就足夠了。就象我幻想的一樣，如果突然有一天有人要給俺稿費，那簡直就是天上掉餡餅一般，管他多少錢，都會讓人很高興。會不會有餡餅掉俺身上先不管，還是設想一下怎麼讓這些無私的程式員有餡餅掉在身上再說，畢竟俺拉的，讀完就該扔進垃圾堆，而那些程式員做的東西是我們實實在在能夠用的軟體。
俺用過Linux，近10年前摸過一段時間，圖形界面和硬體支援那時候非常得不友善，後來就沒接觸過了，最近幾個月下載下傳最新的某個發行版，發覺和10年前反差太大了。進步太快了，線上更新，軟體子產品間的關聯，硬體的支援，使用得非常友善，特别是裝在移動硬碟上，在多台機器上啟動都沒有問題，并且不同機器的硬體估計在啟動中就檢測并把驅動裝上了，直接就可以進入圖形界面，聯網使用，簡直自己的工作環境可以揣兜随身帶了，軟體這麼多，還讓我能夠免費的用，真是讓人感慨！不知道那些程式員的生活狀态，希望能有穩定的生活來源，在自己的業餘時間做着這些事。
後來慢慢的又了解一些開源，發現有一批專職做開源的人，不為别的，就是為了開源的推廣，一個開源項目，有公司給小小的贊助，對他們都是一個龐大的支援。希望開源所出的東西，能給為開源做出貢獻的人帶來收入。開源的宗旨是free，智慧自由的交流，代碼自由的交流，如果還有什麼可以加的，我希望加上快樂和責任，我們智慧的閃光讓我們沖動，我們用手指慢慢的把想法用代碼實作，反複的玩味，為我們帶來快樂，程式員是為了快樂去程式設計，不是為了金錢，出的東西對别人有用，不斷的更新，加入新的功能，都是源于對别人的負責。
這樣的一群人，由于沒有穩定的收益，實力龐大的一些閉源公司的拉攏，有一些人慢慢的玷污了開源的純淨性，慢慢的把一些項目後繼的發展變成了閉源，或者本身就為了自己的私利，慢慢的不再開放。不斷的有人遠離開源，不斷的又有人加入。這樣的流轉都是因為一個最現實的問題--錢。為了生活，我們面臨着誘惑總是放棄了理想，如果有那麼一個友善的途徑讓我們能夠支援開源，不知道那麼多使用開源成果的并享受的是否願意提供支援。不知是否有人看過我前面的那篇‘關于軟體盜版問題的一些思考’，下面讓我繼續發揮一下，嘗試設想一下開源的商業模式。
在我看來，軟體這樣的東西，我們買來隻是使用。我們現實中買的東西，比如汽車，開始有個一次性投資，後來使用的時候，我們要加油，也要花錢，對于現在很多商業軟體，都是一次性買個許可證，以後軟體的打更新檔和更新有專門的網站維護，一般都是免費的。對于這樣的收費模式，如果把一次性的投資分成兩塊的話，我想軟體賣的不會那麼貴。比如商業作業系統，買個許可證，從開始使用的那一天開始贈送一年的免費更新，1年過去後，再使用的時候，B伺服器驗證的時候會提醒需要交錢延續更新打更新檔服務了，使用者可以通過門戶網站A交錢延續更新服務時限。如果不交的話，總是彈出視窗提醒夠煩的，這樣分開付費，我想更新的錢也不會很貴。
對于商業軟體，有個先期的許可證投資，對于開源軟體，這部分投資就可以省掉了。對于開源作業系統，比如Linux，各個不同的發行版本可以做一個門戶網站A，如果資金不足，至少大家可以合在一起整個一個門戶網站A，貨架上擺着很多開源閉源軟體，對于驗證網站B，開源軟體的驗證不需要商業軟體那樣的許可證之類的，是以完全可以省掉。安裝某個開源軟體的時候，統一的網絡接口連到A，輸入自己在A上的通行證，通行證下就表明在使用這個開源軟體。不同人用的軟體自己選擇是否讓别人看到，這樣用同一個軟體的人很容易标示成一個群體，大家交流提問會很友善。用的不爽的話，完全可以删掉，覺得用得好的話，可以通過A上的付款機制買一段時間的更新服務。當然這些都不是強制，比如試用和沒付錢買服務時，某許可證下該軟體的标示就是灰的，買了服務就是彩色的，并且買的期限也可以顯示出來。擺在門戶網站A的貨架上的軟體，就對應一個開源項目，使用者付的錢直接進入該項目賬戶，項目組織者自由支配，分給對該項目有貢獻的一些人，對于Linux的各個發行版本，各版本在門戶網站上的收益，可以拿出一部分給Linux核心開發團隊，同樣，一些開源軟體，如果用到别的項目做的底層的支援，也有義務把收益的一部分分給相關的項目，這樣對于不能上貨架的底層支援項目，也會有相對穩定的收入。
有了A，B兩個伺服器，有很多好處：
1、商業軟體的B驗證伺服器，有多少人在使用軟體，時段分布等都可以很容易統計，對于開源軟體，在A上就實作了統計。
2、能上貨架的軟體經過廣大開源參與者反複檢驗過代碼，要能讓人放心使用，門戶網站做好了，參與的人多，會有很好的廣告收入。
3、商業軟體更新服務過期了會經常彈出來提醒，開源軟體沒必要這樣，使用自由，覺得好就開心地給錢，收獲的也象掉餡餅那麼開心。
4、讓願意支援開源的使用者有一個友善可信的管道，真正的把支援給到自己喜歡的開源軟體項目裡。
5、軟體編寫者有經常掉餡餅的收益，不會在軟體中插入廣告的形式維持生活，大家自由使用，自由選擇，如果編的軟體好，自然很多人付錢支援，如果插入廣告，估計是自尋死路。
6、對開源項目，一個好的口碑非常重要，如果走向閉源，也許以後的支援一夜之間就不會再有，對于維持開源隊伍的穩定和純淨很有好處；當然，如果閉源後軟體做的也越來越好的話，可以把它擺在閉源的貨架上，不過對于能上貨架的閉源軟體，估計會有比開源更高的要求。
在沒有穩定收入的時候，開源者都可以本着負責的态度不斷的為别人服務，我想經常有餡餅掉在身上，别人對自己的那種認可和期盼，更讓人有動力快樂的工作。
