Java将学习开放源代码的自由创造方式

核心提示：java开放源代码的论战持续延烧，在2004年O´Reilly开放源代码会议中，Java将学习开放源代码的自由创造方式，Sun 电脑公司技术宣导长Simon Phipps再度承认，Java还不够开放，而是软件提供者，若那种现象在Java生态系重现，Phipps说：“我们渴望让Java学习开放源代码软件创造自

　　java开放源代码的论战持续延烧。在2004年O´Reilly开放源代码会议中，Sun 电脑公司技术宣导长Simon Phipps再度承认，Java还不够开放。Phipps说：“我们渴望让Java学习开放源代码软件创造自由的方式。我们正坚定地踏上成为开放源代码社区正式成员的轨道。”
　　
　　Apache网络服务器专案的共同创始人暨Collabnet 的创始人Brian Behlendorf认为，有待克服的挑战，是消除把开放源代码软件以“兼容性”(compatibility )和“弹性”(flexibility )截然二分的作法。
　　
　　Phipps把这种二分法称为两大成功的“自由”阵营：“自由阵营有二：一种是靠保证所提供软件的兼容性来推动，另一种则靠标准化授权来保证其自由。两者都让他人取得自己的源代码。问题是，我们如何能把这两种成功的自由社区结合起来。”
　　
　　此处提及的兼容性，系指Sun 要求凡是以Java程序语言编写的程序，都必须通过一套兼容性测试，才能获得Java社区创制中心(Java Community PRocess ；JCP )的兼容性认证。
　　
　　对企业而言，兼容性人见人爱，想玩弄基础源代码的冲动也比较小。对Sun 而言，向单一规范靠拢的兼容性，可避免源代码发展分歧(code forking )，重蹈Unix阵营分裂成互不兼容解决方案的覆辙。又如新近崛起的linux ，已出现各种大同小异、多多少少兼容的版本，但欠缺Java的跨厂牌兼容保证，Linux 和Unix一样，都因为提供者添加种种专有的装饰套牢终端用户，而牺牲了兼容性。
　　
　　Sun 唯恐IBM 、BEA 或微软公司运用市场势力和雄厚的资源，创造出一种Java的分支，再把它拱成强势的“标准”，让Sun 怀抱的Java理想飞灰烟灭。Sun 的愿景是借Java促成公平竞争的环境，包容多重的平台选择，并且让编写程序的可猜测性提高、成本降低。
　　
　　“问题不是出在开放源代码社区，”Phipps说：“而是出在有些人未顾及社区精神，不经意地把权利授予他人。”
　　
　　但开放源代码发展社区想要的，是能够自由、无负担地取得并修改开放源代码。这两种自由阵营如何统一，仍不得而知。“难就难在细节 ……我们需要一种务实的实现过程(implementation)，”Phipps说。举例来说，Apache软件基金会(ASF )正试着制作一种Java2 企业版(J2EE)服务器，称为“杰罗尼莫”(Geronimo)专案。
　　
　　此专案逼近大功告成和通过认证的阶段，但法律问题却从中作梗。如同该专案下载网站公告的文件所示，“杰罗尼莫”软件在授权之前， ASF 必须出示Sun 的认证发布(certified releases)通知：
　　
　　本授权软件所衍生的任何作品，若要重新发布，都必须具备兼容性，并且印有Sun 指定的和Sun 随后另依商标许可证(Trademark License)授权的适当兼容性标记。这是你和Sun 之间必须执行的步骤。
　　
　　这份Sun 通知的含意，是要求ASF 的J2EE服务器每作一次改变，都必须重新接受兼容性测试。Behlendorf说：“倘若每一项衍生的作品，即使是安装修补程序那么基本的东西，都得逐一接受测试的话，所需的经常费用会高得不可思议。其实偏离标准的风险微乎其微，这应该在弹性与遵从单一规范之间作个妥协。”他接着说：“我们正与Sun 商量，设法从体制内解决问题。我们尚未评估这是不是错误的解决问题之道。”
　　
　　ASF 正试着与Sun 商议如何解决问题，并建议以下列措词修改Sun 通知书的内容：
　　
　　任何宣称与Java(商标)技术规范兼容的声明，只适用于原始的、未经修改的作品。衍生的作品并不承袭兼容性认证，而且或许会受到第三方对兼容性认证及使用相关商标的限制。
　　
　　但监于JBOSS 等未经认证的开放源代码J2EE服务器向来大受欢迎，这种暗示支持源代码分歧的措词可能让Sun 不安，究竟像IBM 这些对开放源代码娴熟的掠夺者仍潜伏在暗处伺机而动。
　　
　　Behlendorf则表示乐观，认为凭开放源代码社区内部的自我约束力，即可预防Java四分五裂。“假如某种技术广为流传使用，又是开放源代码，就不可能成为控制点，”Behlendorf说：“我们不认为会重蹈Unix的覆辙。听起来也许太理想化了，但Linux 一向都是志帽睾稀４蠹一岢?共同的标准聚集。??/p>
　　
　　Behlendorf评估瞬息万变的现况时，可能只从钱的角度来看，却未顾及不兼容性带给企业用户的困扰，也未顾及这些企业要的是明确标准带来的舒适性。法定的标准，例如给Java撑腰的JCP ，赋予企业买方的优势明显超过各种解决方案所能提供的。
　　
　　只因为目前的解决方案太慢、不稳定、不安全或价格高昂，就换用其他的解决方案，做这种决定并不轻易。试想，微软的解决方案即便伴随着种种危险，世人依然深陷其中，无法自拔。最轻易转换的情况，是发生在所有软件都必须遵照某种标准之时。各方争相推出遵循标准的软件，也有助于压低成本。
　　
　　令Behlendorf和其他开放源代码社区人士忧虑的，是创新脚步可能因为兼容性认证测试而减慢。但标示若是货真价实，亦即软件兼容性与标示相符，这种作法也许能提供程序设计师想要的弹性。
　　
　　Linux 或许真的会整合。但基于Linux 可预见的分歧性，Linux 的企业用户不会存有转换版本的幻想。一如红帽公司(Red Hat )恣意修改红帽版Linux 的订价办法，从免费改为收费，还是有众多企业马上签约使用，掌控贵公司信息科技(IT)系统和财务的不是你自己，而是软件提供者。若那种现象在Java生态系重现，可能终会产生同样的后遗症。