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.
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.
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.
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.
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.
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.
 |
|
|
| |
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).
|
|
|
| |
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. |
|
| |
|
|
|
|
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.
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.
The Java Community Process
Spec Lead Guide
License Reference page
Sun Compatibility Testing Scholarship Program
java.net Java Research License page and FAQ
java.net Apache License page
java.net 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 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.
|
|
|
|
|
|
