What is Sun announcing?A:
Fulfilling its promise to the world exactly one year later, Sun is releasing a fully buildable implementation of the JDK in the OpenJDK Community.Q:
Following on to Sun's November 13, 2006 announcement six months ago of the creation of the OpenJDK project and community, and the widely acclaimed choice of GPL v2 as the license for Sun's open-source JDK initiative, Sun is delivering in only one year on substantially all of its promises to the industry. Building on this momentum, Sun has solidified its position as the pre-eminent contributor to the F/OSS ecosystem.
What is the significance of this announcement to the industry?A:
This announcement takes open-source, compatible Java from a long-standing dream of developers worldwide, to concrete reality. With the open sourcing of the code base for one of the industry's most significant and pervasive software platforms, the groundwork has been established to foster adoption in new markets, to build broader communities, and fuel even more innovation. With over 5.4 billion Java technology enabled devices, Java technology has already demonstrated explosive growth, appearing in volume nearly everywhere. Now, as free software, the Java platform can address new markets and be the engine of innovation for the next generation of networked applications.
What is the OpenJDK Community?A:
Sun has established the OpenJDK Community for the ongoing development of Sun's open-source implementation of Java SE. The OpenJDK Community is where developers gather to collaborate on the open-source JDK code base and related projects. The OpenJDK project in which the open-source code base lives is part of this community. Through the OpenJDK project, developers can directly influence the future of the JDK implementation, participate with their peers in an open community and help take Java technology where it hasn't been before. Sun evolved the earlier JDK Community, where developers worked on the source code the two years prior to open-sourcing the JDK, into a site where Sun and non-Sun developers alike can collaborate together on the implementation. The OpenJDK Community can be found at http://openjdk.java.net.Q:
What components of the JDK software are you open sourcing today?A:
In November 2006, Sun open sourced the Java programming language compiler ("javac"), and the Java HotSpot virtual machine. In addition, Sun open sourced the JavaHelp 2.0 extensible help system, Sun's reference implementation of JSR 97. Now Sun is open sourcing most of the remaining components of the JDK, with the exception of a few encumbered components that we hope, with the community's help, can be re-implemented so that 100% of the OpenJDK code commons is available as free software.Q:
Specifically, which components of the JDK are being added today to the OpenJDK project's code base?A:
The following components are newly open sourced under GPL version 2 plus the Classpath Exception:Q:
Is the entire OpenJDK code base under the GPL?A:
Yes, much of the OpenJDK code is licensed under the GPL version 2 with the Classpath exception. The Java Hotspot virtual machine source code is licensed under the GPL version 2 only. All of Sun's Java platform implementations are or will be licensed under the GPL version 2, or GPL version 2 with the Classpath exception. The GPL is endorsed by the Free Software Foundation, and is the license used by the GNU/Linux operating system.Q:
When will you finish clearing encumbrances? What is the timeline?A:
With the community's help, we hope that encumbered code can be re-implemented over the next 6 to 12 months, balancing this critical engineering task with other priorities, and depending on the level of community participation in speeding this effort.Q:
Will Sun continue distributing its commercial implementation of the JDK?A:
Yes. For people who want the benefits of commercial support, and predictability, they may choose to use Sun's commercial distribution of the JDK or JRE. The free commercial implementation of the JDK may be found at http://java.sun.com/javase/downloads/index.jsp. Similarly, Sun's free JRE may be downloaded from http://java.com. To learn more about development and deployment support options, visit http://sun.com/javasupport.Q:
Will Sun's commercial JDK releases be built from the open-source code?A:
Yes, for the most part. Since there's some encumbered code in the JDK, Sun will continue to use that code in commercial releases until it's replaced by fully-functional open-source alternatives. In addition, Sun may deliver more differentiated commercial JDK products that address specific market needs in the future with these variants still built from the open-source code.Q:
Are you open sourcing the Java language or the Java SE platform specifications?A:
Since both of these are documents and not source code, there is no source to open! Thus, while we are open sourcing Sun's implementations of both, we cannot "open source" the Java programming language, nor the platform APIs and specifications, which are governed by the JCP.Q:
Which version of the JDK do these components come from? Are you open sourcing the latest code?A:
We're open-sourcing these components from an early build of JDK 7. JDK 6 is the current shipping production release, and is stable. Hence we're releasing these components from the JDK 7 tree. At this stage, the only significant differences between the JDK 6 and 7 versions of these components are minor bug fixes and enhancements that have already been integrated into the JDK 7 tree. JDK 7 is the next feature release where all the action will be for innovation and new capabilities.Q:
Didn't you promise to open source both JDK 6 and JDK 7 last November? What happened to JDK 6?A:
Sun did make that promise, and we plan to keep it. But in the six months since the November 2006 announcement, it has become clear that doing this is far more complex than just changing the license and publishing the source code. JDK 6 is a stable, production release that millions of developers and users depend on. Sun's Java platform release engineering processes have evolved over 12 years to insure this stability, based on very tight control over changes. We don't yet know how to open source a stable release in a way that maintains the robust quality and compatibility characteristics consistent with this tight control, while creating a community that attracts innovation and participation. We have some ideas on solving this problem based on the inherent differences between established APIs and new platform directions. We're looking forward to working with the community to adjust the release cycle and processes to solve this problem.Q:
The OpenJDK code base is huge! How do I know what each component does, and where to begin?A:
Hacking on the OpenJDK project can be daunting for those just starting out. Even the most experienced Sun engineers who've been working on this code base since the first line of code was written find it necessary to specialize and focus on specific modules. A solid grounding in the language and platform are a must for working on this project, but for the aspiring systems programmer or experienced Java developer there are many interesting opportunities in such a large body of code. Find the elements that interest you most, study the APIs and javadocs, then dive into the code to see how these APIs are implemented, search the bug database for interesting problems to solve, and get going! It might be tough going at first but you can join the community discussions and get some help and advice, and enjoy the satisfaction of working on one of the most widely used programs in all of computing. We will be providing a list of suggested "starter bugs" on our community site, to give you some ideas where you can get started.Q:
Where do developers go to participate in implementing these JDK components?A:
Developers can gain immediate access to these components under the open-source license by visiting https://openjdk.java.net. NOTE: The URL has changed and been simplified with this announcement!Q:
How can I get involved?
Visit the OpenJDK Community at http://openjdk.java.net and check out the projects, mailing lists, pointers to blogs, and other opportunities to participate. Sun, and indeed the whole Java technology ecosystem, welcomes any and all suggestions, bug fixes, and contributions of code, ideas, and energy.Q:
With this announcement, how is the governance model for the OpenJDK projects evolving?A:
Sun is pleased to announce the formation of an Interim Governing Board for OpenJDK, and a charter for this board to create the new, community focused governance model for OpenJDK featuring transparency and an open, meritocratic process. The IGB will invite the community to join in discussing and debating its own structure and rules, and the resulting model will reflect the will of the OpenJDK community. For more details on the IGB, the charter, and the roadmap to establishing the steady-state governance model for OpenJDK, please see the Governance section of this FAQ. In the interim, Sun will establish the needed processes and governance criteria (as required) for community interaction and projects to operate effectively.Q:
With the JDK nearly completely available under the GPL, and working implementations based on OpenJDK code on the horizon, both the promise and peril to compatibility of an open-source Java platform are upon us. How will Sun make the JCK (the Java SE TCK) available, and provide access to the "Java Compatible" brand?A:
Sun understands the importance of compatibility. In fact, most users, developers, source licensees, open-source contributors and leaders indeed most of the Java technology world all agree that compatibility is essential to the value of the Java SE platform. For that reason, Sun will establish a clear process for the Java SE TCK (JCK) to be available to developers who need to verify the compatibility of OpenJDK-based implementations. Please see the TCK section of this FAQ for more information.
What is the Mobile & Embedded Community?A:
The Mobile & Embedded community establishes a central location for the open-source development of Java ME technologies and applications. This community has been launched on java.net and can be found at the following URL: http://community.java.net/mobileandembedded. It currently includes the phoneME project, the cqME project, and the application developer project. In the future we anticipate that this community will grow by adding additional Java technology and application projects.Q:
What license did you choose for Java ME?A:
Java ME code is licensed under GPL v2, as are all of our Java implementations.Q:
What parts of Java ME has Sun open-sourced?A:
Sun has open-sourced its implementations of Java ME. Available since November 13, 2006, are the source code for Sun's feature phone implementation called the Sun Java Wireless Client (based on the Connected Limited Device Configuration, CLDC), and the advanced OS phone implementation (based on the Connected Device Configuration (CDC) specification). The Java Wireless Client is the next generation version of the platform that currently enables rich mobile data services in over 1.5 billion handsets.Q:
Sun has also open-sourced its compatibility and quality testing tool frameworks. This includes the source code for the Java ME TCK Framework, the foundation for Sun's Java ME compatibility tests. We believe this project can help to standardize the industry on a single framework to simplify the testing process. In addition, Sun has open-sourced the Java Device Test Framework, the foundation for the quality and function tests. This project enables developers to create new tests, reducing implementation variation and enabling their applications to run across multiple devices.
What is the feature phone implementation?A:
The feature phone implementation is a Java runtime designed to run on today's mass-market handsets.Q:
What is the Advanced OS phone implementation?A:
What is the Advanced OS phone implementation? A: The Advanced OS phone implementation is a Java runtime designed to run on operating systems targeting advanced mobile devices like smartphones, set-top boxes, etc.Q:
Will Sun's implementation be built from open-source code?A:
Will Sun's implementation be built from open-source code? A: Yes, Sun's implementations for feature phones and advanced OS phones will be based on the open-source code base.Q:
What can a developer do immediately with the CDC and CLDC code bases?A:
A developer is able to build both the feature phone and the advanced OS phone code bases now that these are open-sourced. Developers have the opportunity to download, evaluate, and play with the source code, and help in its ongoing development.Q:
Will Sun continue to ship commercial implementations?A:
Yes, Sun will continue to ship commercial implementations for feature phones and advanced OS handsets under Sun's commercial licenses.Q:
What is the difference between the open-source and the commercial code bases?A:
The differences include encumbrances and some minor modifications to the source code such as splash screen, logos, license, header files, etc.Q:
What can a developer do with the framework code bases?A:
A developer can use these frameworks to drive testing of compatibility tests for new mobile JSRs, and create tests to improve the quality of implementations.Q:
Where do developers go to participate in the Java ME projects?A:
The Mobile & Embedded community has been created to enable platform developers and application developers to participate. Visit http://community.java.net/mobileandembedded for more information.
What is the phoneME project?A:
The phoneME project is where Sun is releasing its phone implementations for Java ME. It has a single repository that consists of various active development modules including CLDC, CDC, MIDP, and various JSR implementations.Q:
What is the cqME project?A:
The cqME project (compatibility and quality) is where Sun has released the source code and is doing the active development on the Java ME TCK Framework. In the future, Sun will release into this project the source code and engage in the active development of the Java Device Test Framework.Q:
What is the Application Developer project?A:
The Application Developer project provides resources to developers and a place to engage in the development of open-source Java ME applications. The project is the home for the new developer guidelines that were created in partnership with Orange. These guidelines will help developers minimize porting efforts. This project is also a home to open-source Java ME application projects.
How can developers use the NetBeans IDE to get started in working with this code?A:
In conjunction with the NetBeans 6 Preview Release, Sun has created pre-built NetBeans projects and incorporated this project metadata directly into the newly open-sourced OpenJDK code base. This NetBeans integration makes it intuitive and easy to use NetBeans and also Sun Studio to dive into the OpenJDK source code and begin working on the platform right away. Once you've inspected the code and made changes, the NetBeans "Build Project" command lets you easily build modules. For more information and a step-by-step tutorial, please visit http://nb-openjdk.netbeans.org
Why is Sun open sourcing its Java implementations now?A:
The Java platform is 12+ years in the making. When it was first released it was a radical departure for commercial software, including full source code under a novel license. Sun and the Java ecosystem have been extremely successful at establishing and growing a very large and dynamic market in this time. The Java platform retained its own licensing model even as the open-source model proliferated, because the Java licensing model successfully created a large and open market with many compatible choices. We now see an opportunity to encourage even more possibilities for adoption in places the Java platform hasn't gone before, where Free licensing and open-source development approaches are a prerequisite for consideration.Q:
At the same time, the Free software and open-source communities are now saying that compatibility is a given for any Java implementation. And there is a new spirit of innovation with Web 2.0, SOA and collaboration/participation technologies, and the Java platform is the perfect foundation platform on which to innovate - and open-source can help accelerate this innovation.
What influenced this decision?A:
Key Free software and open-source communities have stated that they believe that only Java technology implementation that are completely compatible with the specification can succeed in the market. These communities, which provide thought leadership for the open-source Java world, are now focused on delivering only compatible implementations. In addition, Sun has gained experience in community development with the Project GlassFish open-source implementation of Java EE, with OpenSolaris, with OpenOffice.org and NetBeans, and with the JDK Community on java.net. This experience makes us confident that when we open-source Sun's Java implementations, the platform will benefit, and we can better balance the needs of community with those of customers, end users, and licensees.Q:
Overall, we feel that caution is appropriate for a technology that affects the lives and livelihoods of tens of millions of people around the world. After much reflection we feel now is the perfect time to take the next step with the Java platform.
Why is this good for Java SE developers?A:
Because volume wins. Open sourcing Sun's Java SE implementation will lower barriers to adoption in markets where open-source software leads. As new markets adopt Java technology, developers will discover new opportunities. More applications. Innovations that leverage the industrial strength foundation of Java to deliver valuable new products and services. And developers will be able to directly influence the future of the JDK implementation, participating with their peers in an open community. Taking Java where it hasn't been before, and helping to ensure that Java technology remains a central unifying standard for the Internet.Q:
How does this benefit Java SE customers and users?A:
Your investment is safe, with multiple independent implementations of Java SE, and the reference implementation from Sun available under an open-source license. An open-source JDK provides peace of mind, plain and simple:Q:
What markets do you believe this initiative will open up for the JDK?A:
Several markets are likely to find the JDK to be more suitable for use once it is under an open-source license:Q:
What impact will this move have on the adoption of the Java SE platform?A:
The Java platform has been very widely adopted already - it is one of the most important and widely used components of modern web-based infrastructure. But there remain un-tapped or under-served markets. In particular, Java technology is not always included in open-source web infrastructure stacks that are commonly distributed and deployed alongside and included with GNU/Linux distributions. Those that do include Java technology often do not include an up-to-date, compatible runtime and development environment. We continue to work with the GNU/Linux distributions to get the JDK included as part of the free software repositories commonly included with these open-source operating system distros. Once the JDK is easily obtained and installed with these platforms, we expect to see more widespread adoption of Java technology especially outside of North America and Western Europe, as well as in cutting edge web infrastructure deployments worldwide. Since the GPL is a very widely used open-source license (in fact it's the same license used by GNU/Linux), distributing the JDK under the GPL with GNU/Linux distributions should be a good match, making it easier to adopt by those looking for open-source alternatives.Q:
What are your goals in open sourcing Sun's Java ME implementations?A:
To remain the number one mobile application development platform*, Java ME needs to grow and evolve. This means engaged developers, accelerated innovation, and a more consistent implementation across devices. [* Evans Data Corp. Spring 2006]Q:
Who benefits from open sourcing Java ME?A:
Everyone in the Java ME ecosystem benefits from open sourcing Java ME. Benefits include:Q:
By open sourcing these implementations, handset manufacturers can leverage the common code base to reduce their development costs. The result will be less variation across devices P in other words, Write Once, Run Anywhere taken to the next level.
Both application developers and operators will benefit from the accelerated innovation, enabling developers to continue to create compelling applications and services, which in turn help drive revenue. Operators and handset manufacturers will benefit from lower porting, testing and maintenance costs.
What does Sun mean by "compatibility?"
Compatibility for a Java technology means the implementation of that technology meets the associated compatibility requirements of its Technology Compatibility Kit or TCK. For Java SE this means passing the TCK tests and other requirements defined in the Java SE TCK, known as the JCK.Q:
Do you think anyone will fork the JDK?A:
We expect great new ideas and valuable research to come from adaptations (i.e, forks) of the platform. Sun encourages compatible forks where the code is ported to additional hardware and software platforms. Such ports extend the breadth of Java SE to places currently not supported by any vendor. Broad distribution of incompatible forks is potentially a danger since such forks could damage the "Write Once, Run Anywhere" compatibility value of the Java platform.Q:
So, what about compatibility? How will Java technology remain "Write Once, Run Anywhere" since Sun's Java platform implementations are open sourced?A:
The Java technology compatibility promise is so central to the value of the platform that it has been the single most important influence in driving the detailed planning and decisions for this initiative. Sun is making a number of key decisions and commitments to the community that we believe will help foster compatibility:
In addition to the specific steps that we're taking to help foster compatibility, we are convinced that the market will demand compatible implementations, and that incompatible ones won't gain traction. With the billions of dollars of Java applications in the installed base, the community has recognized that a Java implementation that doesn't run the installed base of code won't get very far. That is why both the GNU/Classpath and Apache Harmony projects have stated unequivocally that they're working to build fully compatible implementations of Java SE.
We have experience in the Java EE world to back this up: there are four compatible, open-source Java EE implementations in the market including Sun's GlassFish Application Server, and no incompatible variants have achieved any market penetration. We expect the same dynamic to happen with both Java SE and Java ME platforms.
What do Java SE customers buy from Sun?A:
The JRE and JDK binaries themselves will remain zero cost downloads. End-user customers can buy subscriptions and one-time engagements for enterprise-class support from Sun for Java SE, including:Q:
Commercial source code licensees may optionally buy additional services and gain additional rights, including:
In addition, some customers needing specialized versions of Java SE for embedded and real-time applications may purchase licenses to these added-value implementations. We're also investigating support services that could be offered optionally to customers who prefer to "do it themselves" using the open-source code base, but need a bit of additional help.
Why purchase these added value services and implementations from Sun?A:
Sun, the only systems vendor to have open-sourced nearly its entire software portfolio, enables customers to leverage a number of unique advantages that only it can offer, including:Q:
In addition, Sun brings unique expertise and knowledge of both Java technology and open-source best practices to the table. This combination will help Sun establish OpenJDK as the most compelling open-source community for innovation, allowing Sun to gain maximum benefit from the open-source initiative. Some of these advantages include:
How will Sun's Java ME business be affected?A:
Sun is confident that licensees will continue to leverage Java ME commercial products and services that help them deliver an exciting and compelling mobile internet experience to consumers. As a result, we expect our business opportunities to multiply based on the improved economics that easy access to source code will bring.
What license did you choose for the open-source JDK components?A:
GPL v2 for almost all of the virtual machine, and GPL v2 + the Classpath exception for the class libraries and those parts of the virtual machine that expose public APIs.Q:
What license did you choose for implementations of Java ME and the Java ME frameworks?A:
GPL v2 was chosen for all components related to Java ME.Q:
Did you use the GPL v2 verbatim, or did you alter it?A:
Sun is using the unmodified GPL v2 for Java ME and using GPL v2 for the JDK with the Classpath exception and a new Assembly exception.Q:
Is GPL v2 an open-source license?A: Q:
What is the Classpath exception?A:
The Classpath exception was developed by the Free Software Foundation's GNU/Classpath Project (see http://www.gnu.org/software/classpath/license.html). It allows you to link an application available under any license to a library that is part of software licensed under GPL v2, without that application being subject to the GPL's requirement to be itself offered to the public under the GPL.Q:
Why do you need the Classpath exception?A:
If an application is distributed with an implementation of Java such as the JDK under GPL v2, that application could be subject to the requirements of the GPL that all code that is shipped as part of a "work based on the [GPL] program" also be GPL licensed. Accordingly, a GPL license exception is needed that specifically excludes from this licensing requirement any application that links to the GPL implementation. The Classpath exception accomplishes this. Without the Classpath exception, a Java SE implementation licensed under GPL v2 could not practically be distributed with non-GPL licensed Java applications. This could present a serious barrier to adoption, for example by OpenSolaris or GNU/Linux distributions if left unaddressed.Q:
Why did you choose this licensing method?A:
This is the licensing paradigm in common use within Free software communities such as GNU/Classpath and Kaffe for the components of a Java technology implementation including the virtual machine and class libraries. We consciously chose the same licensing method so that there would be no temptation to second guess Sun's intention to make its Java SE implementation available under a genuinely Free and open license and to allow easy collaboration with these existing communities.Q:
Doesn't GPL v2 + Classpath exception offer very similar licensing terms to the LGPL? Why not use LGPL instead?A:
Yes, from a practical perspective the Classpath exception establishes similar terms to LGPL. However, the Free software Java technology communities haven't chosen to use LGPL, and so we at Sun decided to follow their lead and use the Classpath exception.Q:
Does this mean Sun is abandoning CDDL?A:
Not at all! Sun has developed a broad and pragmatic approach to Free and open-source licensing, and uses several different licenses to meet the varying needs of the communities it has started.Q:
Are you licensing the entire JDK under this method?A:
Yes. Note that some of the code included in the OpenJDK project is not part of the Java Runtime Environment, but rather is part of the tools and documentation that let developers use the JDK to create and test code, as well as some demo and sample application code. See below for specifics on how each of these modules is licensed.Q:
What about source code in the JDK that originated outside of Sun and is incorporated into the JDK under its own license? Can you relicense this code under the GPL?A:
Where such licenses are compatible with the GPL, then this code is licensed under the GPL in the OpenJDK code base. There are some code modules that Sun may not have the right to release under the GPL. We're still investigating some of the license compatibility issues and hope to resolve them as quickly as possible. In the mean time this code will be released only as binaries if the source is proprietary or as source under its original open source license.Q:
How can you ship the JDK with binary-only elements then? You said there were encumbrances.
Well spotted! Because there are encumbered components that must be shipped without source. The Software Freedom Law Center and the Free Software Foundation have helped us craft a special exception to the GPL, called the Assembly exception, to allow the full JDK to be built. This exception will be applied temporarily until the encumbrances are removed to these binary plugs. We would welcome your help to make this happen as soon as possible. In addition, the Assembly exception is needed to allow Sun to combine in a single collected work components under both GPL, and GPL plus the Classpath exception. Without the Assembly exception, the entire OpenJDK code base would have to be licensed under GPL without the Classpath exception.Q:
Is there anything else besides encumbered binary plugs and files subject to the Classpath exception that are covered by the Assembly exception?A:
Yes, there are a number of open source code files under licenses that may be incompatible with the GPL. In these cases we ship the source code under its original license, covered by the Assembly exception.Q:
Can I take my non-GPL code and combine it with the OpenJDK code base to create a combined work if I apply the Assembly exception to my code? Doesn't this get around the GPL's requirement to license the entire combined work under GPL?A:
No. The Assembly exception applies only to specifically designated files that are described in a document called "Designated Exception Modules". As holder of the overall JDK copyright, only Sun is able to designate such exception modules, so you aren't able to apply the Assembly exception to your own arbitrary source code modules. This preserves the requirement to license combined works under the GPL.Q:
So, what if I work on the OpenJDK code base and make a change to a module covered by the Classpath exception or that is a designated exception module with a different license? If Sun is the only one that can designate exception modules, won't my derivative work no longer be covered by the Assembly exception and thus unable to be distributed subject to the Classpath exception or applicable open source license?A:
The language of the Assembly exception covers derivative works. So as long as you continue to license your changed code under its original license, whether that be GPL v2 + Classpath exception or under another license as a designated exception module, you can apply the Assembly exception and retain the original license terms for the modified file. Please be aware that you can't modify the encumbered binary plugs. You can only create derivatives of source files that are designated exception modules.Q:
Will all future implementations based on the OpenJDK source code require the Assembly exception?A:
The Assembly exception serves two purposes. It allows us to ship code that includes binary plugs for encumbered components. It also allows us to create a combined work that includes components licensed under the Classpath exception. If you want to create a binary from the OpenJDK code base and retain the Classpath exception for components that Sun has licensed using this exception, you will also need to retain the Assembly exception. Sun is looking forward to clearing all of the encumbrances as quickly as possible, to eliminate the need for the Assembly exception for any purpose other than to allow for the Classpath exception.Q:
This seems like a very complex licensing scheme, with exceptions applying to exceptions. Why is it so complex?A:
Sun is very respectful of the intellectual property of others and is scrupulously careful not to violate licenses to the best of our knowledge. We have studied the detailed implications of the GPL v2 license and the Classpath exception and based on this careful analysis, have devised this approach toward delivering a buildable JDK implementation that includes a small number of encumbered modules as binary plugs. The Software Freedom Law Center and the Free Software Foundation agree with Sun's analysis of these licenses and helped us develop this approach.Q:
Why didn't you choose a license like BSD or Apache v2?A:
Sun had several objectives in mind in choosing the license for the JDK source code. We wanted to:Q:
Why is the license different for Java ME than for the JDK? Why no Classpath exception for Java ME?A:
Sun chose GPL v2 without the Classpath exception for the phoneME software because the method of bundling and distributing applications together with platform implementation code (which is practiced in the Java SE space) does not apply to Java ME.Q:
What are the advantages of GPL v2?A:
As well as fulfilling its original purpose of promoting Free software, the GPL v2 is designed to help advance projects and code commons by requiring innovation sharing with the commons. By design, it minimizes proprietary forks by requiring any modifications be shared with the project. GPL v2 is the right license to preserve Java's trademark "Write Once, Run Anywhere" value proposition.Q:
What rights do developers have under GPL v2 + Classpath exception?A:
The best source for answering this question is the license itself. In addition, there have been numerous analyses of the GPL license and its terms, not least by the license stewards, the Free Software Foundation. Sun recommends studying these interpretations, and consulting legal counsel as necessary to understand your rights under this license.Q:
What are developers' obligations under this license?A:
Once again - the best source for understanding Sun's chosen license for the JDK source code is the license itself.Q:
How can someone use the open-source code base to create a derivative work?A:
Sun's Java platform implementations are now Free software. Developers can use the open-source OpenJDK and phoneME code bases in any way that a GPL v2 licensed code base may be used. These implementations are not "special cases".Q:
Can someone create and distribute an implementation that isn't compatible with the Java specification using this code?A:
Yes. We do not recommend or endorse that action, however. In addition, they cannot label that implementation with the Java Compatible or Java Powered (for Java ME) brand and logo. These brands are your assurance that an implementation has passed the relevant TCKs.Q:
Can someone create software that doesn't even implement Java, but uses pieces of the OpenJDK code commons? What are the limitations, if any?A:
Yes. There are no limitations. But there is an obligation to meet the requirements of the GPL (plus Classpath and Assembly exceptions if appropriate).Q:
Can I call the resulting software "Java"?A:
What must I do to call my software based on code from the OpenJDK or phoneME projects "Java"?A:
The requirements for the use of the "Java" trademark and name have not changed with the open sourcing of the JDK and Java ME source code. The GPL v2 does not include a trademark license - no OSI-approved open-source licenses do. Sun does not currently have a licensing program that permits the use of the "Java" mark in your product or company name. You can use a truthful "tagline" however associating your product or company with Java technology, according to Sun's standard terms for use for trademarks. Please see http://www.sun.com/policies/trademarks/ for more details.Q:
What must I do to use the "cup and steam" logo? Does Sun license it?A:
Sun offers several logo programs featuring the distinctive Java "cup and steam" logo design. To see whether you qualify for one of these programs and to learn how to participate, please visit http://java.com/brand for more details.Q:
How do I know which components in the OpenJDK project are under just the GPL, and which are under the GPL + Classpath exception?A:
Each source file is individually licensed. The key difference is the presence of the sentence:Q:
Sun designates this particular file as subject to the "Classpath" exception as provided by Sun in the LICENSE file that accompanied this code.in the "+ Classpath" version. So basically if you see the word "Classpath" in the license header then you know that the exception applies.
How do I know which components in the OpenJDK project are covered by the Assembly exception?A:
The Assembly exception covers all files under the Classpath Exception, as well as all files described in the "Exception Modules" document which can be found at http://openjdk.java.net/legal/assembly-exception.Q:
How are the tools that are a part of the JDK, but that are not part of the JVM or class libraries licensed?A:
Tools such as jconsole, javadoc, javac, and others are licensed under GPL v2 + Classpath exception.Q:
How are the regression tests you have released as part of the buildable OpenJDK code base licensed?A:
GPL v2 only. There are a small number of files that have no license in the file itself. These files are all licensed under GPL v2 only, as the entire combined work constituting the OpenJDK code base is under GPL v2. These files are mostly data files used in certain tests, for which no provision has been made for comments, and thus which cannot be modified to include the GPL v2 header.Q:
What about non-Java language files such as manpages, readme files, scripts, and other elements of the JDK? How are these licensed in the OpenJDK Project?A:
These components are licensed under GPL v2 only.Q:
Are there any other licenses used in the OpenJDK code base besides the ones you've already described?A:
Yes. The demo and sample code modules are released under the BSD license. These code elements are intended to be very widely distributed, freely modified and used. Accordingly, we've chosen the BSD license as most appropriate for these uses. Because these components are not part of the JDK but rather are application programs, they need not be under the GPL license because of the Classpath exception.Q:
What about GPL v3? Have you considered using that license?A:
While Sun has been working with the Free Software Foundation as an active participant in the development and review of the GPL v3 license, and while the license is in a late review phase, it is not yet complete. It is Sun's strong desire to advance the open sourcing of its Java technology implementations in a timely manner, so we made the decision to use an existing, established license paradigm rather than wait for GPL v3 to be completed. Using GPL v2 does not indicate anything negative about GPL v3. Sun continues to be very actively and positively involved in this new license's development.Q:
I want to contribute. Do I need to sign anything to get started?A:
Yes. In common with many other F/OSS organizations, Sun requires that contributors to all of its Free and open-source projects sign the Sun Contributor Agreement (SCA) and mail or fax back the completed agreement. A copy of the SCA, complete with FAQ and instructions for submittal can be found at http://www.sun.com/software/opensource/contributor_agreement.jsp.Q:
Will Sun continue to offer the JDK and Java ME source code under a commercial license along with GPL v2?A:
Yes. Indeed, some of Sun's existing licensees will continue to prefer a commercial license over an open-source license for a variety of reasons.Q:
Why will Sun continue to offer the JDK and Java ME sources under a commercial license?A:
Sun has commercial obligations towards its licensees which of course we will continue to satisfy after the code base is open sourced. Sun will continue to work with licensees who want to distribute derivatives of Sun's implementations without the requirement in the GPL to contribute modifications back to the community. Sun's commercial Java technology distribution licenses require licensees to distribute only compatible implementations as determined by the TCK for relevant Java technologies.Q:
What is the process to get a commercial license for the JDK, Java ME implementations, or Java ME TCK Framework source code?A:
For more information on obtaining a commercial license to the JDK source code, please contact Sun Sales .Q:
Will Sun continue to offer its binary bundles for the JDK and JRE?A:
Yes, Sun will continue to offer these bundles under the Binary Code License (BCL). In addition, Sun will offer Distribution License for Java (DLJ) bundles for GNU/Linux and OpenSolaris distributions.Q:
Is Sun changing the terms of the Binary Code License (BCL) for Sun's JRE?A:
Sun is not changing the terms of the BCL. However, Sun is clarifying some of the language. Please refer to the BCL for details.Q:
What about the JCP's Spec License? Is that changing?A:
No, the Spec License is not changing.Q:
Is Sun changing the terms under which it licenses the Java SE TCKs?A:
Yes. Sun will be offering the Java SE TCKs for use by OpenJDK developers and distributors of OpenJDK-based implementations to test for compatibility with the Java SE Specification. Please see the TCK section of this FAQ for more details.Q:
How can Sun have multiple licenses that bear on the same open-source code base? Isn't that no longer "open source"?A:
Because Sun owns the copyright for the open-source code base, Sun is able to license each copy of this code base distributed by Sun, under any license, including a commercial software license. This right is inherent in copyright law. Several Free and open-source communities also follow this practice.Q:
Will Sun offer binary builds of the OpenJDK code base for download? If so, under what license?A:
Not at this time. After extensive consultation with the Java package maintainers for major GNU/Linux distributions, we've learned that these distros almost always build supported components from source code, in order to control patch levels precisely and be able to deliver commercial-grade support on their open-source distributions. Accordingly, we think there would be little, if any demand for binary builds of the OpenJDK code base for such distribution purposes. If there is demand for such builds, such as for application testing by developers, the OpenJDK Community may reconsider this decision in the future.
What do you mean by "encumbered code"?A:
Some parts of the JDK and Java ME implementations include code to which Sun may not hold sufficient rights to release under a license that allows third parties to create unlimited sublicensable derivative works. These rights are necessary to allow release of these implementations under the GPL v2. Those parts of the code for which we don't have these rights are said to be "encumbered".Q:
What do you mean when you say that you are now shipping a "fully buildable" JDK?A:
We have released as much of the source code as possible under the GPL. However, there are encumbered modules in the first buildable release of the OpenJDK code base. In the short term we are providing a separate bundle of binaries compiled from these sources that can be combined with builds of the GPL'd sources to yield a complete, working JDK. We hope to rewrite these components to remove the closed-source code - and we welcome your help!Q:
What are the encumbered components in the JDK?A:
The larger encumbered components requiring binary files for a full build include the font rasterizer, the graphics rasterizer, and the sound engine. Smaller components include some cryptographic algorithms, some SNMP code, and some of the imaging APIs.Q:
How will the encumbered binaries be licensed? Will I be able to redistribute a JDK built from the GPL'd sources and the encumbered binaries?A:
The Assembly exception allows downstream redistribution of such a JDK. For more on this subject see "Licensing".Q:
I'd like to help clear the encumbrances in the OpenJDK code base. How do I get started?A:
We're opening sub-projects under the OpenJDK project on java.net focused on the major encumbrances that need to be addressed so that OpenJDK can be 100% free software. These projects and their URLs are:Q:
Will everything in the Java ME feature phone and advanced OS phone implementations be available in open source?A:
No, there are several encumbrances in these phone implementations. These encumbrances include support for specific phone hardware, graphics engine, sound engine, etc. All of these components and any other encumbered code will not be included in the open source code base.Q:
How will encumbered code in the Java ME code base be managed?A:
Sun is actively negotiating with Intellectual Property (IP) owners to gain the rights to add the encumbered code, if any, to the open source code base. We will try to clear encumbrances with open-source or other reasonable alternatives. Implementations including encumbered components will continue to be made available via commercial license.
Its great that the community has access to the source code now, but what about documentation? What are your plans for providing developers and publishers access to documentation that enables the openness and sharing that are the goals of the open-source Java initiative?A:
Sun recognizes that restrictions on how documentation can be created and disseminated would limit many beneficial activities such as training programs and materials, and added-value third party websites. We are re-examining our Java platform documentation policies with community development in mind and will implement a new policy in keeping with the spirit and enabling the opportunities made possible by Java as free software.Q:
Given that the Javadoc content is embedded in the newly GPL'ed OpenJDK code, and the Javadocs can be generated by running the javadoc tool, aren't the Javadocs now also under GPL?A:
Yes. The documentation that can be generated by running the javadoc tool over the open-source code base is a derivative work of this code base and as such, must also be licensed under the GPL.Q:
So then, is the Java SE Platform Specification now GPL'ed as well?A:
No. Although the Javadocs are the primary documentation for application developers, they form only a small portion of the Platform Specification, which includes several other important, normative documents (prescriptive parts of the standard) including the Java Language Specification, the Java Virtual Machine Specification, and other ancillary specification documents that are referenced from the Javadocs. It is important that there be a single, definitive specification for the Java Platform, and for this reason the complete Platform Specification is not being open-sourced. It remains under the auspices of the JCP.Q:
Where can I see the complete Platform Specification? Under what license is it available?A:
Sun is in the process of finalizing a Platform Specification for Java SE 6. Once complete, it will be endorsed through a JCP maintenance review of Java SE 6, and then published. The Platform Specification is made available under the Java Specification License. The Java SE 6 version of this license can be found at http://java.sun.com/javase/6/docs/legal/license.html.Q:
How will Sun promote redistribution of documentation in ways that foster adoption, while respecting and protecting the Java Specification?A:
As the earlier answer explained, there will always be a single, definitive version of the Platform Specification. However, we plan to create a new "Developer Documentation" bundle that can be licensed for redistribution. Initially this will contain only the Javadocs, but we hope to add other materials such as tutorials and guides later. Links from the Javadocs to other documentation will point back to the relevant documents on the java.sun.com website.Q:
Under what license will this Developer Documentation bundle be offered?A:
The bundle will be available under two different licenses.Q:
Why not use the GNU Free Documentation License (GFDL) or a Creative Commons License? Wouldn't one of these licenses, designed specifically for documentation and written works be more appropriate than the GPL?A:
Since we expect that most redistributions of the Developer Documentation bundle will be incorporated into products that also include source code, we felt that the GPL rather than a documentation-only license would be more appropriate.Q:
Now that the Javadocs will be available under the GPL, how can developers collaborate on improving them?A:
Sun intends to build a new dynamic documentation portal on java.sun.com to bring the power of collaborative development to Java developer documentation. While the specific plans for this portal have not been finalized, we expect it will include features such as:
What's the community governance model for the OpenJDK Community?A:
Over the past six months, Sun's OpenJDK team has been carefully considering alternative governance models, and discussing these with the community. Based on this analysis and these discussions, we're ready to roll out the initial model, and a plan to move the governance model to one of community involvement, with a goal of inclusive, transparent, meritocratic governance. The governance model for the OpenJDK Community will evolve over time, based on community input and participation in the process.Q:
To kick this process off formally, on Tuesday May 8, 2007 at the JavaOne conference, Sun established the OpenJDK Governance Board (GB) by signing the OpenJDK Charter. This is a legal document describing the Governance Board and its roles and responsibilities, and to grant to the GB the powers and rights required to carry out their duties on behalf of the community. The GB:
Who is on the Interim Governance Board? How were they selected?A:
Sun is pleased that the following community leaders have accepted Sun's invitation to join the Interim GB:Q:
What are the additional elements of the OpenJDK Charter? Where can I read it?A:
The OpenJDK Charter is posted at http://openjdk.java.net/legal/chartera. It is a legal document that turns over the governance of the OpenJDK Community to the GB. In addition, the Charter:Q:
Will the Governing Board set technical direction for the OpenJDK project?A:
No. Technical direction for the project will be based on the contributions of the members of the OpenJDK community. The code and technology itself will evolve based on the merits of the committers and other contributors to the code base. The OpenJDK Constitution will include the roles and responsibilities recognized within the community and how these roles are established, as well as procedures for dispute resolution.Q:
Is Sun turning over decisions about the code base itself licensing and such to the GB?A:
No. The GB's role is to build a community in which everyone is empowered to participate in the evolution of the technology. But the Charter does not transfer any title or rights under intellectual property law to an independent organization, nor does it confer upon the GB any right to alter the licensing of the OpenJDK code base.Q:
Does Sun still have a "veto" over decisions that the GB makes?A:
No. Sun does not have a blanket veto, except for over the initial Constitution. Once ratified by the community and approved by Sun, the Constitution can be amended by a process that will be part of the Constitution itself, without Sun's approval. Amendments to the Charter must be approved by Sun, and receive an absolute two-thirds supermajority vote of the GB, but the Interim GB will not have the power to amend the Charter.Q:
Can Sun dissolve the GB and force the election of a new GB?A:
We can't predict how long it will take to create the new Constitution. But there is a one year deadline for the Interim GB to create the initial Constitution before it is dissolved May 8, 2008. In addition, no member of the Interim GB will retain his or her position after an elected GB takes office. If the Interim GB is dissolved before a Constitution is ratified, then a new Interim GB will be appointed by Sun with a new six-month time limit on completion. This process will repeat until a Constitution is ratified. We have high hopes that the newly appointed Interim GB will see a Constitution ratified before the initial time limit is reached.Q:
Can a member of the Interim GB run for election to the first elected GB?A:
While waiting for the Constitution and the first elected GB, can I contribute fixes and enhancements to the JDK? If so, how?A:
Certainly! Based on our experience with the transparent development initiative for JDK 6, we've devised process for handling contributions. Please visit https://openjdk.java.net/contribute for more details.Q:
Who will decide which contributions are accepted to the OpenJDK code base?A:
As with the JDK 6 initiative, the final decision will rest with Sun during this interim period. Once the new Constitution is ratified, we expect that appropriate roles for determining how contributions are incorporated into the code base will be established, along with meritocratic principles and transparent processes to decide on code base changes.Q:
Will Sun always be in control of what goes into the JDK?A:
We are committed to building a thriving community around this code base so that the proven power of open development can be brought to bear on the JDK. Yet we're also determined to retain the ability to ship high-quality releases in a timely fashion, a goal that's of benefit not just to Sun but to the entire Java community. We are confident that these two goals can be reconciled, and look forward to the community's advice on how to respect both of these objectives in making decisions on code changes. Sun is not promising that every bit of code in the OpenJDK project will find its way into Sun's commercial products. But we're enthusiastic about the potential for the community to make the broadly available commercial implementations of Java SE better. After all, that's why we open-sourced the JDK in the first place!Q:
Will there ever be non-Sun committers to the OpenJDK project?A:
Yes! We are very excited about collaborating with non-Sun community members on the code, and as is customary with open-source projects, inviting the best of them to become committers to the code base on equal terms. The process of becoming a committer to the OpenJDK code base will of course be governed by the new OpenJDK Constitution.Q:
Will non-Sun committers to the OpenJDK project be treated as equals?A:
Yes. It is our expectation that both Sun engineers and non-Sun community committers will be governed by the same principles and roles established in the OpenJDK Constitution. Accordingly, non-Sun committers will have all the rights that Sun engineers have. They'll also have all of the responsibilities, including code-review duties and the obligation to adhere to, as well as to assist, the various development practices and processes that help to maintain a high-quality OpenJDK code base.Q:
Will it be possible to contribute code to the OpenJDK community that Sun does not plan to ship in its implementations, such as ports to other operating systems or hardware platforms?A:
Of course. OpenJDK will embrace code contributions that augment the Java SE platform such as with new ports, research projects and other improvements including code Sun will not test or integrate into its own products. Criteria for how contributed code will be deemed appropriate for OpenJDK is still under discussion (e.g., application code will likely not be considered appropriate). Sun plans to identify interim criteria shortly and final criteria will be defined in the OpenJDK Constitution.Q:
This is no different from other open-source projects and code commons, where the community, through governance processes, decides what goes into the commons, but then distributors who construct products and distributions from that commons have the latitude to create targeted distributions that address specific markets and commercial opportunities. We expect that the OpenJDK Constitution will include provisions for how such code can be accepted and what quality, testing, and ownership criteria it would need to maintain to remain a part of the code commons.
Does Sun plan to make its JDK quality test suites available?A:
We're shipping some of our test suites in the first buildable OpenJDK code release. Sun is eager to get the community engaged in working on quality and testing, releasing more of the unit and functional tests, and building new test frameworks. We've established a quality project and portal as part of the OpenJDK Community in order to work closely with the community on testing.Q:
Will Sun allow alternative implementations of components to exist in the OpenJDK code base?A:
As with the question of non-product code in the OpenJDK code commons, this will likely be an integral part of the community and will be governed by the same kind of considerations of quality, testing, and ownership.Q:
What impact do you see open sourcing the JDK will have on bringing Java to platforms that Sun may not be directly interested in supporting? For instance, could the community provide an implementation for a game console? Can a bunch of like-minded engineers simply approach the console manufacturer and offer to compile a JVM for them for free from the OpenJDK sources?A:
Great question - because we think one of the most important benefits of open-sourcing Sun's platform implementations will be the new platforms that will be supported by the community. And to your point - once the complete JDK is available under the GPL, it will be free software, and developers will be able to use it in any way they see fit, as long as they abide by the GPL, including publishing any modifications to the platform they might make, benefiting the whole Java technology ecosystem. We think there are many opportunities to bring Java to new platforms, and neither licensing nor technology really stands in the way in most cases.Q:
That said, there are significant issues with delivering a JRE embedded in a platform such as a game console. The most significant issue is that if the JRE built from GPLed code is distributed by the manufacturer as an integral component of their game system, the entire source code for the game system would need to be made available under the GPL as well. Revealing the proprietary APIs and implementation details of the game system might not be what the manufacturer would wish for. In this case, if they see value in using Java technology to make their game platform more open to application developers, they would likely want to do so under a commercial license from Sun, which would protect their interests.
Beyond the GPL issue, there are significant benefits for a company such as a game console maker to consider a commercial license, including engineering services and support, TCK access and support, trademark licensing as "Java Compatible", and a host of additional benefits. We expect that in most cases, device manufacturers wanting to incorporate a JRE will find the combination of these benefits and the ability to continue to make money from their IP investments compelling enough to do such work under the commercial licensing model.
We're hoping that the open sourcing of Sun's Java platform implementations will take Java technology into places we cannot imagine. With the entire developer community getting complete access to the implementation source code, we expect to see many new ideas, experimentation, and innovation. We also hope to see the best of these ideas formalized and brought back into the platform where appropriate.
What's the Mobile & Embedded community governance model?A:
The Mobile & Embedded community will launch with an interim governance model that will evolve over time. The Sun team has studied many of the existing governance models in the open-source community and has determined what it believes is a good initial model to follow.Q:
The model is based on its founding principles of transparency, participation, compatibility and engineering excellence. It consists of a governing board of 5 members. 2 are permanent seats for representatives from Sun, 1 is appointed by Sun (non-Sun member), and 2 are elected from the membership of the Mobile & Embedded community. The role of the board is to maintain the health of the community by overseeing its affairs and facilitating the alignment between the operations of the community and its established principles and objectives.
The Mobile & Embedded community will be made up of Java Platform Projects (based on JSRs), Java Tools projects (tools, utilities, libraries, etc) and Java application projects (midlets or xlets). New projects can be established in the community by filling out the Project Request forms and meeting the entry criteria. Approved projects are placed in the incubator. A project remains in incubator status until it meets the criteria for becoming an official Mobile & Community project. Project level governance is determined by the project owner.
Can you create a new project within the Mobile & Embedded community?A:
Yes, new projects can be created in the Mobile & Embedded community. New projects get created by submitting a new project proposal on java.net. These newly requested projects that meet the incubator entry criteria get placed in the incubator. To graduate from the incubator to official Mobile & Embedded Community project status, a project must meet certain criteria such as transparency, quality, compatibility requirements, etc.Q:
Can I contribute fixes and enhancements to the phoneME and cqME projects?A:
Certainly! We strongly encourage contributions into these new projects. In order to be able to contribute the following steps needed to be completed:Q:
Who will decide which contributions are accepted to the Mobile & Embedded Community projects?A:
Committers have the authority of submitting code into the source tree. Until an individual becomes a committer, contributors will have to work with a committer in order to get their code reviewed and submitted.Q:
Will there ever be non-Sun committers to the phoneME and cqME projects?A:
Yes! As with the OpenJDK Community, we very much want to collaborate with non-Sun community members on the code. We would hope to make the most skilled participants committers to the code base.Q:
Will non-Sun committers be treated as equals?A:
Yes. As with the OpenJDK project, non-Sun committers will have all the rights and responsibilities that Sun engineers have.Q:
Does Sun plan to make its Java ME quality test suites available?A:
Sun has no plans to make its quality test suites available.Q:
What is the criteria for becoming a full Project in the Mobile & Embedded community?A:
The criteria for becoming a full Project in the Mobile & Embedded community is alignment with the Founding Principles and meeting the necessary legal requirements.
What is the Java brand?A:
The Java brand has two components: its name, Java, and its logo, the Java cup and steam. In addition, there are "sub-brands" that further clarify your use of Java technology and define how a product complies with its brand promise: Java Powered and Java Compatible.Q:
These brands - and their logos - are valued registered trademarks owned, protected, and managed by Sun Microsystems. The Java brand carries with it a very specific value proposition that tech-savvy consumers and IT professionals everywhere recognize - a promise of "Write Once, Run Anywhere", and an expectation of exciting, robust, easy to use applications generated from its code.
Sun Microsystems will continue to own and protect the brand and its value by managing its use. Any product that wishes to use one of the family of Java brands must comply with the associated Java brand program. These are outlined at http://www.java.com/en/about/brand/.
What does the "Java Compatible" logo signify?A:
For both Java SE and Java ME, the "Java Compatible" logo signifies that a platform implementation has been tested against the relevant platform TCKs and has passed, and is a compatible implementation of the platform specification.Q:
What does the "Java Powered" logo signify?A:
For Java SE, this logo signifies that an application is built upon the Java SE platform. For Java ME, this logo is used to signify that a device which embeds an implementation of the Java ME platform is compatible with the Java ME specification. The "Java Powered" logo is thus the primary and preferred logo to designate compatible devices.Q:
Can I call products I create from code I download from your open-source site "Java"?A:
If your product meets one of several program requirements for using the Java brand, including the applicable testing, (see http://www.java.com/en/about/brand/) then you can use the appropriate Java cup and steam logo, according to the guidelines of the brand.Q:
For example, you can say:
Can I use the term "JDK" to describe my product - it's built with code from the OpenJDK Project after all?A:
The trademark "JDK" is Sun's name for the Java Development Kit. Accordingly, it follows similar rules to the "Java" trademark. You may not refer to your product or implementation as a JDK, even if it is based on code you downloaded from the OpenJDK Project. You can use the term "JDK" under Sun's "fair use" guidelines, however. Please refer to Sun's trademark policy for more information.Q:
How do I know if someone else's product is compatible?A:
If a product carries the Java cup and steam logo, and/or uses the term Java Compatible or Java Powered (for devices embedding a Java ME implementation), then it is bound by Sun's trademark and compatibility program rules, and carries the guarantee of a tested, compatible product.Q:
If a product describes a relationship to an open-source Java community and its code, such as "derived from code found at openjdk.java.net" , then it is important you look further into its claims, and ask for more concrete evidence that the device implementation or code has been tested and certified as "Jaba Powered" or "Java Compatible". For instance, you might ask if the solution has been certified by the appropriate TCK test suite.
How can I describe a product I create using code from the open-source site if I don't wish to get it certified by Sun?A:
If you create a derivative product from code you download from one of the open-source Java technology project sites on java.net such as openjdk.java.net , it is not considered "Java Compatible" until it is certified; it is instead, a "derivative work based on the open-source code from the OpenJDK Project." While it may truly be a derivative of Java technology, trademark law only supports use of the word if it's verifiable and licensed by Sun.Q:
Because "OpenJDK" is a trademark of Sun as well, and refers to an open-source code base, project, and community sponsored by Sun for the benefit of the Java ecosystem, you can't call your implementation "OpenJDK", even if you don't change any code. You could, however, say something like "SimonJ, based on code from the OpenJDK project" or "SimonJ, an OpenJDK-based implementation".
Trademark law, however, does support a notion of "fair use" that allows the use of a trademarked word as text under certain guidelines.
When making fair use of a Java trademark, you should acknowledge that Sun Microsystems owns the trademark. The following language is appropriate:
"Java, JDK, OpenJDK, Java Compatible, Java Powered, and ... are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. or other countries."
For a comprehensive description of how and when you are allowed to use the Java trademark, please refer to http://www.sun.com/policies/trademarks/.
What is the Java Verified Program?A:
The Java Verified Program is a wireless industry driven organization that provides a complete testing process for mobile Java technology applications. The member companies consisting of Motorola, Nokia, Siemens, Sony Ericsson, Vodafone Group, LG Electronics, Orange and Sun Microsystems create the testing criteria by which the mobile applications are tested. Those applications that pass the certification testing gain the right to use the Java Powered Logo and a digital certificate to prove the authenticity and integrity of the software.
What are TCKs? What is the JCK?A:
Technology Compatibility Kit (TCK) is a conformance test suite that is used to verify that an implementation of a Java technology conforms to its specification. If an implementation passes all of the tests in the TCK and meets all of the additional Compatibility Requirements defined by that TCK then it is Compatible. The Java Compatibility Kit (JCK) is the TCK for the Java SE Platform; an implementation of Java SE must pass all of the tests in this TCK and meet all of its compatibility requirements in order to be Compatible. (There are also additional TCKs for technologies that can be incorporated into the Java SE platform for example, the BeanInfo, SmartCardIO, JAXB, JAXP, and JAX-WS TCKs).Q:
Why are TCKs important? Isn't this just a detail?A:
Java technology, unlike many other industry standards, includes a mandatory test for compatibility. It is the combination of detailed, industry-led Specifications, complete Reference Implementations, and TCKs that together are the technical and procedural underpinnings to the Java "Write Once, Run Anywhere" compatibility promise that developers and deployers around the world rely on to protect their investment in Java software. With the OpenJDK code base available under the open-source GPL, the TCKs provide the assurance of compatibility that users need to feel confident in using a particular implementation whether developed commercially, or in the community.Q:
Are you open sourcing the JCK?A:
Why aren't you open sourcing the JCK?A:
The JCK is a conformance test suite, and as such, gains much of its value from there being a single, authoritative version against which multiple implementations of the Java SE specification can be tested. If the JCK itself were open sourced, alternative versions of the test could proliferate that might or might not conform to the actual specification or that might interpret the specification differently. With alternative JCKs in use, various implementations might claim to be compatible but in actuality, run Java technology programs differently the opposite of "Write Once, Run Anywhere". Open sourcing the JCK thus is not in the best interests of the Java technology ecosystem.Q:
We recognize the value of community collaboration on the JCK, and hope to make such collaboration a reality as we learn more about how the community uses the JCK in practice, and as we experience first-hand where it could be improved. Right now, we're focused on making the OpenJDK community itself into a powerful force for innovation, and on giving this community the means to test for compatibility.
Will developers have the ability to run TCK tests on components they modify, or run the whole TCK on complete implementations?A:
Yes. Sun has released a license, called the OpenJDK Community TCK License which allows developers to run the Java SE TCKs on OpenJDK-based implementations that are distributed under the GPL. In developing this license, we've made certain that the terms under which we offer access to the Java SE TCKs are legally compatible with developers' obligations under the GPL. The same license terms are applicable both to testing individual components and complete implementations.Q:
Even though it isn't precisely accurate, for the purpose of this FAQ, we'll use the term "JCK" to refer to the entire Java SE TCK, including additional tests. The new license will grant usage rights to everything needed to test for platform compatibility.
Is the license available now?A:
Yes, the license is now available and can be found at http://openjdk.java.net/legal/openjdk-tck-license.pdf. Since there is no JCK for JDK 7 yet, the practical value of TCK access will have to await the release of a buildable implementation compatible with Java SE 6, expected later this year. Sun is working actively within the OpenJDK community to deliver this implementation, and in turn, the community is keen to gain access to an open source implementation that conforms to the current specification. So this is a high priority for both Sun and non-Sun members of the OpenJDK community.Q:
Releasing the JCK is a new departure for Sun and we fully expect that the terms and processes will need to change with community input. We are releasing this version 1.0 of the license now to allow this process to take place before the JDK 6 is made available on OpenJDK. Sun welcomes all comments and questions about this license, and we hope that the discussion can happen within the OpenJDK community. While we are establishing a JCK Access project, we're recommending that this discussion take place on the main discussion list for OpenJDK: firstname.lastname@example.org. You can subscribe by visiting http://mail.openjdk.java.net.
We know there will be a strong temptation for the community to try to backport a compatible implementation of Java SE 6 that could pass the JCK based on the OpenJDK JDK 7 code base. Sun strongly encourages the community to work with us to focus efforts on delivering such an implementation within the OpenJDK community itself. Though it might take a little longer to achieve, we believe that a joint, focused effort will concentrate resources on solving this problem for everyone in a maintainable and integrated way.
What about other Java technology platforms like Java ME and Java EE? Will a version of this new TCK license be made available for these platforms as well?A:
There are no plans to release the TCKs for other Sun Java technologies under the terms of the new license at this time. That said, Sun is constantly evaluating the applicability of innovations across our technologies and communities, and innovations can be procedural and legal, not just technological. If this approach has merit for the other platforms, we will certainly consider it but we are not in a position to comment further on it now.Q:
Who is intended to use this license?A:
In thinking about the problem of verifying compliance with the Java SE Specification, we realized that there are two audiences we need to address:Q:
Am I allowed to create derivative works of the JCK or incorporate JCK tests into other test frameworks?A:
No. The license does not permit modifying or creating derivative works of the JCK. It allows only for use in testing for compatibility.Q:
Which implementations are eligible to exercise the license?A:
Implementations must be substantially derived from the OpenJDK source code and must be distributed under GPL which of course would be a requirement of any implementation making use of code from the OpenJDK code commons (except to the extent that Sun's use of the any license exceptions permits combinations of code under a different license). For some time Sun has offered the Compatibility Testing Scholarship Program as a way for qualified not-for-profits and individuals to gain access to TCK's and support services for the testing of independent implementations of Java technology standards. The TCK Scholarship program will continue, and is the appropriate means for implementations that are not based on OpenJDK to gain access to the JCK.Q:
What do you mean by "substantially derived"?A:
An implementation is "substantially derived" from the OpenJDK code base if it includes a large body of code existing in the code base that does something identifiably significant, or implements some set of APIs in their entirety. The code need not be part of Sun's implementation it only needs to exist in the code base. Obviously, adding one line of code from the OpenJDK code commons to your private implementation does not make your implementation "substantially derived". If in doubt, please ask! If you apply for the license, Sun will, as part of evaluating your application, determine whether your implementation meets this requirement.Q:
What is the procedure for an individual or organization to apply for and receive a TCK support scholarship from Sun, through the JCP?A:
Please see the section "How to apply for a scholarship" on the website.Q:
Is there a charge to exercise the new OpenJDK Community TCK License?A:
The license will be free of charge.Q:
Is this a click-through license?A:
No. To ensure eligibility all applicants must pass a screening process with specific, published requirements established by Sun. This process is intended to ensure that applicants are serious developers or packagers of an OpenJDK-based implementation, or are contributors to the OpenJDK project.. Members of the OpenJDK community will likely need to be SCA signatories prior to applying for the OpenJDK Community TCK License, but it will also be possible for those not participating in the OpenJDK community to become signatories to the license or example, a student research project conducted outside of the OpenJDK community.Q:
We recognize that the application process and requirement for a signature may be difficult for some groups or individuals who might want to exercise the license. We will work with such groups to come up with solutions to this problem over time. Until there is an open source implementation of Java SE 6 available in the OpenJDK community, we expect that we'll be approving eligibility for the OpenJDK Community TCK License on an exception basis.
So, what exactly is the process?A:
We're still figuring this out, and we expect to have a process in place within a few weeks. However, the broad outlines will likely be as follows:Q:
How long does the application process take?A:
We expect this process will take no more than a month from submitting the web form, through granting access to the download site.Q:
I'm part of a team of developers working on an implementation. Can our whole team sign and execute the license agreement as a group?A:
The license agreement includes a parallel signature block to make this possible.Q:
If I choose to exercise the license are there any issues with me working on any other test suite projects?A:
No. The OpenJDK Community TCK License includes a residual knowledge clause which says that you can use what you happen to remember unaided after accessing the TCK under this license. Of course, you must keep the projects separate.Q:
Once I have signed the license and received the JCK, how do I get support for running it and testing my implementation?A:
The JCK is a mature product with extensive documentation. It has been designed for use by non-Sun implementors of the Java SE platform, and has been in widespread use for many years. The JCK engineering team, anticipating a much broader base of users, is working hard to simplify the configuration process and to improve the documentation. Nevertheless, the JCK remains a large and complex software product that can sometimes be difficult to configure and whose output may be difficult to interpret without expert help.Q:
Support for the new OpenJDK community of JCK users will, in the spirit of open-source development, be primarily community-based. A discussion forum will be provided through which JCK users may pose questions and problems and where answers may be provided by other community members. Sun's JCK engineering team, who are looking forward to the opportunity to work with this new group of users, will actively monitor the forum and will make every effort to provide help and support. Over time we are confident that a community of JCK users will develop, and that they will be able to provide a high level of support and to develop FAQs, configuration guides, and other best-practice documentation to supplement the extensive JCK User's Guide.
Sun's Java Licensee Engineering group (JLE) is available for a fee to provide technical support for OpenJDK users of the Java SE TCKs, just as they do for commercial licensees. For more information on this option please inquire with Sun's Software OEM Sales organization at http://www.sun.com/sales/wwsales.jsp.
What is the relationship between the JCK and the JTHarness test harness project on java.net?A:
JTHarness is the test harness that is used within the JCK. It is a general purpose tool which is used by many technologies and projects, not just the JCK. This test harness has been open-sourced as a project within the Java Tools Community on java.net . The project includes a forum area where participants can share information about the test harness and participate in its development.Q:
Implementors interested in certifying their OpenJDK-based implementations of the Java SE platform must use the version of the test harness included with the JCK. This ensures a valid certification process. The test harness reports the test results, including interpreting what it means for a test to "pass" in some cases. If users were allowed to use any version of it for certification, they could potentially affect the outcome of the testing.
If I use the JCK under this license, am I able to publish test results?A:
Yes. In addition, you can make truthful statements about the results, such as how many tests you pass or fail, but cannot make partial or comparative claims of compatibility. Of course, if you do pass and are compatible you are allowed to make that claim. In order to use the term "Java Compatible" and the corresponding cup-and-steam logo, you must pass the JCK, and accept a trademark license, as described below.Q:
Here are some examples of the kind of truthful claims you can make if you pass the TCK:
What do you mean by claims of "partial or comparative compatibility"?A:
Partial compatibility claims are claims such as "90% compatible". Comparative compatibility claims are claims that an implementation is "more compatible" than another implementation. In order to preserve the very high level of compatibility between Java platform implementations, the license treats compatibility as a binary characteristic. An implementation either is, or is not, compatible. There are no degrees of compatibility.Q:
There is no contradiction in prohibiting partial or comparative compatibility claims, and a free discussion among collaborating licensees on a private mailing list as to which tests pass and don't pass, and how close an implementation is to passing. "Only 10 failures remaining we're really close to passing!" on the private list is perfectly fine. The same claim made publically in order to promote an implementation is not.
If I test my OpenJDK-based implementation under the new compatibility testing program and license, and I pass the TCK, can I call my implementation "Java Compatible"?A:
Yes. But you'll first need to accept a trademark license before you can use this Sun brand and trademark subject to the terms of the trademark license, which can be found at http://openjdk.java.net/legal/openjdk-trademark-license.pdf. The trademark license will be free of charge for use on implementations that qualify for testing under the OpenJDK Community TCK License.Q:
Must compatible distributions use the "Java Compatible" brand and logo?A:
No. Compatible distributions are not required to use any Java brand or logo. However, Sun encourages compatible distributions to accept the trademark license and brand their implementation "Java Compatible". By doing so, you identify your implementation as conforming to the Java SE specification, give your potential users assurance that their Java technology applications will run without modification on your implementation, and help to strengthen the Java "Write Once, Run Anywhere" value proposition, benefiting both your own implementation and the entire Java ecosystem.Q:
If my implementation does not pass the TCK, will I be required to say so?A:
No. But of course you won't be able to make any affirmative claims either.Q:
Does the license allow me to test anyone's implementation or only my own?A:
The license only allows you to test your own OpenJDK-based implementation.Q:
If I know my implementation is not yet compliant, may I still use the JCK under the new license to test it, in order to determine where additional work is needed to ensure compatibility?A:
Is the JCK itself confidential?A:
As Sun is not open-sourcing the JCK tests themselves, the JCK remains confidential. The test harness for the JCK is JTHarness and has been open-sourced under the GPL license at https://jtharness.dev.java.net. A read-only version of the JCK has long been available under a special evaluation license. This version remains available for potential OpenJDK Community TCK License licensees to examine, and is available at https://jck.dev.java.net.Q:
If the JCK is confidential and I agree to keep it confidential when I agree to the OpenJDK Community TCK License Agreement, then how can I collaborate with others on community support?A:
The license specifically allows you as a licensee to share comments, questions, results, and relevant portions of the JCK code itself with other licensees. There will be one or more private mailing lists to which you may subscribe to facilitate just this kind of interaction among licensees and with Sun's JCK engineering team.Q:
Private communications between licensees are also permitted, but we do hope that such interactions will be rare. On-list communication allows everyone to benefit from interactions and is more in the spirit of community.
Does the OpenJDK code base pass the JCK?A:
Not at present. The OpenJDK code base contains changes that are early access implementations of features that may become a part of JDK 7, and over time will also likely include research, alternative feature implementations, ports, and other code as separate projects in varying states of maturity, and that may never be compatible, or used in a compatible implementation. While it is one of the OpenJDK Initiative's most important benefits to give developers this early, direct influence over the future, the JCK is about the current, shipping specification. Sun and the community will work together over the coming months to deliver a compatible Java SE 6 implementation through the OpenJDK community.Q:
As is typical for open source communities, once there is an implementation of JDK 6 in the OpenJDK community, it is likely that some snapshots of this code base will be designated as "official" and the community will certify prototype binaries built from these snapshots as compatible, once they pass the JCK. Distributors of OpenJDK-based implementations will be encouraged to pick up these official source code snapshots as the basis for their own binaries which they in turn can certify by running the JCK against them and passing.
Over time, it may be both necessary and advantageous for the JCK tests that are under development for JDK 7 new features and APIs to be made available to the OpenJDK community. Sun is confident that as the community evolves, new and technically interesting opportunities for collaboration around testing and quality will inspire developers to improve both the JDK and the JCK. Time will show how these opportunities can best be realized.
How can I challenge a TCK test that I believe to be invalid?A:
The JCP Process Document requires all spec leads to define a TCK Appeals Process that allows that allows implementors of a specification to appeal one or more tests defined by the specification's TCK. The process that Sun has defined for commercial and independent implementors of the Java SE platform is managed through Sun's Java Licensee Engineering (JLE) group, who receive test challenges from TCK users, and who act as intermediaries between these users and the JCK engineering team. Sun recognizes that implementors are often working to a deadline and that timely resolution of test challenges is critical. Consequently, challenges receive the highest priority within JLE and the JCK team.Q:
OpenJDK implementors of the Java SE platform will be enrolled in this same program, and will be able to submit test challenges through JLE with confidence that they will be investigated diligently and addressed promptly.
JCK users who are not platform implementors, but who have licensed the JCK in order to verify that their individual code changes do not break compatibility, will not need a formal test challenge mechanism. Nevertheless, it's likely that they will have questions or concerns about the validity of individual tests, or about how to interpret test failures. Such questions should be posted to the JCK discussion forum for resolution,. The JCK engineering team will pay particular attention to such questions, since they are very concerned to identify and correct invalid tests.
Can an implementation expand the APIs supported within reserved namespaces, for example by introducing extra packages, say, javax.gtk, and still pass the JCK? Is the java package namespace still off-limits for compatible implementations to extend?A:
This is really a question of whether one can superset the API within the java* namespace. While the GPL license naturally allows such work to proceed, the current restriction on no supersetting within the protected namespace continues to hold for the purposes of passing the JCK and being "Java Compatible". While we understand that there may be some issues regarding package level protections and security, and that it might be easier at times to extend within a package by adding new methods or classes, versus outside of the package, there are some important reasons for not permitting such supersetting within compatible implementations.
Supersetting can hamper the JCP's ability to move things forward in future versions, since there would be no way to know whether someone had used a particular name to superset the API, creating the potential for confusion. This is a very good question, and the answer hopefully will help shed some light on just what we mean by "compatibility".
Will open-sourcing Java SE and Java ME require any changes in the JCP?A:
No. Many open-source implementations of JSRs developed under the JCP are available today.Q:
For example, Sun's reference implementation of JSR 244, Java EE 5, has already been open sourced as the GlassFish application server.
Nonetheless, the JCP itself is constantly reviewing its own rules to ensure they are fair and modern and indeed, is currently engaged in revisions - see below.
Where will Java SE and Java ME specification evolution occur?A:
The JCP defines the process whereby Java technology specifications are created and updated. This will not change. Today, Sun is the Spec Lead for the umbrella JSRs which define the components of Java SE. The Java SE Expert Group works with the Spec Lead to determine which additional JSRs and other minor improvements will be included in each new release of the specification. Final approval for all changes is made by a vote of the JCP Executive Committee. The same process holds true for the Java ME platform.Q:
How can I influence the evolution of Java SE or Java ME?A:
There are several ways to influence the direction of Java SE or Java ME platforms: 1) you can join the JCP and propose or join a JSR which will be included in Java SE or Java ME specifications, 2) comment on such JSR specs during public reviews, 3) work with Sun or a member of a JSR Expert Group to sponsor your ideas, 4) work with Sun in the OpenJDK or Mobile&Embedded communities to develop minor enhancements to the implementation ( i.e., small improvements not warranting a separate JSR). The JCP Program Office has recently sponsored JSR 306 which in part will look into ways to get more individual involvement in JSRs.Q:
How do I join the JCP?A:
Join the JCP by signing the Java Specification Participation Agreement (JSPA). You can find the JSPA and instructions on how fill it out and send it in here: http://jcp.org/en/participation/membership.Q:
My employer won't allow me to join the JCP as an individual. I still would like to participate in Java's evolution, so what can I do?A:
Many employers have policies about employee involvement with outside groups such as the JCP or other standards bodies. There are often good reasons for such policies and your employer should be able to explain them to you. As described above, however, there are ways to participate without signing the JSPA. In addition, one of the goals for JSR 306 is to look for means to increase participation of individuals and to allow more outside influence into the JSR development process.
Still, as a non-member you have many options to participate and influence: all spec drafts are publicly accessible, and you can provide direct feedback at any time to the spec lead and expert group by emailing the comments alias you can find on each JSR's web page.
Last but not least, in order to stay informed about the Java Community Process, you may subscribe to the JCP mailing list: JCP-INTEREST. Visit the web site for more details.
This list will allow you to follow the progress of specification proposals as they go through the Community Process. You will receive messages when new specifications are proposed, when revisions to existing specifications are requested, when specification drafts are available, and when the specifications are finalized.
What's required to participate in the OpenJDK and Mobile&Embedded Communities?A:
Nothing but your time and interest! You can visit openjdk.java.net or mobileandembedded.dev.java.net and look around, join mailing-list discussions, download the binaries and file bugs, or take the source to make improvements and/or use it yourself. It's up to you. You don't even need a java.net user ID to join the mailing lists. Please let us know if you have any suggestions.Q:
Do I need to sign something before making a contribution?A:
Yes. If you want to contribute code for inclusion in the OpenJDK, phoneME, cqME projects, or other Sun-sponsored open-source projects, then we ask that you sign the Sun Contributor Agreement (SCA) first so that Sun has the right to distribute your contribution if accepted. This is a standard practice in many open-source communities. If you've already signed an SCA for another Sun project, this agreement covers your participation in any of the projects discussed above.Q:
Do I give up any rights by signing that agreement?A:
No, you merely commit to sharing your rights in the contributed code with Sun. For more information about the Sun Contribution Agreement please check under the "Licensing" section and read the SCA and SCA FAQ.Q:
What will Sun be doing to attract developers to participate in its JDK open source effort?A:
Sun engineers will continue to interact with external developers through mailing lists, blogs, and 1:1 e-mail conversations as we do now. Each of the component projects in the OpenJDK project will become the source base used for development within Sun of Sun's commercial Java SE products, making the OpenJDK code commons the repository for the reference implementation of the Java SE Specification. Sun engineers associated with those components will also work with developers who show interest. Over the next year or so, Sun will make more of its internal processes, mailing lists, and materials available to the developer community.Q:
What's the holdup on delivering tools and processes for the OpenJDK community? What can't they be made available now?A:
Most of the tools and processes we use are Sun-specific. For example, our source control management and bug tracking systems are proprietary and not usable outside Sun's infrastructure. We're going to change that, but it will take some time. Our processes also need to be documented in a manner that can be understood by people who don't work at Sun. Our top priority has been to get the source code out and now the rest will come as quickly as possible.Q:
What tools will the Mobile & Embedded community use for collaborative development?A:
The Java ME team is utilizing all of the collaborative tools offered on java.net including the source control management system, bug tracking, blogs, forums, mailing lists, etc to enable community development of implementations of Java ME and the Java ME TCK framework.Q:
How are you making the components of the OpenJDK code base available now?A:
These components are available in zip files and also via a read-only Subversion repository. Access to the Subversion repository requires a java.net user ID, but getting one is free and easy. Visit https://www.dev.java.net/servlets/Join for more information.Q:
What will happen to the current JDK projects which are currently licensed under the Java Research License (JRL) on java.net?A:
Sun will continue the JDK6 and JDK7 projects under the JRL license until an implementation of these specifications can be built from the OpenJDK code commons with unencumbered code. Afterwards we will determine if there is any interest in the community for continuing this project. The J2SE 5.0 source code will not be released under an open-source license, and the "Tiger" Project will continue to be available, offering this code base under the JRL.Q:
Are there any restrictions on use of the code base for residents of countries on the U.S. Government's export embargo lists?A:
Yes. Unless licensed by the U.S. Government, export and reexport to embargoed countries of items subject to the Export Administration Regulations, including use, are prohibited.Q:
How do I make a suggestion or comment about Sun's open-source JDK effort?A:
Use the general feedback mailing list on openjdk.java.net.
What are the remaining key steps that Sun and the OpenJDK community are planning to take to continue progress in meeting the goals of the initiative?A:
While we've made tremendous progress in delivering a fully buildable JDK from the OpenJDK code commons, established an interim governance process, begun to develop a process for compatibility testing, and started building out the infrastructure of the community, there is much left to do. Here is a partial list of some of the projects and milestones planned for the OpenJDK community. Our goal is to get these done in the next year, but we aren't able to guarantee that all of this will happen in that timeframe without help from people outside of Sun. Sun is committed to continued rapid advances for the OpenJDK initiative.
Have you been engaging with the non-Sun Java SE platform communities such as Apache Harmony, GNU Classpath, and Kaffe?A:
The Java developer ecosystem has a lot of very smart, experienced, community-savvy people who are passionate about the platform and eager to help. We've been in contact with these projects over the last few years, but in much more regular contact during the last few months. We've been talking with people like Geir Magnusson of Apache Harmony, Dalibor Topig of Kaffe, and Mark Wielaard of GNU Classpath to test ideas and get their perspectives. We are very grateful to all of these people for the help and advice they have so generously and graciously offered.Q:
Are you planning to work with these communities directly?A:
The Java ecosystem can support multiple implementations. Choice and differentiation keeps both commercial and open-source implementations on their toes, and we're not expecting any of the existing open-source Java SE or Java ME implementation communities to "close up shop" now that the JDK and Java ME implementations have been open sourced. It wouldn't be good for Java technology if they did!Q:
But we do hope that developers who are working in these and other open-source communities will consider joining the OpenJDK Community, the Mobile and Embedded Community, and the GlassFish Community (as, indeed, some Java EE implementors have already done). We're confident that developers will feel free to contribute to multiple projects, and through participation, allow good ideas to combine in new and interesting ways. Ultimately, we're hoping that the communities and implementations are differentiated by technology, not by license or ideology, for the betterment of the Java ecosystem as a whole.
At any rate, we hope to maintain a friendly, professional, and mutually beneficial relationship with all open-source Java SE platform development communities, and we look forward to finding ways to collaborate. We're especially pleased that Dalibor Topig has agreed to serve on the interim OpenJDK Governing Board.
What impact will the choice of the GPL license have on your relationships with other open-source Java SE and Java ME implementation communities?A:
Because of the complexities of open-source licensing, not all open-source licenses are compatible. This means that unfortunately, once you choose a particular license, you close off collaboration that involves combining source code with communities using incompatible licenses. For example, when we chose the GPL as the basis for Sun's open-source Java SE implementations, we made it easy to combine the open-source JDK code base with other GPL-licensed code bases such as GNU/Linux, GNU Classpath, Kaffe, GNOME, and others. At the same time we made it hard to combine the code with projects licensed under the Apache Software License V2, such as the Apache Harmony project, because of license incompatibilities. By using the Classpath licensing exception we hope we have gone as far as we can to allow all Free and open source software to benefit from the OpenJDK Project code base.
We knew by selecting GPL that we would not please everyone. We picked this license because it tends to drive innovation into the open, and this open innovation will help to maintain and enhance the compatibility promise of Java technology. This license is also compatible with one of the largest and most influential open-source communities - namely, GNU/Linux - to broaden the Java developer community and enable it to enter new markets.