新闻原稿发布于2006年11月13日12时01分。
该发生的终于还是发生了——Sun于今天宣布在GNU通用公共许可证第2版（GNU General Public License v2, GPLv2）下开放Java SE、Java ME以及Glassfish的源代码，同时Sun在Java.NET网站上新的OpenJDK项目中发布了Java SE 7 HotSpot JVM、javac编译器和JavaHelp的早期构建版本，而OpenJDK将作为今后JDK开发、发布和bug修正等的项目网站。完全可构建的Java SE 7 JDK类库计划于2007年第一季度发布。
Glassfish，Sun 的开源Java EE应用服务器（以及Java EE参考实现）目前也在GPLv2许可证以及CDDL下发布。今后，在java.net上将也能看见Sun feature phone Java ME实现及测试/TCK（技术兼容性工具包）的可构建版本。今年后期，Sun将发布另外的源代码，包括其高级操作系统电话实现和Java设备测试套件 （Java Device Test Suite）的框架。
一旦其最终版本发布，Java SE 6将在2007年春天开源。Sun的Mark Reinhold称，倘若现在就发布Java SE 6会显得太过莽撞，因为这样做将影响到它的发布时间——第一个候选发布版本刚刚于上周发布，另外，JSR 270（Java SE 6发布目录）也于2006年10月24日刚刚被JCP通过。“我们必须在HotSpot JVM和编译器上做一些修改，以便使之能够在Sun公司之外构建。这些修改被集成到JDK 7的早期构建版本中。当我们在2007年春天进行完全发布时，我们将同时发布Java SE 6和7两个版本。
Java开源最重要的两个方面是许可证和管理模式。在管理模式方面，目前尚未有任何东西宣布，仍然有待定夺。Tim Bray向InfoQ表示：“管理模式最终将以一种平和且符合开源价值观的形式公布，也就是说，以提交者为中心，而我们非常期望会有来自Sun之外的提交 者。”从另一个方面来说，社区中某些组织一直在寻找一种能让Sun放弃绝对控制权的管理模型（参见Eclipse对开源Java的管理模式）。唯一言及的与管理有关的是，提交者将必须签署一份贡献者协议，协议规定了共同版权委托协议（Joint Copyright Assignment），并且将专利权许可证委托给Sun。Tim Bray对专利权委托作出了如下解释：
我们必须保证Java用户不必担心会因为使用Java而侵犯Java的任何一个贡献者（包括Sun）所持有的专利权而遭到索赔；因此，我们必须预防任何人，不管是有心还是无意地在为Java贡献代码之后向使用Java的人索取赔偿。
为什么选择GPL？正如过去在InfoQ上所报道的，开源的Java存在着许多实际的需求。Sun声称，GPL许可证能够达到两个主要目的：为Java带来更多的内容及更大采用率，并且继续维持“一次编写，随处运行”的兼容性承诺。
在内容和采用率方面，在GPL之下的Java可以允许：
- Java变得对Linux友好，此外，因为免费，Java可以默认随GNU/Linux发行版本发布。
- Java变得对政府友好。 现在，由于Java的许可证使得Java自身完全免费，外国政府可以放心将其基础架构构建在Java之上，而不必担心受到专有权和属于美国的知识产权（可 能会在某一天被政府禁止出口）的限制。Sun官方人员还特别提到了中国和巴西，以例证一直以来向Sun游说开放Java源代码的国家。
- 即便在美国，也存在一些项目不接受不基于开源软件开发的竞标。
- 新的技术用例。现在公司可以随意将Java移植到新的硬件平台和操作系统上，还可以在必要的时候创建定制的有特定应用的JVM。但是按照GPL的规定，所有衍生物还必须在GPL下发布，因为GPL限制基于商业目的类似行为，企业对这些衍生物是不具备专有权的。
Sun官方人员就兼容性承诺表示：
GPL作为Java许可证是非常合适的，因为它将尽可能减小代码中出现专有分支的可能性……它为公众带来创新，任何对代码的更改都必须被发布……
Tim Bray就GPL和分歧问题向InfoQ展开详细说明：
GPL并不会[阻止代码分支]，它完全允许分支，而且分支也确实会产生，这就引出了我们如何保持Java的兼容性承诺问题。我们将使用一个商业的/ 法律的办法，而不是使用技术手段。也就是说，你可以获取代码，改变代码，编译代码，发布代码，销售代码，而不需要任何许可。但如果没有通过你现在所必须通 过的所有相同的步骤，你就不可以称其为Java或者使用咖啡杯logo：通过合适的技术兼容性工具包和保护版权的批准。所以对于那些想一定使用真正合适的 非分叉Java的商业人士来说，"Java"名称和咖啡杯Logo的商标使用是一定要经过批准的。
因为GPLv3尚未完成，所以它并没有被选中。但当被问及Sun是否会在将来转向GPLv3，一名官员回答：“目前为止，我们还不知道最终版本的许可证会是什么样子。”
开源Java的许可证成为了困扰Java开发人员的主题，以至有人担心连扩展java.lang.Object都可以视为 JDK的衍生物，而且，使用GPL可能会引起自己的Java应用不得不在GPL下发布。开源JVM Kaffe（在GPL下许可）的领导人Dalibor Topic澄清说并不是这么一回事：
GPL并不要求使用以GPL为许可证的java.lang.Object的字节码也要在GPL下被许可。因为字节码和使用字节码 的源代码都不是java.lang.Object的派生物，有关联的只是接口名称和常量，而他们没有变化，所以不用理会java.lang.Object 的许可。那些symbol通过JCP标准化，并按规范发布。从交互性角度来说，他们是必须的。所以，symbol名称和常量值不能被GPL下的 java.lang.Object声明为原始物，因此不会有版权的障碍。
简而言之，Dalibor 稍后又解释说：
从标准类库获取以 GPL 为许可的代码，稍作修改或者原样照搬，你就可以在你自己的代码中应用它们，当然，也不用理会许可。
Tim Bray就JCP的行动所产生影响向InfoQ阐明：
JCP并不管理实现，而只管理规范。它所做的工作是定义各种各样的Java包（SE、EE、ME），其中部分使用参考实现。这个时候，我们没有计划为了表现开源运动的发展，而在JCP里做任何大的变更。
在这一点上，关于声明对已经存在的开源Java项目（包括Kaffe VM、GNU Classpath类库或者GCJ编译器等）究竟意味着什么，还不明显。对于Apache Harmony项目来说，它也在试图为开源Java实现营造一个洁净的环境。最新消息：Apache Harmony PMC（Project Management Committee，项目管理委员会）主席Geir Magnusson向InfoQ表示，Harmony的开发将继续下去：
对于我们来说，不会有太多改变。Apache和Sun拥有的社区并不相同，社区的许可证、代码捐赠条件及管理模式也各有迥异。由 于Apache Harmony的每个贡献者各自怀着不同的参与原因，因而我不能在这里代表他们每个人的立场，但是我相信今天这则来自 Sun 的好消息并不会改变我们将做的事情——这仅仅意味着更多的开源Java，而这是件好事。
Harmony被发布于Apache许可证之下，不能包含GPL许可的代码，因此无法使用任何OpenJDK的代码。由于GPL阻止了对Java的 专有修改（因为GPL要求你也在GPL下发布更改），因此仍有许多商业利益集团希望Apache Harmony项目继续下去。
在这些商业利益集团中，最大的自然要数IBM，它多年以来一直在向Sun施加压力，要求其开放Java的源代码。自2003年来，IBM在JCP通过的每一个JSR的投票中都加入了以下条款（摘自每条JSR的最后一轮表决票）：
IBM所投的表决票是基于此项JSR规范的技术价值考虑的结果，而非针对许可条款。通过允许第三方组织创建Java规范的独立实 现来创造一个开放和平等的领域以及禁止个人或公司以专有利益为目的行使不必要控制的许可证模式，是IBM所倡导的。我们支持开源作为JCP内捐赠的许可证 模式，同时也希望其他参与者能够支持这个路线。本评论并非针对此项JSR的商业或许可条款，但它是IBM最为认可的许可证模式的声明。
IBM 一直以来都是Apache Harmony的支持者，此外Intel也对该项目捐赠了许多代码。这也一直被业界猜测为是向Sun施加压力，使之开源 Java 的间接尝试。
Sun将在 http://www.sun.com/opensource/java上面进一步发布关于Java开源的详细信息，太平洋时间今天上午9:30将有公开的网络宣传。最新消息：Sun发布了面向分析师的新闻中心，囊括了更多的消息，包括对不同人物的视频访谈引用。
开源Java所带来的冲击将是什么呢？Tim Bray的个人心愿是“开发GNU/Linux桌面的人也能从C++的专制中解放出来。”你认为呢？