从Java开源说起……

　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 公司一路走好。