Find JSRs
Submit this Search

Ad Banner

Java Technology Licensing Update
Options provide JCP Program Spec Leads with Choice & Flexibility

Java Community Process:
A Brief Background

Read a summary of how the JCP program was launched and continues to evolve in response to the needs of the Java Community.
It’s easy to get confused over various Java technology licenses – SCSL, SISSL, JRL, Apache. Here’s a look at some choices recognized by the Java Community Process (JCP) program.
Today, at least a dozen software licenses are in popular use to provide rights and protections to software developers. Some were designed to be as open as possible, others were designed specifically for the needs of a particular development community, organization, or platform. Many are overly complex. It’s easy to get overwhelmed when trying to choose the best option licensing model. This article should help clarify the choices for Java Specification Request (JSR) licenses.
Evolving License Models to Developer Needs
The Java Community Process (JCP) program supports a variety of Java technology licensing models to give specification leads the freedom to choose the best for their specific Reference Implementation (RI) and Technical Compatibility Kit (TCK) needs.
The primary concern of the JCP program around licensing models for the Java platform has been ensuring the platform’s code compatibility between the hundreds of Java Application Programming Interfaces (APIs) or JSRs and across applications, operating systems, and hardware platforms.
Compatibility is essential to the value proposition of Java technology and facilitates interoperability as well as the “Write Once Run Anywhere” promise to the Java developer community.
The licensing models selected by specification leads should help to assure developers and customers that any software product bearing the Java Brand Logo has passed the strict tests for compatibility and will work with other components of the Java platform. That reassures customers and multiplies the market size for developers.
The JCP program discovered that, as a whole, the Java development community was highly motivated to maintain compatibility on its own. So through the evolution of the JCP program rules (currently in version 2.6) and the most recent version of the agreement to join the JCP (the Java Specification Participation Agreement), the requirements of licenses were lightened and some new licenses introduced by specification leads. A primary defining characteristic of each license is the way it addresses platform compatibility and code distribution.
Predecessors to Today’s License Models

Initially, Sun led the JSR expert groups and ensured compatibility by using the Technology License and Distribution Agreement (TLDA) for licensing its implementation code (e.g. Reference implementations). This license goes to great lengths to describe how a licensee could modify the source code and distribute the technology, only after extensive compatibility testing to maintain cross-platform application compatibility. These standards remain today, but the JCP has evolved to allow other members to lead JSRs –- currently over half of the JSRs are led by members other than Sun – and they, like Sun on occasion, have often chosen newer, more flexible licenses.

Both the current version of the Java Specification Participation Agreement 2 (JSPA2), the membership agreement of the JCP program, introduced in October 2002, and the current version of the JCP program, JCP 2.6, launched in March 2004, allow spec leads to use a license of their choice, including an open source license, for the licensing of the RI and TCK. The requirements also separate the licensing of the RI and TCK, and confirm the freedom to create and test independent implementations.
The Sun Community Source License (SCSL) was introduced at the same time as the JCP program - in December 1998.
This license – like the TLDA, covers Sun's licensing of implementation code – allows developers certain freedoms, but it also requires them to publicly post the source code to their developments. With the source code publicly available for download, developers can look at how a program is run in an understandable format; applications are usually distributed in machine-language format, which lets a person execute but not analyze the program.
Today, Sun offers the J2SE 5.0 Software Development Kit (SDK) source code, which includes the Java Runtime Environment (JRE) source code, under the SCSL as one of its options.
The SCSL license is broken into three levels: research use, essentially for evaluating and prototyping potential software applications; internal deployment, for limited distribution and testing; and commercial use, for selling products. Incompatible modifications can be made to the existing code without giving back to the Java community, but only compatible distributions may be distributed commercially.
Some of the Java development community resisted SCSL’s code disclosure requirements and, many objected to SCSL’s “clarity challenged” length and complexity. The JCP program spent the next five years working to simplify its requirements around licensing while protecting the community’s interest in platform compatibility. Today, there are much simpler licenses in use that are available to spec leads.
Separate Licenses for Research and Distribution
As one option, Sun has introduced two new companion licenses that are easier to understand and comply with: the front-end Java Research License (JRL) and the back-end Java Distribution License (JDL). Both are allowed for use in the JCP program.
Used in conjunction with the TCK, these two newer licenses are the simplest way yet to license Java technology.
The JRL is for researchers and universities and is a less stringent version of the research level of the SCSL license. It can be used for research and to experiment with changes to the code base. However, if it's distributed or used internally, developers will need the JDL license as well.
The JRL gives any organization broad freedoms to research and develop implementations for internal use without publicly posting the source code, and it allows them to share the code with other JRL licensees. It gives developers a chance to build and test their solutions under a simple, lightweight license. Issues of compatibility and distribution are not addressed by the JRL.
Next, when the code is shown to be stable, it’s time to license the TCK and test the product against the compatibility test suite for certification, which can include the right to use a Java compatibility logo with the product, applicable for some, but not all, JSRs.
Then, when an organization is ready to consider distribution of their code, they can enter into the JDL, which specifies distribution rights and requirements.
Both the JRL and JDL are considered to be much easier to use than the TLDA or SCSL, and they are recommended by the JCP program for most projects today.
Sun still offers the SCSL license for JDK 5.0 (JSR 176, Java 2 Standard Edition 5.0 ”Tiger”), but using the JDK under the JRL simplifies access to source code. JSR 270, J2SE 6.0 “Mustang” is one of the first JSRs in the JCP program to operate under the JRL from the beginning of its development cycle.
Other Licensing Options, Based on the Open Source Model
The Sun Industry Standards Source License (SISSL), is an open-source license created to encourage compatibility, but not require it. The SISSL is approved by the Open Source Initiative (OSI) as a license for “OSI Certified Open Source Software” and is a choice that is within the JCP requirements for JSRs in development through the JCP program.
SISSL allows developers to use Java source code to develop compatible implementations that can be privatized and shipped without divulging the source code. In this case, it is similar to the open source Berkeley Software Design, Inc. (BSD) license.
JSR 48 – a Web-Based Enterprise Management (WBEM) Services Specification – uses the SISSL.
For developers who want to build incompatible implementations, SISSL requires them to make their source code or a reference implementation available to other developers, who can also use that implementation. In this case, it is similar to the Mozilla style of license.
Apache Licensing, a Complementary Approach
The Apache Software Foundation (ASF) is an important open source community for the JCP program, and the Apache License, version 2.0 is popular among Java developers. This license option can be used by JCP program spec leads.
Scholarships that
Pay for TCK Support
The cost of licensing the Technical Compatibility Kit (TCK) can be a burden on some development organizations, but testing with the kit is a requirement for compatibility certification. While the JCP program’s Java Specification Participation Agreement (JSPA) provides free TCK usage for some organizations, such as not-for-profit organizations, it does not provide for the support usually needed to use the TCK.
Sun’s Compatibility Testing Scholarship Program, currently funded at $1 million a year, now pays for the needed TCK support for qualifying organizations and individuals.
To learn more about the Compatibility Testing Scholarship Program and see if you qualify, visit the scholarship home page.
Several JSRs use the Apache License, such as JSR 154, the Servlet JSR and JSR 206 for JAXP. JSR 243, Java Data Objects (JDO) 2.0, recently started using the Apache License and brought more freedom to developers.
Freedom with compatibility is an important goal, and the Apache License can help.
While the JCP program is chartered with protecting the compatibility of the Java platform, the primary goal of the Apache License is legal protection for its developers, as described on its web site:

The only things we desire from a license are protection of our developers from frivolous lawsuits and giving everyone the right to use our code however they wish, even when they redistribute our code in non-open-source products.

The goals of the JCP program and the Apache Software Foundation are different, but not at odds. In fact, they often work together.
For example, Apache can’t be asked to ensure compatibility among “downstream” licensees of licensees. The same goes for other open source organizations. That’s not their job.
So the JCP program found a way to accommodate Apache and other open source licenses through a Java Specification Participation Agreement (JSPA) provision (5b). It states that downstream licensees must maintain compatibility with the specification in order to benefit from the intellectual property grants offered by the JSR’s spec lead and Expert Group.
Here, the Apache license and the JSPA work together to provide protection and freedom for licensees, and promote platform compatibility.
JSR 168, Portlet Specification, is an example of this combination. The RI is managed by IBM as an open source project at Apache. The TCK is managed by Sun, and it is licensed independently of the RI. They are both freely available for independent implementors and don’t require shared implementation code.

The Apache license is purposely broad and open, designed to be reusable without modification by any project (including non-ASF projects).
Not Open Source,
but Open Standards
The “open source community” of developers is made up of many independent groups, each with their own licensing models. Some open source licenses offer freedoms that the JCP program cannot offer, because of its compatibility standards.
While the JCP program shares many aspects with the open source community, it is bound by its mission to protect platform compatibility. It requires more structure than pure open source organizations.
The JCP program does, however, adhere to open standards as a way to include the maximum number of developers and users. The interoperability that comes from using open industry standard implementations is a Java platform foundation with far-reaching benefits.
Because of common standards, the JCP program is able to support specific product and component agreements with the open-source software development community. The Apache Jakarta Project ’s Tomcat application from the Apache Software Foundation is an example.

Tomcat, the reference implementation servlet container for Java Servlet and JavaServer Pages, is developed and maintained in an open environment and released under the Apache Software License.
And, Two More: the Common Public License and Open Specification License
The Common Public License (CPL) was designed by IBM to encourage collaborative open source development by allowing developers to combine their code with other software governed by other commercial licenses. In that way, it offers a wide degree of choice and freedom.
It also provides protections for the developer's code against unscrupulous or predatory developers or distributors.
The JCP program allows the CPL to be used by specification leads. JSR 80, Java USB API, uses the CPL.
More information on the CPL is available at Wikipedia.
And sometimes, special circumstances require a special license. For example, JSR 87, Java Agent Services, required a license that is as fully open as the JCP program allows, can be used with other licenses, yet is strict enough to lock down usage of the javax.agent name, namespaces, and specifications. So Francis McCabe, of Fujitsu, the spec lead on JSR 87, and his expert group, drafted a new license from scratch – the Open Specification License (OSL).
When it came to licensing out the source code for the JSR’s Reference Implementation (RI), McCabe used the CPL.
The OSL is available for use by other expert groups. McCabe points out that while many licenses are appropriate for software products, a JSR is a specification, not a product, and it may need special obligations for consistent use. “Honoring the fundamental commitment to a specification while allowing contributions is a difficult task,” says McCabe.
Finding Flexible Safeguards
The Java platform and the JCP program are in a constant state of improvement through community-driven evolution. The JCP program version 2.6, along with the JSPA 2, represent a major overhaul of the JCP program and brought new licensing freedoms to developers. It allows each spec lead to recommend which license to use for the JSR, and you can see there is a wide range of options.
But licensing is like security – there is a critical balance between assurance and burden. We’re always working to keep that balance. If you have ideas or experience that can help the evolution, please let us know. The Executive Committee is already at work discussing what might be included in the next version of the JCP program.

The license reference page also has information on these licenses, or use the links below to explore further.
More Information:

The Java Community Process
Spec Lead Guide
License Reference page
Sun Compatibility Testing Scholarship Program Java Research License page and FAQ Apache License page Java Specification Request Community
JDK 5.0 Source Code & Licensing Review
Java Research License, version 1.5
JCP Program Letter of Intent
Open Source Initiative (OSI)

Java Community Process: A Brief Background

Java technology was invented and introduced by Sun Microsystems a decade ago.
Almost immediately, several technology companies began to develop proprietary versions of Java technology. Sun Microsystems was faced with a decision: Establish and enforce rules for the way Java technology is used, or risk the possibility that it would lose its promise of cross-platform compatibility.
A marketplace flooded with proprietary code that varies from the official specification, or worse, parallel platform versions, would “fork” the platform, eliminating its basic “Write Once, Run Anywhere” compatibility foundation.
In 1998, Sun launched the JCP program to develop and maintain the Java platform specification. The program grew quickly and soon needed to evolve to accommodate diverse needs. Broad, cross-industry representation was helpful, so Sun added a blue ribbon panel of Java technology stakeholders to create the next evolution – JCP 2, in June 2000. It created the Executive Committees (EC) and extended freedoms for developers.

JCP 2.6, currently in effect, increases public participation, process transparency, specification visibility, guideline availability, and operational efficiency of the JCP program itself.
Today’s JCP program is acknowledged as the standards body for the only binary standard in the industry, Java technology, and membership is open to anyone who wishes to be part of the platform’s evolution.
Through the JCP program, members can submit Java Specification Requests (JSRs), essentially an idea proposal for an extension to the Java platform. If you submit a JSR and it is approved by the EC, it is adopted as an active project for development by an Expert Group, which you may join or lead. Today, there are over 270 JSRs under development.