Why won’t Sun ‘Open Source’ Java?

By Tina Gasperson
News Editor
Sun is a computer hardware company whose software products, in the past, have seemed a means to an end — that end being more hardware sales. Network file sharing (NFS) and PC-NFS, a SAMBA predecessor, are tightly integrated with systems. So is Solaris, a UNIX that was developed to run only on Sun’s scalable processor architecture (SPARC) workstations, but now works on other vendors’ systems.Sun’s software outlook changed direction, when in November of 1998, Sun and Star Division joined to release the StarOffice suite, a collection of applications similar to Microsoft’s popular Office.

Sun, known for embracing Open Source with one hand and maintaining strong control with the other, originally set out to license StarOffice under its Community Source License (CSL). The CSL allows free use of source code for research and development, but in order to use a CSL project commercially, the licensee must pay royalties to Sun.

Then, much to the delight of the Open Source community, Sun changed its plans and announced that the office suite would be released under the GPL (General Public License) as of October 2000. To accommodate development and house the source code, Sun teamed up with Collab.net and created OpenOffice.org. Sun also set up the OpenOffice Foundation as a governance for the huge project, which encompasses around 9 million lines of code.

Sun doesn’t appear to be concerned about the possibility of fragmentation of the StarOffice project. “StarOffice already has a strong external ‘standard’ for a file format, because it’s supposed to be compatible with files from Microsoft Office. Everyone has an incentive to comply with that standard or they won’t be able to exchange files with Office users,” says Bruce Perens, president of Linux Capital Group, chairman of Progeny Linux Systems, and one of the originators of the Open Source initiative.

So, why did Sun leap into the Open Source market with such abandon, tossing this fully functional, highly developed office suite into the ring? The consensus among Open Source pundits is that Sun was trying to cut in to Microsoft’s chokehold on the office applications market.

In his editorial, Sun’s StarOffice Release: Is It Really What You Think? Perens says, “Sun has assisted Linux and other operating systems on the principle of ‘the enemy of my enemy is my friend,’ because those systems cut into Microsoft’s operating-systems revenue and intrude upon their monopoly in the systems software market.”

But Sun hasn’t fully converted to the religion of Open Source. It is still holding on to control of its cross-platform Java technology, so far only willing to release it under the CSL. Why?

In an article at InfoWorld.com, Sun’s vice president of technologies advocacy and community development George Paolini said the company is averse to code forking in Java, since the platform is so new.

Danese Cooper, manager of Sun Open Source, says it’s all a matter of cycles. “We talk about the life cycles of software when it comes to licensing issues. Even Open Source developers … tend to hold new software proprietary at first,” until the software matures to a certain stability.

“In the case of Java, a couple of years ago, it was in a state where most of the people using it felt it needed support to maintain compatibility,” says Cooper.

Lou Grinzo, the editor of LinuxProgramming.com, says “if they GPL’ed Java and it forked into two or more incompatible versions, it would all but kill Sun’s ability to make money from it.”

But Perens says that Sun has hampered widespread acceptance of Java by being too protective of their so-called intellectual property. “I think it’s about time for them to release the JDK (Java Developer’s Kit) under an Open Source license,” he says.

“They are afraid of someone running away with their product. My contention is that they don’t have to be.”

Perens maintains that there are two conditions that must be met before Sun could reasonably be expected to release Java under a true Open Source license — and he says that those conditions have already been fulfilled. They are:

1. “A good standards program coupled to trademarks, where you would be able to call it ‘Java,’ or ‘Enterprise JavaBeans,’ etc., only if it passed Sun’s validation suites. This is mostly in place.”
2. “A licensing scheme that gives Sun access to other people’s changes, so that nobody can ‘run away’ with their product. Either the GPL/LGPL or the Sun Industry Standards License would work for this, or both.”

But Grinzo believes Sun still isn’t ready to let go of the fragmentation issue. “Sun won’t GPL Java until they’re convinced that they can avoid forking, and there’s nothing anyone can do to convince them that won’t happen; that’s a decision [they have] to come to on their own terms, if ever.”

Cooper says that if and when Java goes Open Source, it won’t necessarily be placed under the GPL. “Use of the GPL is seen as an experiment at Sun.”

Not only are they observing the StarOffice project to see how it goes, but, Cooper says, “a lot of our more traditional customers are not comfortable with the GPL, and we have to conduct business.”

NewsForge editors read and respond to comments posted on our discussion page