December 8, 1998 12:35 PM PST
Sun moves to relax Java grip
"We used to charge for the source code and we won't anymore," said Sun chief operating officer Ed Zander. "Anyone could pull the source code off and not pay a dime to develop and innovate products."
What before amounted to an up-front royalty to use the source code has been replaced by payments to Sun only once the product is deployed.
"Anyone can build an application using Java and use the Java run-time environment, nothing changed about that," said Jim Mitchell, vice president of Sun's Technology and Architecture. "But if a company takes the source code and modifies it to create a derivative product to use internally--by their human resource department--or to ship to outside end-users, they are using our technology, but those are the things we will charge a royalty."
For one thing, Sun will likely add measures to its license agreement that will protect other companies' efforts to create Java-related technology, said David Gee, program director for Java marketing at IBM.
Currently, if a licensee develops "a great technology for inclusion in the Java Development Kit, we have to give it to Sun. They own the intellectual property on that. We get nothing in return," Gee said. "Why would anybody want to contribute to the JDK if there's no recognition, no compensation? It's one of the major sticking points we hoped to have resolved."
Sun also is working on modifications to the Java license agreement that will allow Java clones--"clean room" versions of software that can run Java programs but that aren't made from Sun technology, Gee said.
Gee said Sun is working on the revised license agreement now, showing its latest draft to IBM late last week, and IBM is optimistic that the new license agreement will be announced this week, during Sun's Java Business Expo in New York.
"We're encouraged," Gee said. "They've made a lot of progress from an original, fairly poorly worded proposal from Sun to one the industry all will be more happy with."
IBM also is working on technology to run Java programs. Today it made the source code of its Jikes Java compiler available to anybody who wants to modify it--the open source model of software development that has worked for Linux and other collective programming efforts.
HP made it clear it didn't plan to use Sun's steaming coffee cup Java logo with its version of Embedded Java, a version of Java for small computing devices. But under Sun's new license agreement, there may be a way for cloned versions of Java to still win that symbolic stamp of approval. Java clones could get the Sun Java logo if the clones pass compliance testing to ensure Java compatibility and if the company pays royalties to Sun.
Sun, the developer of the Java language, promotes Java for its "write once, run anywhere" universality. But the Palo Alto, California, company has run into problems as it expanded Java to work in more and more environments.
HP, among others, complained that Sun wasn't including other companies enough in the process for how Sun writes application programming interfaces (APIs), standardized ways that programs can send messages to an operating system such as Java.
The disagreement led to the formation of the Real-Time Java Working Group, which has been going about writing a specification--without Sun's help--for how Java should handle time-critical commands for "real-time" equipment.
The National Committee for Information Technology Standards now is examining whether it will work with that group on setting the specification for real-time extensions to Java, said Barry Hedquist, a member of the committee.
"In terms of the creation of technology I think we are on a good track," said Ian Brackenbury, chief scientist at the IBM Java Technology Center. "But in terms of the long-term stewardship of the standard, we think that a standards body or another international body would be the right repository."
One reason for the separate effort is that companies that weren't Java licensees complained that Sun didn't listen to their comments. Companies also complained that Sun's standards came out too slowly.
But Sun insists it will push aggressively to maintain Java's compatibility.
"The reason we have developed this community source model as opposed to a free and open source model is because we want to maintain compatibility," said Sun's Mitchell. "Open source is good for advancing things quickly, but by definition the source won't stay the same for long.
"So we have a nice balancing act between maintaining compatibility and moving forward carefully," added Mitchell.
"We will keep working with Sun as well as being sticks in their sides at times so they remain good Java stewards," said Pat Sueltz, general manager of IBM's Java and OS/2 unit.