Geronimo 叛逆者: Geronimo 与 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 中）并籍此谋利。