從Java開源說起

作者 Sun 中國技術社群的進階經理蔣清野

Java終于開源了，采用GPLv2授權協定。

Java開源的最終方案和時間表，我是在10月初的時候拿到的。從那個時候起我就深深的體會到保守一個自己非常希望公開的秘密真是一件非常難受的事情，哪怕時間隻有短短的一個月。Sun 公司的官方消息是11月13日（美國時間）釋出的，但是在11月12日（也就是中國的11月13日）的時候，網際網路上相關的新聞報道已經可以用鋪天蓋地來形容了。我在水木社群上看到一些認識的抑或是不認識的ID興奮地在Java, ITExpress還有LinuxDev等版面釋出相關的新聞和評論，心裡滿是抑制不住的歡喜。

這一篇文章，想要表達的是我個人對于Java開源，以及Sun 公司的開放源代碼運動的一些想法，不代表Sun 公司的觀點。

Java 為什麼要開源？對于這個問題，很大一部分人的觀點是Sun 公司終于抵擋不住開源社群和Java社群的種種壓力，最終被迫開放Java虛拟機和編譯器的源代碼。持這種觀點的人們可能沒有意識到，在2005年6 月14日之前，Sun 公司對開源社群貢獻的代碼量僅次于加州大學伯克利分校。例如說在我們非常熟悉的Apache, Mozilla, Gnome, OpenOffice等等項目裡面，就有大量Sun 公司貢獻的代碼。2005年6 月14日，Sun 公司在CDDL授權協定下開放了Solaris作業系統的源代碼，從此成為對開源社群貢獻代碼量最大的實體。除了開放軟體産品的源代碼之外，Sun 公司還大膽地開放其核心硬體SPARC處理器 －－ 包括2005年11月剛剛釋出的8 核心32線程UltraSPARC T1處理器 －－的全部設計檔案，使得其他廠商能夠生産和銷售UltraSPARC T1以及經過改進的SPARC處理器。平心而論，不管是在軟體開源還是在硬體開源領域，Sun 公司都不是第一個進行嘗試的廠商，例如說IBM 公司早在2004年就有限度的開放Power構架技術，并且成立Power.org來為主要合作夥伴提供基于Power構架的處理器開發支援和應用開發支援。然而，在這場轟轟烈烈的開放源代碼運動中，Sun 公司毫無疑問的是開放得最徹底的一個，從處理器（UltraSPARC T1）到作業系統（OpenSolaris），從內建開發工具（NetBeans）到應用軟體（OpenOffice），無一例外。是以，公衆的壓力固然是促使Sun 公司開放Java虛拟機和編譯器源代碼的原因之一，但是即使這些壓力有所減輕甚至是不複存在，Java的開源也早就在Sun 公司的藍圖之中。2005年3 月的時候Sun 公司以JRL授權協定（Java Research License, Java研究授權協定）在java.net上公開 －－ 注意是公開，不是開放 －－ 了JDK 5.0的全部源代碼，可以認為是Sun 公司在Java開源之路上的一個重要環節。

那麼，Sun 公司究竟為什麼要開放Java虛拟機編譯器和的源代碼呢？進一步說，Sun 公司為何要徹底地進行自己的開放源代碼運動，将自己在軟體和硬體領域多年的積累拱手送給公衆呢？這到底是“自由、平等、共享、創新、互助、團結”的開源精神，還是在自己走向毀滅之前試圖讓對手将來也無法立足之垂死掙紮？

我曾經不止一次地在論壇上看到這樣的言論：“真是羨慕國外的程式員，他們有優越的收入和充足的時間，絲毫不用擔心住房和醫療等等讓人頭疼的問題，是以能夠利用大量的業餘時間編寫和維護開放源代碼軟體。國内的程式員連生存下去都是問題，怎麼可能給開放源代碼運動作貢獻呢？”不可否認，這世界上的确存在大量具有崇高精神的利用業餘時間編寫和維護開放源代碼軟體的程式員，不過我們隻要粗略地閱讀一下Linux、Eclipse、Apache、OpenOffice等等‌軟體的源代碼開頭的注釋部分，就知道這些開源軟體的作者之中的大多數，仍然在為住房和醫療問題而勞心煩惱，而他們給開放源代碼運動所作出來的貢獻，大部分是在他們的正常上班時間作出的。很顯然，對于這些作者來說，編寫和維護開放源代碼軟體是他們的工作而不是他們個人的崇高愛好，他們所在的公司為他們編寫和維護開放源代碼的工作支付酬勞 －－在這個數不勝數的公司名單上有IBM，有RedHat，有Novell，當然也有Sun 。可以這麼說，這些商業公司參與和推進開放源代碼運動的動機基本上是一緻的，所不同的隻是他們參與和推進開放源代碼運動的方式，以及開源與不開源之間的尺度把握。

商業公司參與和推進開放源代碼運動的方式，大體上可以分為如下幾種。

1.将公司已經不再使用并且保密價值不大的源代碼捐獻給開源社群，不再維護，也不為其他願意繼續維護這些源代碼其他公司或者個人提供技術支援，這種方式我們可以稱之為“抛棄型開放源代碼”。在開源社群中存在大量的抛棄型開放源代碼項目，其主要表現形式為項目長期沒有更新，沒有缺陷報告和更新檔釋出，沒有論壇或者是郵件清單活動，發給項目負責人的電子郵件通常來說有如泥牛入海。著名的開源社群sourceforge.net之是以被稱為世界上最大的“恐龍停車場”，其原因之一就是這個社群“寄放”了大量不再活躍的抛棄型開放源代碼項目。由于很少有人會注意到某個公司的某個開源項目是否為抛棄型開放源代碼項目，是以有相當數量的公司将這種方式作為改變公司形象的一種有效手段，不定期地向開源社群貢獻一些侏羅紀的代碼。

2.将能夠直接地為公司帶來盈利的産品和技術開放源代碼，但是通過授權許可（最常見的形式是雙授權許可）來保護公司的盈利。采取這種方式開放源代碼的公司并不鼓勵開源社群對該産品和技術本身進行改進，但是鼓勵開源社群在該産品和技術的基礎上開發可商業化的應用。例如QT，對于開發人員來說是完全開放和免費的，但是基于QT的應用要商業話的話，就必須向TrollTech公司交納一定數量的授權費用。這種形式能夠有效地擴大該産品或者是技術的市場占有率，并且有效地阻止了競争對手利用開放的代碼提高其競争能力，但是也必須直面未授權商業化應用所帶來的利潤損失。

3.将能夠間接地為公司帶來盈利的産品和技術開放源代碼，鼓勵開源社群對該産品和技術本身進行改進，但是通過研發經費、人工投入、授權許可等多種方式來保護公司對該産品和技術的控制權。由IBM 控制的Eclipse項目和由Sun 公司控制的OpenSolaris項目，可以說是這種開源方式的傑出代表。

4.針對為競争對手帶來盈利和産品和技術另起爐竈開發一個開放源代碼項目，通過研發經費和人工投入鼓勵開源社群對該産品和技術本身進行改進，并且在自己的商業應用中使用該産品和技術。舉個例子，今年11月1 日摩托羅拉宣布要成立一個開放源代碼的Java ME社群，這對于Sun 公司的Java ME商業授權來說毫無疑問是個強勁的威脅。

從如上幾種方式不難看到商業公司參與和推進開放源代碼運動的動機所在，那就是提高企業形象，擴大市場佔有率，打擊競争對手。

有的人就會問了：既然開放源代碼有這麼多好處，為啥這些公司沒有向Sun 這樣把自己的核心技術全都開放源代碼了呢？因為開放源代碼就向是一把雙刃劍，機遇與風險總是同時存在的。下面列出的是幾個在開放源代碼運動中常見的風險。

1. 法律風險。這個風險至少包括兩個方面，一個是被開放的源代碼的所有權問題，也就是說源代碼的原作者是否同意公司開放其編寫和維護的源代碼；另外一個源代碼所涉及到的專利權問題，也就是說源代碼中所使用到的專利技術有可能給沒有被授權使用這些專利技術的使用者造成法律問題。對于前者來說，大部分公司的做法是花費大量的人力和物力來征得原作者的同意将其代碼開源，對于未征得同意的部分源代碼需要尋找開放源代碼的替代方案或者是重寫甚至是将該功能徹底剔除。對于後者來說，有的公司會選擇聽之任之将法律責任推給使用開源技術的開發商，但是有的公司則會設法為使用開源技術的開發商提供保護傘 －－例如說，在CDDL授權協定架構之下，Sun 公司承諾為使用OpenSolaris技術的廠商提供法律保護，使用Sun 公司的資金為廠商解決在使用OpenSolaris當中涉及的法律問題。

2.競争風險。選擇将某個産品和技術開放源代碼，也就選擇了将自己的優點和缺點全部暴露在競争者無比挑剔的眼光之下。然而這還不是最可怕的，最可怕的是競争對手直接使用你的産品和技術去搶占原本屬于你的市場。例如說，今年10月30日的時候Oracle宣布推出Unbreakable Linux，正式加入Linux市場搶奪戰 －－ Unbreakable Linux基于RedHat Linux的源代碼，但是去掉了RedHat的Logo，同時加上了Oracle的Logo。還記得Oracle的總裁Larry Ellison在被問及是否會考慮收購RedHat的時候是怎麼說的嗎？他的回答是Oracle不會收購一家随時都有可能被淘汰的公司。

3. 技術分化。選擇了某個産品和技術開放源代碼，也就選擇了讓競争對手參與到該開源項目的開發與維護當中來，進而出現多個版本互不相容的實作。一個很實在的問題就是，Java語言開源之後，會不會出現多個互不相容的Java虛拟機實作，進而導緻Java語言的“一次編寫，随處運作”特性成為一句空話？ Eclipse基金會是不是會将AWT／SWING的競争技術SWT 內建到Eclipse基金會釋出的Java虛拟機裡面去？

Java開源還是不開源？在回答這個問題之前，還是讓我們來看看Java語言和Sun 公司所面臨的挑戰吧。

1.Java語言是“前人種樹後人乘涼”的一個典型範例 －－ Sun 公司發明、發展和維護了Java語言，但是從Java語言當中獲利最大的卻是IBM 和BEA 。

2. 在Java程式員與C/C++程式員的比例接近1：1的今天，Java語言遭遇到了開放源代碼陣營的頑強抵抗。這種抵抗展現在Linux 廠商拒絕在Linux 發行版中內建基于Java語言的應用程式，而抵抗的理由非常的簡單，那就是除非獲得Sun 公司的授權Linux 廠商不允許在其Linux發行版中捆綁Java運作環境（Java Runtime Environment, JRE） －－ 既然連JRE 都沒有，當然就沒有基于Java的應用程式。前兩天在水木社群的ITExpress 版有一些關于為何Gnome 上面有很多軟體是基于MONO而不是基于Java的讨論，Suzhe的觀點是Java調用外部函數比較困難，不能夠很好地利用現有的庫資源，然而從更高的層次來說，Java的授權模式才是Java無法在開源陣營得到推廣的結症所在。舉個例子來說，2005年的時候我跟國内的兩家小有名氣的Linux廠商商談将JRE捆綁（OEM）到他們的Linux發行版當中去，這本來是郎有情妹有意兩廂情願的事情，結果卻在公司的律師們那裡石沉大海。現在Java語言都已經開源了，我一年前遞上去的授權申請還連個響都沒有聽到 －－ 這裡面的主要原因，是在當時的JRE授權模式下，很難向某個Linux廠商提供OEM 授權。基于類似的原因，在BSD 陣營裡Java技術的推廣也沒有太大的進展，甚至給人一種Sun 公司敵視BSD 陣營的印象。

3.經過多年的發展，市面上已經出現了多種開源和不開源的Java虛拟機和編譯器實作，與Sun 公司提供的Java SDK相競争 －－不開源的虛拟機包括IBM 的JDK和BEA 的JRocket，開源的虛拟機包括Kaffe和Apache Harmony。由于這些開源虛拟機在授權許可方面對Linux 廠商相對友好，是以得到了衆多Linux 廠商的廣泛支援。這也意味着（1）如果聽任這些開源的虛拟機項目繼續發展，Sun 将在Linux 陣營上失去原本就來之不易的市場佔有率；（2）競争廠商必然會将與Sun 公司相競争的技術內建到開源的虛拟機項目中，進而導緻Java技術的分化，使得Sun 公司失去對Java技術的控制權。如果Sun 公司主動将自己的Java虛拟機和編譯器開源，就可以利用自身在該領域的強大号召力弱化其他開源項目的吸引力，進而達到保護自身的目的。

4. 作為世界上對開源社群貢獻代碼量最多的實體，Sun 公司已經從開放源代碼運動裡面嘗到了甜頭。例如2005年6 月Sun 公司開放Solaris作業系統源代碼之後，開發者對Solaris作業系統的興趣大為上升，在短短的幾個月時間内，從Sun 公司網站上下載下傳Solaris 作業系統的總份數就迅速超過以往所有下載下傳份數的總和（過去Solaris作業系統也是可以免費下載下傳的）。來自開發者的熱情直接導緻了Solaris作業系統市場占有率的增長，例如在2006财政年度（2005年7 月1 日到2006年6 月30日）間Sun 公司來自Solaris OEM授權的收入達到了預期的124％。2006年第二季度Sun 公司來自伺服器銷售的營收為16億美元，比去年同期增長14％。這種财務上的強勁長勢驗證了Sun 公司高層在各種場合不斷重複的一句話：“從長遠來看，我們也不知道開源到底會給Sun 公司帶來什麼樣的影響。但是從目前的狀況來看，我們每一次開放核心技術的源代碼，都給公司帶來财務上的強勁增長。”

決策層與衆多律師晝夜焚膏推演博弈理論的結果是：采用GPLv2授權協定開放Java虛拟機和編譯器的源代碼。

經過前面的讨論，我想大部分人都會認可Java開源是一件順利成章的事情。不過熟悉Sun 公司開源曆史的人可能會問了：為什麼是GPLv2？為什麼不是CDDL？Sun 公司在開放Solaris作業系統源代碼的時候費盡心思的設計了CDDL授權協定，為什麼在開放Java虛拟機和編譯器源代碼的時候不再使用？在CDDL 剛剛釋出的時候，Sun 公司曾經在多個場合批評GPL 授權協定，認為GPL 授權協定強制要求使用了GPL 代碼的項目進行開源是不公平的，甚至認為GPL 是一個“掠奪性的授權協定”。Java開源使用GPLv2授權協定是不是暗示着Solaris開源使用CDDL授權協定是一個錯誤的選擇？對于這些高層次的問題，Sun 公司軟體部門執行副總裁Rich Green認為他會敞開心懷傾聽任何關于修改Sun 公司開源政策的建議。很顯然，作為對開源社群貢獻代碼量最大的Sun 公司，仍然在不斷地學習和調整開源的技巧和政策。不過，Java采用GPLv2授權協定開源對于Sun 公司來說至少有如下好處：（1）禁止非開源的分叉實作，（2）得到F/OSS社群的支援，（3）與GNU/Linux的授權協定相相容，可以迅速被 Linux社群所接受，（4）通過Sun Contribution Agreement保證了對Java語言的控制權。在Sun 公司公布采用GPLv2授權協定開放Java虛拟機和編譯器源代碼的同一天，IBM 公司未來網際網路技術部門的副總裁Rod Smith認為Sun 公司應該采用Apache授權協定來實作Java開源（因為IBM 公司控制着基于Apache 授權協定的Harmony項目，一個開放源代碼的Java虛拟機實作）。對此Sun 公司首席執行官Jonathan Schwartz毫不客氣地進行了堅決的回擊：“我非常好奇IBM 公司為什麼會反對GPL 授權協定。我真心的盼望他們不會站到開源社群的對立面。”如果不是GPLv2，如果沒有整個GNU/Linux社群作為後盾，Jonathan Schwartz的反應還能夠如此之铿锵有力麼？

Java開源，是Sun 公司的選擇，也是順應潮流的選擇。我真心的希望開源之後的Java一路走好，也希望堅持徹底開源的Sun 公司一路走好。

作者 Sun 中國技術社群的進階經理蔣清野 http://www.newsmth.net/pc/pccon.php?id=6&nid=272944&s=all

1.Java語言是“前人種樹後人乘涼”的一個典型範例 －－ Sun 公司發明、發展和維護

Java語言，但是從Java語言當中獲利最大的卻是IBM 和BEA 。

回顧Java的産生曆史，“一次編譯，到處執行”是那個年代的特有需求。作業系統繁多，

帶來了應用移植的代價問題，這也是為何上面那句話那麼有震撼力。但反過來，我們也

知道沒有各個系統廠商的支援，也不會有這麼個願景的産生。Sun擁有Java的同時也需要

各個系統和應用廠商來支援Java，這對于當時的Java來說是同等重要的貢獻。

說到Sun在Java上的獲利失敗，不得不提的就是當年Netscape倒掉的時候Sun得到了iPlanet

Application Server，當Sun握有當時市場排名第一和第二的産品時，卻逐漸在IBM和BEA

的競争下到今天到達幾乎沒有AppServer的市場，這不能不說自身産品市場定位的問題。

而Sun自身除了Solaris和Java兩個産品，很多應用産品無法占有足夠的市場，有多方面

的原因。一則産品開發無法及時反映市場的變化，二是産品過于集中于基礎平台，沒有

上層商業應用支撐。對于中間件這塊大市場來說，都是很緻命的錯誤。