December 1998
Navigate    Home    Topical index    Archive    Discussion Forums  Subscribe    Free e-mail alerts  Search          Contact Us    Masthead    Advertising Info    Writer Guidelines    Link to LinuxWorld  What do you think?    E-mail the editors

Advertisement

Analysis

Not quite open source, but closer An analysis of Sun's new Java license Summary Open source developer Stig Hackvän takes a close look at Sun Microsystems's recently announced changes to the Java software license and explains what about it is good for developers -- and what might not be so good. (Can anybody say "Sun Tax"?) (1,500 words) By Stig Hackvän

his week Sun Microsystems announced plans to significantly change the way it licenses the Java platform. Though precise terms of the new Java license will not be made available until January, 1999, the license will be an instance of what the company is calling the Sun Community Source License (SCSL). The new license is liberal enough that some are, in fact, calling it an open source license.

Not yet. Come on Sun, you can do better.

What's the deal?
The SCSL, which is slightly customized for each product, is already used to license Sun's Jini technology, and Sun has indicated the licensing for the Java platform and the licensing for Jini will be very similar. (The Jini license FAQ, by the way, doesn't specify a correct pronunciation for SCSL, but "skizzle" has a nice ring to it.)

The newly announced licensing model will be applied to the different versions of the Java 2 platform: Java Developers Kit (JDK), Personal Java, and Embedded Java. Other Java products, such as the Java Card and JavaOS, aren't included at this time. Sun is also currently evaluating all of its non-Java products to determine if the SCSL licensing model is appropriate.

Licensees receive liberal access to Sun's intellectual property for three different levels of use: research, internal deployment, and commercial use. Internal deployment is the use by end users within a company or organization of a product using Java technology. Commercial use is the shipment of a product using Java technology by a company or organization for either direct or indirect gain.

Nonlicensees have access only to the Java platform specifications and are cautioned, with the threat of patent litigation, against developing "clean room" implementations.

Sun provides royalty-free access to the source code with all levels of licensing, so there is no fee for those wishing to experiment with the platform and product development. Beyond the development stage, however, products must be tested for Java compatibility, and the required Java Compatibility Kit (JCK) is available only to those who purchase a support contract from Sun. So, if you've modified the JDK, for instance, you must buy Java support before you can deploy your work.

Commercial licensees must also purchase a license for the Java Compatible logo. Fee schedules for support and for commercial distribution royalties will remain basically the same as they are now. Sun will also continue to provide binaries of the Java runtime environment to developers free of charge.

A marked improvement
The Java platform is definitely not free software, but it is more open than it was before. The cost of gaining access to the platform's source code has been greatly reduced and the level of freedom granted to members of the community of SCSL licensees has been greatly increased. The six-digit fee for a commercial source license has been eliminated, and the mandatory support fees and Java Logo License royalties don't activate until an application is ready to move beyond the research and development stages and come into contact with end users.

Licensees pay the same price for Java technology, whether or not they use Sun's source code, so there is less financial incentive to rewrite Sun's code in order to save on license fees. This change in incentives alone should foster more compatibility for the Java platform. In other words, cloning Java to save on licensing fees will no longer seem quite as attractive.

Thanks to improvements in the JCK, where there used to be a large body of "shared code" that source licensees couldn't modify -- even to fix bugs -- Sun will now certify implementations as 100% Pure Java even if the source is a mix of Sun code, proprietary code, and third-party code. There is still some "shared code" from Sun that can't be touched, but anything else can be changed, so long as the final result passes the JCK test.

Since the portion of source designated as "shared" has been greatly reduced, the SCSL licensee community will be free to experiment with the four base classes -- I/O, util, net, and lang -- and most of the runtime interpreter.

Modifications can also be freely shared and sub-licensed within the community, and Sun need not be involved in such transactions. If those modifications are sold repeatedly within the licensee community, however, the commercial licensing terms do apply.

Alan Baratz, president of Java Software at Sun, summarized all of this nicely in a teleconference with Java licensees on the day before the official announcement: "So you get the code base up front. You innovate on it for research, for education, for commercial product development, you share it with other licensees -- all free of charge. At the point in time at which you want to ship, you need to make sure you get the JCK and take the support agreement." And, "when the final end user product, the binary product, ships it [is required] to use the Java Compatible logo," he said.

SCSL vs. the Mozilla License
The SCSL-based Jini license (which is, remember, a precursor to the forthcoming Java license) is twice as long as Netscape's Mozilla Public License (MPL) and considerably more complex. Netscape wrote the MPL to create a relatively level field on which to collaborate with other developers of Communicator. Sun wrote the SCSL to stay at the top of the Java platform food chain. Otherwise, the two licenses have a good deal in common.

The Java platform can be used for research and internal deployment simply by agreeing to the terms of the SCSL, but commercial use requires the signing and execution of the attached Commercial Use license.

As with the MPL, the SCSL requires that bug fixes be returned to the community but allows other modifications to remain proprietary. The SCSL, however, further regulates proprietary changes by requiring that all extensions have published APIs, and, moreover, requiring extension authors to freely provide compatibility test suites. Any patents required to implement extensions must also be made available, royalty-free.

Sun still in the driver's seat
Sun sees open-source and standards-based initiatives as troubled by fragmentation. Baratz says that Sun's Community Source licensing model is breaking new ground by "bringing together a community of licensees with very low barriers to entry -- free -- all working together to evolve the technology as rapidly as it could be evolved under the open source model while at the same time preserving compatibility which is so important for [the Java] technology base."

All of this sounds great for the many Java developers out there and for users who have been troubled by the incompatibilities of the various Java implementations. But the SCSL leaves Sun firmly in control of that standard; and in the long run, that may be bad for developers and users alike.

If you are a SCSL licensee and you find some aspect of the Java specification to be a problem -- a bug and not a feature -- then you'll be trapped by the Sun license.

Maybe you want to implement a better security model, or you're looking to pare down the API for your application because it doesn't need to interact with outside Java code. You can participate in the Java standards process, but you don't have control of the standard. Sun does.

You're also stuck on the treadmill of upgrading your product to remain compliant with the Java standard as it changes, even if you don't like the changes. Finally, there are royalties and fees.

With open source, there are no license fees. And while some open source licenses present their own challenges to commercial software developers, it's simply good sense to consider the long-term costs of the Sun license. While you may be better off with the SCSL than with the GPL, you might find the MPL or another open source license even more attractive.

Are you comfortable with an obligation to pay Sun's price, whatever it may be in the future? Could royalties on Sun's Java technology become the next "Microsoft Tax?"

Part of the problem is that we don't really know how to properly value contributions of this nature. It's said that the value of a network increases as the square of the number of users of that network. A fax machine is only valuable if lots of other people have fax machines, and the only videophone in the world is just about worthless.

In some sense, as a technology standard like Java -- or Microsoft Windows -- becomes more ubiquitous, it derives most of its value from the mere fact that everyone else uses it. Preserving the standard becomes all-important to whoever owns it and cashes all the royalty checks. But allowing the business priorities of one company to squelch innovation by others is a dangerous thing. It's probably better to allow innovators who violate the standard to be accepted or rejected by the market.

The open source model favors decentralized evolution of standards, in the firm belief that monopolies are bad and that decentralization yields better technology in the long run. The radical GNU Copyleft contains a very end user-centric brand of idealism that prevents long-term monopolies by preventing short-term monopolies, but at the price of severely constraining developers' opportunities for investment recovery. Other open source licenses, such as the MPL, allow proprietary relicensing of derivative works as a practical matter of doing business, trusting the ethics and logic of cooperation to ensure the long-term survival of open source.

Sun's SCSL-based licensing has much in common with Netscape's MPL, but it focuses on generating a direct revenue stream from -- and maintaining strict control of the standards process within -- the community bound by the SCSL.

How will the open source community respond? Alan Baratz says "This new model is an investment in the future of our customers ... we don't make money unless you make money." The SCSL is not open source, but Sun's approach seems reasonable in spirit.

The SCSL occupies what has been a vacant space in the software licensing landscape, lying about halfway between the Mozilla License and a traditional proprietary license. Relative to the previous Java license, the SCSL is a very clear step in the direction of openness and cooperation, and it should be applauded as such.

It's a very good thing that more and more software companies are now experimenting within the bounds of open source and on its fringes. The world, it seems, is becoming a more cooperative place.

Discuss this article in the LinuxWorld forums (9  postings)
(Read our forums FAQ to learn more.)

About the author
Stig Hackvän is an open source developer who has served as a core XEmacs developer and has been an active participant in the Linux community since before the 1.0 kernel. Currently, Stig is writing a book on open source licensing, to be published by O'Reilly & Associates this spring.