Door to Java source code opens a crack wider
"Project Peabody" adds two licenses that make it easier for outsiders to see the code. But Sun stops short of embracing open source.
It will modify its licenses to make access to the Java source code easier, the Santa Clara, Calif.-based company said Wednesday. But it stopped short of creating an open-source license--something it has resisted, despite calls to do so.
Over the next month, Sun intends to introduce two licenses for using Java 2 Standard Edition, the software for building and running Java programs on desktop PCs. The licenses are expected to be used for the Mustang edition of J2SE, which is due in the first half of 2006.
The new licenses are part of a program code-named Project Peabody, which aims to give outsiders more involvement in the development of J2SE. Sun controls the development of J2SE and licenses all versions of the Java software.
The changes are intended to smooth out the process by which Java software companies and business customers view the source code and contribute changes, notably bug fixes, said Graham Hamilton, a Sun vice president and fellow.
Sun's licensing practices for Java are closely watched. Proponents of making Java open source argue that a different license and development process will help accelerate usage of Java, which faces ongoing competition from Web open-source scripting tools, such as PHP, and Microsoft's .Net line of tools.
Sun has elected not to use an open-source license at this time because its commercial customers are concerned with "forking," or the creation of incompatible editions of the base Java software, said James Gosling, chief technology officer at Sun's Developer Products Group.
"By and large, (corporate customers) are somewhere in between uninterested and hostile to the wild and woolly world of open source," Gosling said.
With a few exceptions, open-source products do not have the same rigorous testing for compatibility that Java products do, he said.
"We're trying to do a delicate balance act where we create a licensing atmosphere as close to open source as we can get, while on the other hand, not violating the expectations of the other half of the world around interoperability and compatibility," Gosling said.
Anne Thomas Manes, an analyst at the Burton Group, applauded Sun's decision to make its source code more easily available. But Thomas Manes, a former Sun employee and a longtime advocate of open-sourcing Java, said that Sun could prevent incompatible versions of Java through its control of the Java trademark.
"I think it's an improvement, but it's still just dancing around the concept of open source," she said. "All these arguments are a lot of FUD (fear, uncertainty and doubt)."
Jewel in Java crown
One of the new licenses, called the Java Internal Use License, is targeted at corporate customers that use Java to build business applications. The JIUL, pronounced "jewel," makes it simpler for these customers to view the source code and so to root out the problems a Java application is having, Hamilton said.
The second license, called the Java Distributed License, is meant to make it easier for Java software vendors to have a contract with Sun. The substance is the same as the existing commercial license, which Hamilton said will likely be abandoned for future versions of J2SE.
The licenses, which Hamilton called "an experiment," will be used for J2SE in the future but not for the server-side version of Java, known as Java 2 Enterprise Edition or J2EE, nor for the handheld device version, known as Java Micro Edition or J2ME.
Hamilton acknowledged that its new licenses pose some risk for both Sun and Java customers. The company will use an "honor system" whereby corporate customers will be expected to submit back bug fixes to Sun and not intentionally create incompatible versions of J2SE, he said.
Sun is working on an improved mechanism to accept bug fixes spotted by corporate developers or researchers in academia. It will also seek to educate customers on the risks of making changes to the underlying Java software, he said.
"There's a lot of scope for companies getting into trouble if they get too enthusiastic about making their own versions of J2SE," Hamilton said. "We don't think it should be our job to tell them what risks to take."