开发狂想曲：如何在开源Java下生存

核心提示：自从Sun公司宣称要将java代码基础的大部分“发布”之后，Internet上就布满了这样的疑问：此举措对于Java，开发狂想曲：如何在开源Java下生存，开源以及开发者社区来说意味着什么?

自从Sun公司宣称要将java代码基础的大部分“发布”之后，Internet上就布满了这样的疑问：此举措对于Java，开源以及开发者社区来说意味着什么?

首先，我们来看一条通告：Java的要害部分将会在遵循开源GPL V2许可证以及Classpath例外的条件下发布。这一套重要且遵循开源许可证的Java软件的发布可以看作是对开源社区最大的一次代码贡献，同时也产生了很多反应，从担心企业Java社区会在刹那间坍塌，到许多私有软件不可避免地衰败。那些不了解软件许可证的Java技术人员可能会希奇有什么值得大惊小怪的，也不清楚这则通告对他们的影响。

GNU通用公共许可证或者GPL，是由自由软件基金会支持的开源软件的许可证。一旦某软件项目中使用了遵循GPL许可证的代码，则该项目也必须遵循GPL，这意味着它的许可证对项目使用不添加任何的附加约束。后面一点也就是我们在开源社区中经常提及的“copyleft”，这也是产生争论的来源。Java的开源是否意味着，假如使用新近发布的遵循GPL许可证的Java虚拟机开发出Java项目也会被强制性地要求遵循GPL许可证呢?批评者称前面的情况为“许可证的病毒天性”：遵循GPL的代码会“传染”其它由其演绎出的代码，并且强迫作者在GPL下公布源代码。

很显然，这会造成一些恐慌——-免费开放源代码的要求会威胁到企业Java开发人员的商业模式。但是Sun公司很快就取消了大家的担忧，对于现有Java开发人员来说，软件的发布意味着一切正常。Sun公司如此有信心的原因就在于前面所说的Classpath例外，Classpath例外是为Classpath项目而开发的：它是通过开源编写的Java类标准，也在其它开源Java项目中采用，例如Kaffe。Classpath例外的内容较短，所以也值得一读：

静态或者动态地将java库和其它模块链接在一起，完成基于此库的组合工作。这样，GNU的GPL规定和条件将覆盖在整个组合体之上。

作为一种非凡的例外，此库的版权持有者分配给你权限来将用于生产可执行程序的独立模块链接到这一库。无论这些独立模块的授权如何规定，如何复制、发行可执行程序都依靠于你的选择。这里的独立模块是指非来源于或是基于此库的模块。假如你修改这个库，就可以扩展这个例外到你的版本中，然而这并不是必须的义务，假如不想这样做，可以从你的版本中删除这条例外。

这段话的实质就是关于Java代码问题。当你只是通过链接使用Java方法或者对Java类进行扩展时，你的代码就不需要遵循GPL标准。只有当对Java代码进行直接更改的时候才需要遵循GPL的“copylef”规则。例如，假如你扩展了一个遵循GPL许可证的Java类，并且在你的项目中使用它。则Classpath例外意味着你不要按照GPL的要求发布你的项目，但是假如你修改了原来的类，并且期望发布项目的话，则必须要遵循GPL的许可证。这样做的结果就是只有那些从事Java语言本身的开发人员需要公布他们的源代码，而不是那些使用Java语言进行项目开发的人员。

进入讨论组讨论。