Printed: Apr 26, 2024
From: http://www.jcp.org/en/press/news/licensing_update
Java Technology Licensing Update
Options provide JCP Program Spec Leads with Choice & Flexibility
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. 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.
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).
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
|