级别： 中级 Neal Sanche (neal@nsdev.org), Java 开发人员, Pure Technologies
2006 年 3 月 02 日 在 “Geronimo 叛逆者” 专栏的这一部分中，Java™ 和 Microsoft® .NET 开发人员 Neal Sanche 邀请您体验他的梦想 —— 共享的、底层的、面向对象的代码使开发人员可以在其上集成和构建任何应用程序。这一梦想能否成真？Neal 详述了一批开发人员对此作出的努力，他们想设计一种代码框架，使您从每次构建应用程序时都不得不完成的大量重复劳动中解放出来，通过本文，您还将发现 Apache Geronimo 项目和许可颁发与此理念的不谋而合之处。
欢迎进入梦想世界
我还没有那么老，真的。我不会回顾像打孔卡、拨动式开关或晶体管那么古老的事物。我在计算机方面的初次经历涉及到了哑终端、绿色荧光屏、光电笔和一款非常出色的游戏 tic-tac-toe。多年之后，当面向对象的技术面世时，我立即渴望学习它。我依然记得在 20 世纪 90 年代初的乐观态度 —— 不久之后，所有底层面向对象的构造模块就将编写出来，到时候我们就能在平台上编写新应用程序了，只需简单地单击所有那些构造模块就行了！我不由回忆起儿时对 Lego® 积木的困惑。仅仅通过少数设计好的原始积木块真的能够创造出整个宇宙吗？
Apache Geronimo 应用服务器项目获得了商业友好的 Apache 许可，它或许正在成为一个装满积木的大箱子，就像我儿时曾拥有的那样。最终有一批开发人员想到了奠定代码基础，从而使其他人从曾经必须重复实现的基本拼图中解脱出来，这是一件好事。拥有这样的底层平台的关键就是 Apache 许可本身，如果没有这一许可，那么结果将会完全不同。
宇宙的比喻
让我为您描绘两幅景象。第一幅是分段的停滞画面，源代码孤独的支柱隐现在不透明、坚如磐石的许可之后，闪烁着光辉。第二幅是现实的景象，飞驰的叛逆者已赢得战争的胜利，并谨慎地为后代奠定了基础，刀枪不入的许可声明在高大的自由圣堂墙顶的玻璃橱中光芒四射。这两幅迥然相异的画面看起来可能非常熟悉。或许您已经在开放源码这面旗帜下英勇奋斗多年，面对过许多这样坚如磐石的许可，它们阻止您添加下一块拼图，防止您继续完成下一里程碑。
在第一幅画面中，软件归企业所有，这些企业通过销售许可向用户授予使用其软件的特权。这些许可往往不含源代码，因此购买者根本无法影响软件质量，至多只能报告软件中的 bug，期待软件所有者能响应其需求。有时软件中包含源代码，但根据其许可，严禁在其他任何产品中使用其源代码。
第二幅画面显然更为光明。它包含了高度的开放性，源代码可自由获得，有时商业软件也可使用自由软件进行编写。后面我会介绍主要的开放源码许可颁发方案。
两个分支
知识产权（intellectual property，IP）在过去约 20 年的时间里发生了巨大的变化，其特色是不收取任何高昂费用的开放、共享的知识产权，人们希望籍此促进理念的学习与共享。许多开发人员都动手写下了不同许可，不仅允许为学习或其他非商业目的而自由交换理念，还为商家提供了使用其开放源码代码谋利的机会。而开发人员所要的回报仅仅是获得原创身份、维护版权，以保证原作者能对自己的作品保留一定的权力。
两种类型的许可就像支撑自由软件运动的两根柱梁：GNU Public License (GPL) 及其派生许可系列和更为开放（商业友好）的许可（比如 BSD 或 Apache 许可）。GPL 使基于学术事业的调研活动与开发更为繁荣，而不为令人不快的经济活动所破坏。它以相同的许可保护源代码及其所有派生事物，而对于企业来说，若未事先与许可持有者进行商议，则无权自由使用代码。Lesser GPL (LGPL) 是 GPL 的一种派生许可，它的限制相对较少，但依然属于 GPL 许可类。LGPL 允许在商业软件内使用代码库，但需标明原创作者及版权，同时不得以任意方式对相应软件加以修改。因此，LGPL 与 BSD 及 Apache 许可非常相似，BSD 和 Apache 的限制还要更少一些。它们允许对代码进行修改并置于商业软件内。
没有妥协
Apache Geronimo 项目已开展多年，现在可打造自主开发的应用服务器 —— 在最近的 Renegade 访谈中，参与 Geronimo 项目的 Jeff Genender 就是这样称呼它的（请参见 参考资料 部分中给出的链接）。当此基础资源库具备作者想使其拥有的一切特性时，它将成为一项商业原动力，其他任何技术都未曾实现这一点，他们的许可 —— 一个 Apache 许可 —— 使得这一点体现得尤为清晰。他们有梦想，并竭尽全力去实现这一梦想。
这是 LGPL 与 Apache Geronimo 许可要求您在这种情况下必须做出的举措之间的根本区别之一。在 Apache 许可中，您必须追踪所作出的更改，以清晰勾勒出源代码的不同之处，但您可以自由追踪，无需向源池回馈。这很好，您可以做一切支持您的业务所必需的工作。随着许可的发展，Apache 2.0 许可变得易读、易于理解并且可信了。Geronimo 开发人员该如何处理在尝试将所有拼图拼凑在一起以发布完整的应用服务器时会遇到的其他开放源码许可呢？
在许多其他库中调研了 Geronimo 在源代码上拥有的相关性后，看起来所有这些库所持有的许可均与 Apache 许可相符。开发小组尽可能保持谨慎，尽可能不合并或包含可能会对许可的效果产生负面影响的任何东西。这是一个极大的优势，代价是许多人进行了大量工作编写代码库来取代有商业限制许可的库的功能。
Sun Microsystems JavaMail API 正是这样一个软件库。Sun 在其 JavaMail 的参考实现方面做了大量工作。它包含 Internet 上描述网络邮件协议功能支持的许多 Internet Requests for Comment (RFC) 文档中的特性。RFC 看上去确实是一种不受版权限制的资料，使有自虐倾向的软件开发人员得以开发出多种底层系统的详细工作模型，而这些系统正是当今推动 Internet 的动力。若持有特殊的调研许可，可下载 Sun JavaMail 源代码，根据许可的要求，严禁直接或间接地将这些代码用于商业目的。显然，这与 Apache 许可不符。因此，尽管 Sun 开发出了惟一可自由获得的 JavaMail API 实现，它依然不可在 Geronimo 内使用。我认为，Sun 采取这种方法的目的很可能是使其他人无法窃取 JavaMail 参考实现（曾有许多开发人员通宵达旦地将其转录到不受版权限制的 RFC 中）并籍此谋利。
与此对比，我认为 Geronimo 小组的工作更注重大众的利益。该小组努力工作，提供一种带有开放式许可的软件平台，可供应每个人 —— 甚至是企业 —— 使用。如果软件质量出色，这将带来高度的市场提升。但这项工作受到了附加在产品上的许可协定的阻碍，比如 JavaMail，由于其起源，它看上去似乎应该是不受版权限制的，但实际上并非如此。
这也就意味着 Geronimo 要提供一个完整的包，而其他一些人则不得不将不受版权限制的 Internet 邮件 RFC 转录到有效工作的软件模型内，然后编写 Sun JavaMail API 的净化版本，以将其聚集在一起。确实如此，令人沮丧的是，由于其复杂性，要完成这项工作，依然需要拥有一台完好无损、商业友好的 Geronimo 应用服务器。理想的情况下，软件一但编写完成，就不必再做重复工作，除非有人需要将 Java 库移植到 .NET 中，但事实与理想相去甚远。
那么，为什么 Geronimo 小组不用其应用服务器重新发布 Sun JavaMail 二进制文件呢？那些片段在源代码中不能获得，只能通过 Sun 直接获取，除了这样一个事实之外，还有其他一些原因使 Geromino 小组放弃了重新发布的想法。原因之一就是许可禁止在取代 API 任何源代码的产品内发布二进制文件。Geronimo 通过自己的 JavaMail API 存根实现这一目的，JavaMail API 存根是 Java 2 Platform, Enterprise Edition (J2EE) 认证所必需的。在 Sun 的 Software License Agreement 中还有一项条款，按其规定，如果您的软件出现任何问题，您必须同意为 Sun 出庭辩护，这将使您卷入法律事务争端中。此条款看上去非常无理。在许可协议中，您已同意 Sun 不对因您使用其软件而出现的任何问题负责。那么为什么您还要负责在法庭争端中保护 Sun 呢？Apache 许可没有任何此类的条款，尽管它的确设法在出现问题时为软件所有者（编写软件的那些人）提供保障。这还不够好吗？请记住，我并不是律师。
对于其信誉（与其他开发小组不同），Geronimo 小组集中精力避免出现许可颁发不符的问题，并明确地规避了任何出现许可颁发的麻烦，从而确保了清白的信誉。他们必须继续战斗。1.0 版本现已面世，许多人都关注着 Geronimo，许可将非常重要 —— 所有关注许可颁发和维护商业友好代码库的艰苦工作都将获得回报。IBM WebSphere® Application Server Community Edition 以 Geronimo 为基础。这明确地展示了此策略的优越性，也展示了大型企业对 Geronimo 架构及其支持团体的信心，还说明 Geronimo 将在未来的很长一段时间内继续发展。
从梦想到现实
我们是否看到了未来软件基础设施的第一层已开始显现？不幸的是，我极力声明自己并非律师，而我也必须承认自己无法预测未来。然而，我确实希望在未来的 10 年内，我们会最终放弃现有的软件孤岛模型，在这样的模型中有许多零散的阵营，它们疯狂地重复实现着所有软件架构最底层。我更希望能看到一种稳固的、商业友好的组件框架，随时可在其上集成或构建任何应用程序。我认为 Geronimo 正是实现这种可能性的第一道耀眼的光芒。
参考资料 学习
获得产品和技术
讨论
关于作者  | 
| | Neal Sanche 是一位最近才涉足 Microsoft® .NET 世界的 Java 开发人员，他正在克服困难脱离他原来习惯了的开发环境。他的经验包括开发多个商业 J2EE 应用程序和多个独立 Java 应用程序。在业余时间，他作曲、摄影并撰写技术文章。访问他的 Web 站点 可以看到相应的多个示例。您可以通过 neal@nsdev.org 与他联系。 |
对本文的评价
| 
