What is the status of the OpenJDK Project and Community as of JavaOne, 2008?

A:

The OpenJDK Project and Sun's open source Java initiative have continued
to deliver on the central goals outlined when Sun began to release code
for its Java SE implementation under the GPLv2 license. Now, 18 months
later, OpenJDK-based implementations are appearing in the Free software
repositories of major GNU/Linux distributions. A dynamic, active
community of Sun engineers and Free Java developers collaborate on a
broad range of packaging, porting, language and implementation projects.
The community's governance, while still in its interim phase, is running
smoothly. The primary goal of bringing Java technology to places it
hasn't been has started to be realized, and the community is on the
verge of delivering a 100% Free software, compatible source base that
can be a foundation for innovation for many years to come.

What has happened in the OpenJDK Project since the release of a fully buildable implementation at the 2007 JavaOne Conference?

A:

The past 12 months have been very busy, with Sun and the Community
working together to tackle many of the most challenging remaining tasks
in delivering a fully free, compatible implementation of Java SE.

Specifically:

On the first day of the code release, the Community demonstrated its enthusiasm for open
source Java technology, when the Gentoo GNU/Linux distribution released an
OpenJDK-based ebuild only 5 hours after the code became available, and the Fedora
project released a source RPM only 18 hours after the announcement by Rich Green on the
first day of JavaOne 2007.

One month later, on June 7, the Fedora project initiated "IcedTea", an experimental patch
set to remove the binary plugs from OpenJDK and replace them with free software alternatives where possible.

On August 9, 2007, Sun announced the OpenJDK Community TCK
License, which gives OpenJDK-based implementations distributed under
GPLv2 the ability to gain access to
the Java Standard Edition Technology Compatibility Kit (TCK), known as
the JCK, and test for
compatibility. Compatible implementations may then gain access to the
"Java Compatible" brand.
Both JCK access and access to the brand are free of charge for
implementations meeting the requirements of this license.

On November 5, 2007, Red Hat announced that they had signed the Sun Contributor
Agreement as a corporation, joined the OpenJDK Community, and also executed the OpenJDK
Community TCK License, demonstrating the commitment of a mainstream GNU/Linux distribution
to Java compatibility and the OpenJDK Community.

In December 2007, Sun completed the process of moving its existing source code
repositories into a new, modern source code management system called
Mercurial. Two months later, on
February 27, 2008, these Mercurial repositories became read/write repositories, making it possible
for the first time for developers outside of Sun to collaborate as equals with Sun engineers on the code.

On February 14, 2008, a new project opened within the OpenJDK community: OpenJDK 6.
This code base closely matches the specification for Java SE 6, with as few differences as
possible and the goal of eventual full compatibility. This implementation is fully Free software,
with no required binary plugs to build, stable, and intended to be built and integrated into GNU/Linux distributions.

By the end of April, through the hard work of both Sun engineering and the F/OSS
community working in both OpenJDK and IcedTea projects, fewer than 30 JCK failures remain in
fully free implementations built from OpenJDK 6 sources, and only the sound engine remains as a significant encumbrance.

As of JavaOne 2008, both the Ubuntu 8.04LTS (Hardy Heron) and
upcoming Fedora 9
releases include a 100% Free software implementation based on the
OpenJDK source code. The Ubuntu implementation is in the Ubuntu Universe
repository.

Fulfilling its promise to the world exactly one year later, Sun released
a fully buildable implementation of the JDK in the OpenJDK Community.

Specifically:

Sun announced that almost all of the JDK was available under the GPL 6.5 million lines of
code, one of the largest and most important contributions to the Free Software community in history.

In conjunction with the NetBeans 6 preview release, Sun created
pre-built Netbeans
projects to make it easy and intuitive to dive into the OpenJDK code
base, making NetBeans and Sun Studio the gateways to participation in
the OpenJDK project.

Sun announced the formation of the OpenJDK Interim Governance Board
with the charter
to write and gain ratification for a Constitution for the OpenJDK
Community, based on transparency and an open, meritocratic process. The
IGB invites active participation in this process, with the goal that
OpenJDK governance will be representative of a broad and inclusive
consensus reflecting the will of the whole community.

Sun created a clear process for OpenJDK-based implementations of
Java SE to test for
compatibility starting with implementations of Java SE 6, and once
certified, to brand their implementations "Java Compatible" while still
meeting all of their obligations under the GPL. This process will
advance the "Write Once, Run Anywhere" promise of Java Compatibility
into the Free and Open Source software world, and guarantee that the
innovations made possible by OpenJDK remain forever available to all.

Sun announced a one year roadmap for the OpenJDK initiative,
including clearing the
remaining encumbrances, open sourcing an implementation of Java SE 6
and associated deployment code, implementation of the compatibility
testing and branding program, and establishment of the governance and
contribution model for the community.

Following on to Sun's November 13, 2006 announcement 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
delivered 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.

After another year of effort, the community can be proud of its
accomplishments: virtually all encumbrances cleared, OpenJDK 6 in
several GNU/Linux distributions, Red Hat having signed the OpenJDK
Community TCK license and with a working JCK test bed, and a broad range
of new Groups and Projects actively hacking on the code base and
advancing the cause of Free Java technology.

Open-source, compatible Java has gone from a long-standing dream of
developers worldwide, to concrete reality in just two years of intensive
effort. 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.

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 6 and 7 Projects in which the
open-source code base lives are part of this community.
Through the OpenJDK Projects, 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.

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.
At JavaOne 2007, Sun open sourced most of the remaining components of
the JDK, with the exception of a few encumbered components.

Specifically, the following components have been open sourced under GPL version 2 plus the Classpath Exception:

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.
A few parts of the OpenJDK source code are licensed under other open
source licenses such as the Apache license. An exception has been added
to the GPL code to allow this open source code to be co-bundled with GPL
code without concern of license restrictions. For more information on
the Assembly Exception , please see the License section in this FAQ.

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.
Over the last half of 2007 and first months of 2008, Sun engineers in
collaboration with developers working on the IcedTea project and other
Free software Java implementations have systematically cleared most of
the remaining encumbrances, either by reimplementing those components,
or obtaining the permission of the original owners of the encumbered
code to release it under the GPL.
As of the end of April, 2008, there is only one significant encumbrance
left the sound synthesizer for the Java sound APIs. In addition, there
are several color profiles used in the imaging APIs that are also
encumbered.

Karl Helgason, a Free software developer with expertise in sound synthesizers, is building a replacement for the
encumbered sound synthesizer
in Java. This synthesizer is nearly complete. Red Hat engineers are
working on coding the remaining color profile tables as well. Sun
expects the last encumbrances to be cleared, and a fully Free software
and compatible implementations based on OpenJDK to pass the JCK before
the end of 2008.

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.

Customers looking for extended support subscriptions to Sun's commercial
implementations have a new offering that more than doubles the support
life of older versions, offers additional enterprise deployment
features, and provides faster access to critical security and stability
updates, called
Java SE for Business
For additional development and deployment support options, please visit
http://sun.com/javasupport.

Will Sun's commercial JDK releases be built from the open-source code?

A:

Yes, for the most part.
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.

Which version of the JDK do these components come from? Are you open sourcing the latest code?

A:

New development on the components of the JDK is being done on builds of
JDK 7, in the OpenJDK 7 Project. JDK 6 is the current shipping
production release, and is stable.
JDK 7 is the next feature release where all the action will be for
innovation and new capabilities.

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 13 years to insure this stability, based on very tight
control over changes.
The new OpenJDK 6 code base released by Sun is based on a similar
disciplined process for integrating essential stability, security, and
compliance changes. This more stable code base is specifically designed
to be built and supported by GNU/Linux and other open source operating
system distributions and is intended to be 100% Free software. Sun hopes
that GNU/Linux distros will be able to build binaries that are
compliant with the Java SE 6 specification and able to pass the JCK,
with commercial quality. While functionally equivalent, OpenJDK 6 is
derived from OpenJDK 7 b20 and does not correlate directly to Sun's
commercial JDK 6 builds, and does not include all the changes present in
JDK 6 update releases.

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.

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.

Sun announced the formation of an Interim Governance 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, at JavaOne 2007. The IGB invites 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.

Isn't the IGB supposed to have created the new Constitution over the course of the last 12 months? Is there a problem?

A:

The IGB was in fact chartered with the task of creating a new
Constitution over a one year time frame. But during the past 12 months,
it has become clear that while a Constitution would be a very worthwhile
and important guarantee of community involvement and influence, in
practice the issues with the code, such as encumbrances, portability,
and packaging are far more pressing. The interim governance model has
been working very well, and there have been no real issues in the day to
day operation of the OpenJDK Community and the participation of its
membership. So the creation of the new Constitution has been delayed,
while other more pressing issues are addressed. We expect that in the
next year, as the code becomes the established Free software Java
implementation for F/OSS operating systems, that governance and the new
Constitution will become more important again and the IGB will complete
its work.

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 has Sun made the JCK (the Java SE TCK)
available, and provided 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
has established 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.

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, the
application developer project, the SunSPOT project, and many others. It
is a vibrant, active community for everything mobile and embedded, with
over 135 projects, forums, blogs and news for both application and
platform developers alike.
It is also a center for collaboration and joint community exchange, with
such important Java ME communities as Vodafone Betavine, CableLabs,
Telenor, and more.

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.

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.
In addition, Sun has open sourced in the past 12 months a number of
other testing and verification tools, including the SigTest project for
signature and API conformance verification testing. SigTest is under
GPLv2 with the Classpath Exception.
We believe this project can help to standardize the industry on a single
framework to simplify the API signature testing process. In addition,
Sun has open-sourced the Java Device Test Framework, its foundation for
quality and functionality testing. This project enables developers to
create new tests, reducing implementation variation and enabling their
applications to run across multiple devices.

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.

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.

The phoneME project is where Sun develops 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.

On April 10, 2008, Sun released its signature testing and API
conformance tool, called SigTest. The SigTest tool makes it possible to
easily compare the signatures of two different implementations of the
same API. It verifies that all of the members are present, reports when
new members are added, and checks the specified behavior of each API
member. Originally developed to help in the creation of TCK test suites,
it has since evolved into a general purpose tool that can be used to
compare any two implementations of an API to determine their
differences. The SigTest Project, while considered part of the Mobile
and Embedded Community, is hosted on java.net as a separate project at
https://sigtest.dev.java.net/.

The Application Developer project provides resources to developers and a
place to engage in the development of open-source Java ME applications.
This project is also a home to open-source Java ME application demos and
sample code.

NetBeans Integration

How can developers use the NetBeans IDE to get started in working with this code?

A:

Sun has created pre-built NetBeans projects and incorporated this
project metadata directly into the 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

The Java platform is 13+ 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.

At the same time, the Free software and open-source communities have
been 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.

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 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 has made us confident that when
we open-source Sun's Java implementations, the platform benefits, and we
can better balance the needs of community with those of customers, end
users, and licensees.

Overall, we feel that caution is appropriate for a technology that
affects the lives and livelihoods of hundreds of millions of people
around the world. But after much reflection we feel that we have chosen
the perfect time to take the next step with the Java platform. The
subsequent events in the two years since we first announced our
intention have only reinforced our decision.

Because volume wins. Open sourcing Sun's Java SE implementation has
lowered barriers to adoption in markets where open-source software
leads. As new markets adopt Java technology, developers discover new
opportunities. More applications. Innovations that leverage the
industrial strength foundation of Java to deliver valuable new products
and services. And developers are now 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.

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:

You can adopt Sun's Java technologies with full confidence. Java SE will be freely
available - subject to the market forces that drive competition, reduce price and speed innovation.

Whether you value Free and open-source software for
philosophical or economic
reasons, want more flexibility, appreciate the quality that transparency
brings, or want to know you have ultimate control over your investment,
you can adopt the JDK knowing that you'll gain these advantages.

With the rock-solid, high performance JDK implementation from
Sun under the same
open-source license used by GNU/Linux distributions, you can expect
Java technology to find its way onto new platforms, be leveraged for new
applications and infrastructure, and be the foundation of tomorrow's
most exciting new products and web technologies.

Your investment in Java technology will become even more valuable as
open-source speeds innovation, spreads adoption, and carries the
platform to places it couldn't previously go.

Enterprises and organizations that have selected OS distributions based on GNU/Linux,
OpenSolaris, and other open source OSs as preferred for deployment.

In order to gain the benefits of commercial support, and predictability,
these customers may still choose to use Sun's commercial distribution
of the JDK or JRE in conjunction with a support contract. However, they
might not consider the commercial product if the open-source version
were not also available as an alternative. In other words, a customer's
investment in Java technology is no longer dependent on Sun to support
and maintain it.

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.

Now, with the advent of OpenJDK 6,
mainstream GNU/Linux distributions such as Ubuntu and Fedora are
packaging implementations of the OpenJDK code base 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.

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]

By open sourcing these implementations, handset manufacturers can
leverage the common code base to reduce their development costs.

Both application developers and operators 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 benefit from lower porting, testing and
maintenance costs.

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.

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.

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:

License: GPL makes proprietary forks less likely, as all changes must be published.

Branding: the Java trademark and logos are for compatible implementations only.

JCP: the JCP's role as the governing body for Java standards and evolution is not changed
by this move.

Community Development: Sun's experience in building strong communities means
developers will likely find the governance and infrastructure to their liking.

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.

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.

The right to make modifications to the source code without putting those modifications
back into the open-source code commons.

The right to use the "Java Compatible" logo for compliant custom implementations.

Porting services.

Custom development and engineering support services.

Upgrades and updates to the source.

Performance tuning services.

Binary support.

Testing services, including TCK testing.

Training.

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.

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:

The economic advantages of the open-source business model through a larger range of the stack.

Recognized "gold standard" Java SE and Java ME implementations on which the
open-source communities are eager to innovate.

Choice of GPL license that maximizes the value of the
open-source code commons and
maximizes incentives for compatibility, while creating an opportunity
to monetize commercial licenses and support services for licensees.

The ability to tap many of the key architects and creators of Java technology, including for
support and tuning services.

Systems optimized to run Java applications with superior throughput, power, and space characteristics.

Development tools including NetBeans and Sun Studio that deliver increased productivity for developers.

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:

Experience at both understanding and balancing the needs of the diverse and complex Java ecosystem.

Unmatched developer outreach and community development expertise.

World-class ability to combine rigorous, enterprise-class
development processes and
open-source transparency, bringing together the best of community
development with top-quality, on-time delivery of commercial products.

Proven success at delivering scalable community infrastructure that manages the largest
open-source projects on earth.

Vision and commitment to participation, transparency, open development, and collaboration.

Deep understanding of F/OSS community concerns and aspirations, and a practical
perspective on balancing the needs of community with the interests of customers.

Best practice policies and procedures for taking large code bases open source, balancing
concerns and monetizing adoption and ubiquity, all while respecting intellectual property rights.

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.

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.

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.

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.

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.

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.

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.

How can you ship the JDK with binary-only elements then? You said there were encumbrances.

A:

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.

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.

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.

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.

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 and other open source licenses that are not
compatible with GPL. 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 and to minimize dependencies on
non-GPL open source licenses, to eliminate the need for the Assembly
exception for any purpose other than to allow for the Classpath
exception.

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.

Sun had several objectives in mind in choosing the license for the JDK source code. We wanted to:

Drive more adoption of Java SE, especially within GNU/Linux distributions.

Minimize the likelihood of incompatible forks.

Engage a broad cross-section of the open-source communities.

Protect and enhance the investments of those who have licensed and chosen to support
the Java platform.

After extensive analysis and consultation with experts both inside and
outside of Sun, we determined that of the choices available, the GPL v2 +
Classpath exception license paradigm is most likely to achieve these
objectives. We know that this choice is unlikely to please everyone but
we believe it offers the best balance of opportunity for developers and
Sun.

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.

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.

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.

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".

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.

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, and as owner of the trademark, Sun reserves the right to use the
mark
"Java" for its own products. 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.

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.

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.

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.

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.

At this time Sun is not planning to distribute the OpenJDK code under
GPL v3. That said, Sun has been deeply involved in the development and
review of the GPL v3 license. This license has a number of interesting
and positive characteristics.
Using GPL v2 does not indicate anything negative about GPL v3.

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.

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.

Yes. Sun offers 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.

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.

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.

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".

What do you mean when you say that you are 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!

As of JavaOne 2007, the larger encumbered components requiring binary
files for a full build included the font rasterizer, the graphics
rasterizer, and the sound engine. Smaller components included some
cryptographic algorithms, some SNMP code, and some of the imaging APIs.
As of JavaOne 2008, the only remaining encumbrances are the sound
engine, SNMP code, and a few data configuration files within the imaging
APIs. The SNMP code is not strictly required by the specification. So
nearly all of the encumbered components have been replaced by Free
software alternatives.

I'd like to help clear the encumbrances in the OpenJDK code base, or
improve the quality and performance of the replacement code already
contributed to the project. How do I get started?

A:

We've opened sub-projects under the OpenJDK project focused on the major
encumbrances that need to be addressed so that OpenJDK can be 100% free
software, with very high quality. These projects and their URLs are:

Each of these projects includes a mailing list with Sun engineers
participating, and additional information on the specifications and
requirements for a replacement implementation that would pass the JCK
and be a suitable replacement for the encumbered code.
Working on creating or improving the Free software replacements for
these encumbered pieces is one of the most valuable initial
contributions you could make, so please consider joining these projects
and helping make OpenJDK completely free software.

When will an OpenJDK-based implementation be
available in my favorite GNU/Linux or other open source OS distribution?
On my favorite hardware platform?

A:

It depends on just how much work it will take to integrate the code with
the packaging system, and underlying OS APIs. In the case of GNU/Linux
distributions running on already supported hardware platforms such as
x86, the actual effort is primarily one of packaging for a particular
distribution's installation and package management system.
This is non-trivial, but has been done for several of the most popular
packaging formats and systems already, including the RPM and .deb
formats. For unsupported hardware, new OSs or variations on supported
OSs with significantly different APIs, the work to port an OpenJDK-based
implementation is much greater. It includes specific hardware-dependent
modules within the HotSpot virtual machine and interface libraries, as
well as porting Class library elements that talk to the underlying
system.

The Porters' Group in the OpenJDK Community is where discussion and
projects for creating new implementations lives. Please visit
http://openjdk.java.net/groups/porters/ for more information and to meet others interested and expert in this topic.

How does an OpenJDK-based implementation get
accepted into a GNU/Linux distribution anyway? Does Sun have commit
rights within popular distros?

A:

Sun engineers, dedicated F/OSS developers like those who have created
the IcedTea Project, and members of GNU/Linux distros responsible for
packaging Java implementations have been closely collaborating to build,
package, and check in implementations based on OpenJDK 6 code into both
Ubuntu 8.04LTS
"Hardy Heron," and into Fedora 9. It's a group effort, with each member
of the team playing their role and working with others to bring Java
technology to these distros. We anticipate that the same pattern will
repeat itself with other popular GNU/Linux distributions. In some cases,
the work done to package an implementation for one distribution can be
almost completely reused for many others using the same package format,
so there is a lot of leverage to this model.

Is there a browser plug-in and Java Web Start
(JNLP) handler available for the OpenJDK based implementations in Ubuntu
8.04 and Fedora 9?

A:

Thanks to the hard work of the IcedTea team, these distros include a
browser plug-in based on gcjwebplugin (part of the GNU Classpath
project) and a JNLP handler based on the Netx project on SourceForge.

What are the plans for open sourcing Sun's plug-in and Web Start implementations?

A:

As part of Sun's Java SE 6 6u10 update release, we're busy adding a
number of new deployment features to Sun's commercial implementation
that are designed to improve the consumer download, install, and usage
experience for the JRE. Part of this effort are new plug-in and Web
Start implementations built from the ground up to replace the existing
code, which is both complex, and hard to open source.

Once the 6u10 release ships, we expect that the new features will be
forward-ported to OpenJDK 7 and some capabilities, like the plug-in and
Web Start implementations may also be open sourced for OpenJDK 6. The
specific plan and roadmap for this work is still being decided.

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.

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.

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.

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.

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.

Under what license will this Developer Documentation bundle be offered?

A:

The bundle will be available under two different licenses.

A commercial license that permits redistribution, but does not allow
for modification or
creation of derivative works. This license will be most useful for
publishers who are seeking to include the bundle with other material as a
combined work, and who would prefer not to offer the entire work under
the GPL.

The GPL, as mandated by the inclusion of the Javadocs in the
GPL'ed OpenJDK code
base. We expect a GPL-licensed Developer Documentation bundle will be
most attractive to distributors offering an OpenJDK-based
implementation.

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.

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:

Annotations

Code samples

Discussion forums

Translations

Links to external references

This will be a significant new resource for the entire Java community to
use and an exciting new way for developers to participate.

The OpenJDK Community is operating under the interim governance model
established at JavaOne 2007. There is a plan to move the governance
model to one of even more 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.

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:

Will consist of five people, two employees of Sun and three from the Community, elected by
a democratic process.

Sun will initially appoint an Interim GB with this composition
whose duties will be to
construct a Constitution for the OpenJDK Community, and get this
Constitution ratified by a democratic vote of community members.

Once the new Constitution is ratified, the Interim GB will hold an election according to the
new Constitution and will be replaced by a duly elected board.

Sun is pleased that the following community leaders have accepted Sun's invitation to join the Interim GB:

Doug Lea
is a professor at SUNY, Oswego. He is an expert in object-oriented
software
development, distributed, concurrent, and parallel object systems, and
software reusability.
Doug was the Spec. Lead for JSR-166, Concurrency Utilities in Java SE.
He is a member of the JCP SE/EE Executive Committee and is a Java
Champion.

Dalibor Topic
has been a graduate student at the University of Saarland, Saarbr|cken,
Germany and worked at the Max-Planck Institute for Computer Science. He
is a well-known and outspoken thought leader for the free software
movement, and a co-maintainer of the Kaffe.org virtual machine project. A
member of the Free Software Foundation, Dalibor participates in the GNU
Classpath project, and has been instrumental in bringing several
Java-oriented free software projects together including GNU Classpath,
Kaffe, and GCJ. Dalibor is now an employee of Sun, with the role of
Java F/OSS Ambassador.

Fabiane Biznella Nardon
is currently the CTO of ZILICS, a Brazilian Healthcare Information
Systems provider with large distributed projects deployed in countries
like Brazil and Angola/Africa.
She was the architect of the Sao Paulo City Health Care Information
System, a Duke's Choice Award winner in 2005. Fabiane is also the
java.net JavaTools Community Leader and a Java Champion.

Mark Reinhold
is Chief Engineer, Java Platform, Standard Edition, Sun Microsystems,
Inc.
His past contributions to the platform include character-stream readers
and writers, reference objects, shutdown hooks, the NIO
high-performance I/O APIs, library generification, and service loaders.
He was the lead engineer for the 1.2 and 5.0 releases, the specification
lead for Java SE 6, and is currently leading the engineering team for
the OpenJDK project. Mark holds a Ph.D. in Computer Science from the
Massachusetts Institute of Technology.

Simon Phipps
is Chief Open-Source Officer of Sun Microsystems, Inc. and is an
advisory
member of a number of open source communities including the GNOME
Foundation, OpenSPARC, OpenSolaris and the China Open Source Promotion
Union.
He was also instrumental in the introduction of the Java platform to IBM
in 1995.

The Interim GB membership includes leaders from the Java community who
are likely contributors to the OpenJDK project itself. We felt it was
important that the members of the GB have a concrete knowledge of the
platform, credibility in the community based on their established past
contributions, and a real stake in the outcome. We're pleased that Doug,
Dalibor, and Fabiane will be joining the two members from Sun in
driving the bootstrapping process for OpenJDK governance, and are
confident that the resulting Constitution will both reflect the will of
the community, and will be the foundation on which the long-term
prosperity of the project and its developers will rest.

Describes the makeup of the GB, and the bootstrap process going from an appointed
Interim GB to an elected GB.

Assigns the task of constructing and ratifying the OpenJDK Constitution to the Interim
GB, and outlines the general shape of the Constitution.

Establishes the GB as the final arbiter of conflict and interpreter of the OpenJDK Constitution.

Describes the procedural processes and timelines for insuring that the Interim GB
completes its assigned role.

Provides for an amendment process for the Charter itself.

The Charter is a short, high-level document that grants the GB the
powers it will need to perform the actual tasks of governing the
community. It doesn't establish the rules themselves. That is for the
community, in conjunction with the GB, to do in drafting a Constitution.

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.

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.

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.

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.
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. Given the current status of the Constitution effort, it is
planned that Sun will announce a new Interim GB soon.

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
http://openjdk.java.net/contribute for more details.

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.

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!

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.

In the interim period, two new non-Sun developers have been voted into
Membership: Neal Gafter (Compiler Group) and Doug Lea (Core Libraries
Group). There are also several Members of OpenJDK Groups who are no
longer Sun employees but who retain their Membership, and so gradually
there are non-Sun committers becoming a part of the project. We expect
more non-Sun committers to be voted into Groups, and for this process to
accelerate in the coming year.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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/.

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.

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.

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.

"created my application using a Java Compatible implementation and it is Java Powered"

For Java SE, the Java Powered logo requires that you be a member of the
Sun Partner Advantage Program and ship a Java-based application for Java
SE 1.4 or later. The Java Compatible logo program for Java SE requires
that your implementation passes the relevant TCKs for Java SE, and that
you apply for the logo. If however, you choose not to pursue and meet
the requirements of a Java brand program, then you are not granted
rights to use the Java name or its logo. Instead, your use of the word
Java is limited only to what is legally referred to as "fair use." (See
question below). Please note that under US law, and other jurisdictions,
there is no "fair use" of a logo, and you must have a license.

Can I use the term "JDK" or "OpenJDK" to describe my product - it's built with code from the OpenJDK Project after all?

A:

The trademarks "JDK" and "OpenJDK" are Sun's names for the Java
Development Kit, and for the open source code base and community in
which the JDK is developed.
Accordingly, these marks follow 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 terms "JDK" or "OpenJDK" under Sun's "fair use" guidelines,
however. Please refer to
Sun's trademark policy
for more information.

But I've created an implementation based almost
entirely on OpenJDK, and packaged it for my GNU/Linux distribution.
Surely you want me to call this implementation "OpenJDK", otherwise how
will people know that they are getting a build of the project's code?

A:

Indeed, this is where the requirements of trademark law run head-on into
the needs of the community, and developers. Sun is trying out a new
approach to trademarks associated with F/OSS projects with OpenJDK. If
you have created an implementation based on OpenJDK code, which is a
substantially complete implementation in which the vast majority of the
code in your implementation is identical to the OpenJDK code base, then
Sun will give you permission to use the
"OpenJDK" trademark for package names and version strings.
This means that when you package an implementation based on OpenJDK, you
can use
"OpenJDK" or "openjdk" as part of the package name. It can appear in
your package manager's list of available packages as well, and other
packages can name it as a dependency. You can also mention your package
on a website as part of a list of packages included in your
distribution.

Sun is not granting you the right to use the "OpenJDK" trademark in any
other way. So you cannot, based on this limited permission, make
statements on your web site or in other marketing materials such as:

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.

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.

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."

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.

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).

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.

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.

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 JCK tests on components they modify, or run the whole JCK 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.

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.

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.
Sun welcomes all comments and questions about this license, and we hope
that the discussion can happen within the OpenJDK community.
The Conformance group has been established for just this purpose, and
for technical discussions of how to set up a test bed and run the JCK
itself. Please
visit
http://openjdk.java.net/groups/conformance/
and also subscribe to the conformance-discuss mailing list to join the conversation.

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.

In thinking about the problem of verifying compliance with the Java SE
Specification, we realized that there are two audiences we need to
address:

Those who modify OpenJDK sources and who want to ship a compatible implementation,
such as GNU/Linux distributors.

Individuals who participate in OpenJDK development and who want to verify that changes
they make don't break compatibility.

We've created a license that is appropriate for both of these audiences.
That said, we don't think this license is appropriate for everyone, and
there is an application process that will assess whether to grant the
license or not.
If you're a group working to ship a compatible implementation, we would
like you to show that you have a credible implementation that has a
realistic chance of achieving compatibility.
If you're an individual developer, we will expect you to show that
you're working in an area of the code where compatibility might be
jeopardized by changes. We understand that you may be curious about the
JCK, and that you might want to apply for a license just to study it
rather than to use it in your work.
If you are curious, please download the read-only version of the JCK
from
https://jck.dev.java.net/, where it is accessible via a simple click-through license.

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.

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.

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.

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. Now that there is an open source
implementation of Java SE 6 available in the OpenJDK community, we
expect that we'll be receiving requests and approving eligibility for
the OpenJDK Community TCK License more frequently.

A prospective licensee applies for the license by submitting a
web-form explaining who they are, what organization and project they're
associated with, and whether they propose to test a full implementation,
or whether they are a contributor who will test contributions prior to
submitting them. A few additional questions about their implementation
or contribution will help Sun to evaluate their need to license the JCK.

Sun evaluates the application according to published requirements, in a timely manner.

Once Sun's decision is communicated to the applicant, then
after having read and understood the license and agreeing to its terms,
the applicant signs and returns the OpenJDK Community TCK License
Agreement to Sun.

Once a signed agreement has been received, the applicant will
be granted access to a secure download site from where they can download
their copy of the JCK and get started.

It is important to understand the roles of the participants in this
process. The terms for access to the JCK the license agreement itself,
and the requirements for eligibility, are established by Sun. The
screening process is run by Sun according to these published
requirements, but necessarily will include some subjective judgement.
And of course, an applicant must agree to the terms of the license which
is an agreement between the applicant and Sun, sign it, and then abide
by those terms.

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.

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.

Support for the new OpenJDK community of JCK users will, in the spirit
of open-source development, be primarily community-based.
A new Conformance group has been established, and a mailing list for
discussions, 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 mailing
list and will make reasonable efforts 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. Sun's product name for its JTHarness
implementation is JavaTest.

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.

Here are some examples of the kind of truthful claims you can make if you pass the TCK:

MyBinary has passed the TCK.

MyBinary has passed the TCK and is compatible with the Java(TM) SE 6 platform.

MyBinary is compatible with the Java(TM) SE 6 platform.

MyBinary is compliant with the Java(TM) SE 6 specification. (Unless you know that your
code is not compliant with the specification despite passing the complete test suite).

If you do not accept the trademark license, you may not:

Use the cup and steam logo.

Use the words "Java Compatible" or "Java Powered" on the code (e.g., splashscreen,
information or about page, documentation) or on the download page of a website.

Use the statement: "MyBinary is Java Compatible(TM)."

Please refer to the "Java Brand" section of this FAQ for more information.

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.

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.
The trademark license will be free of charge for use on implementations
that qualify for testing under the OpenJDK Community TCK License.
Since as of late April, 2008, it is not yet possible to build a
compatible implementation based on the OpenJDK 6 code base, this
trademark license is not yet available. We expect to make draft copies
available to the community soon, with the final.

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.

As Sun is not open-sourcing the JCK tests themselves, the JCK remains
confidential.
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.

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 a private mailing list to which you may
subscribe to facilitate just this kind of interaction among licensees
and with Sun's JCK engineering team.

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.

Not at present. The OpenJDK 7 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.
The OpenJDK 6 code base is specifically intended to be used in creating
compatible implementations. As of late April, 2008, there are still a
few remaining components that are encumbered, and so it is not possible
yet to build a 100% Free.

As is typical for open source communities, now that the OpenJDK 6
project is established 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.

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.

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 private mailing
list 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".

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.

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.

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.

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.

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.

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, IRC, 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.

As part of Sun's Community Awards initiative, the OpenJDK Community is
pleased to be sponsoring the OpenJDK Community Innovator's Challenge, an
awards program intended to recognize developers with great ideas, and
the talent and interest to bring them to life. Please check out the web
site for more information at
http://openjdk.java.net/challenge/.

I and my colleagues have been a source licensee of
Sun for previous versions of the JDK, prior to it being open-sourced.
How can we contribute changes made to the code under these licenses for
inclusion in the OpenJDK code base?

A:

Sun is very interested in accepting such changes, as they often
represent a substantial amount of work, and would be very valuable to
the OpenJDK Community. That said, there are several necessary steps for
Sun in accepting such contributions:

Sun must get the changes with all rights needed from the authors to include them in the
code base. Having all of the authors of the changes sign the Sun Contributor Agreement (SCA) solves this issue.

Because of the very high cost of open sourcing code, both in
legal and engineering time,
Sun will require that the changes be submitted as diffs against the
OpenJDK 6 or OpenJDK 7 code bases. Submitting the changes as diffs
against code that has already gone through the costly scrubbing process
will minimize the additional cost of accepting the changes.

Because the licenses, such as the SCSL or JRL do not give
licensees the right to apply
their changes (i.e. derivative works of Sun's licensed source code) to
an open source code base, Sun can give you explicit permission in the
form of a letter that would grant you the one-time right to contribute
your changes to the OpenJDK Project under the SCA. You would not need to
sign this letter.

Sun will consider such requests on a case by case basis. If you have
changes you would like to contribute under these terms, please post your
request to the discuss@openjdk.java.net mailing list, and Sun will
respond.

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.
We're going to change that, but it will take some time.
We're making good progress we migrated millions of lines of code from
our old proprietary source code management tool to Mercurial this year,
for example.
Our processes also need to be documented in a manner that can be
understood by people who don't work at Sun.
The OpenJDK Developers Guide
is an important document that describes many of the processes used to
create the JDK and should be reviewed by anyone interested in
participating in active OpenJDK development with Sun.

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.

How are you making the components of the OpenJDK code base available now?

A:

These components are available in zip files
as well as in Mercurial source code management repositories. Please
visit http://openjdk.java.net and look under the "Source Code" heading
on the left-side navigation bar for access.

The jtreg test framework is intended primarily for unit and regression
tests. It can also be used for functional tests, and even simple product
tests -- in other words, just about any type of test except a
conformance test. (Conformance tests belong in a Technology
Compatibility Kit (TCK), such as the Java Compatibility Kit (JCK)).
Tests can often be written as small standalone Java programs, although
in some cases an applet or a shell-script might be required. The jtreg
framework has its own extensive FAQ on how to use it, found at
http://openjdk.java.net/jtreg/faq.html
The jtreg Project is at
http://openjdk.java.net/jtreg/index.html.

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 at
https://tiger.dev.java.net
will continue to be available, offering this code base under the JRL.

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
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, IcedTea, 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.
The OpenJDK Community in the past year has been fortunate to see the
active and enthusiastic participation of these developers, who have
offered up not just ideas and comment, but code and hard work, to move
the project forward and address the most important issues, like
encumbrances and packaging. The list of contributors is now too long to
call out here individually, but if you want to see who is a part of the
community, just look at the archives for the discussion mailing lists at
http://openjdk.java.net.

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!

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.

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.