One of the most interesting developments in Java has been Sun's announcement, last December, of a new licensing model that bears a strong relationship to Open Source licensing. Their model is called the "Sun Community Source License" (SCSL); for Sun's description of what this model entails, see the paper Sun Community Source License Principles, by Richard Gabriel and Bill Joy. Essentially, the license attempts to create a hybrid of a traditional proprietary license and an open source license.

Although the details of the license still haven't been released, here's the essence: For the first time, Sun is allowing developers to modify and redistribute the basic JDK; redistribution is without charge, unless you charge for your product. You aren't required to contribute your modifications to Sun; but you are required to maintain compatibility with the Java standard, as Sun defines it. (In the interest of precision, I should say that the SCSL is more of a template for licenses than the license itself. There will be separate Java and Jini instantiations of the license; and there are differences between the two. The Jini version is closer to a true open source model in many respects. In this article, I'll be talking primarily about the Java version.)

The obvious question is whether or not the open source community will accept this new form of licensing. "Open source" is ultimately defined more by religious commitment than anything else, and I doubt that the open source fundamentalists will ever accept something that didn't arise from their own midst. (And it's worth noting that Sun is very careful to avoid calling the SCSL an "Open Source" license.) But the open source community is actually very broad, and includes many pragmatists who are likely to look at Sun's new license terms and like what they see. Open source developers are getting most of what they want: the source code, plus the right to modify and redistribute the source code without charge in other open source products. What's more likely to be controversial is the compatibility requirement. Open source developers are used to doing whatever they please, without a lot of centralized control. Requiring modified Java code to pass a compatibility test is a requirement that a lot of people will understandably balk at.

However, it's important to look at why a compatibility test is necessary. First, Java is a cross-platform language. While there are certainly bugs, "write once, run anywhere" is actually pretty close to true. And if you take away cross-platform portability, Java is really just another boutique programming language: it has some interesting properties, but there's nothing special about it. There needs to be some guarantee of compatibility between different Java implementations.

Doesn't Sun trust the open source community to maintain compatibility on their own? I'm sure they do, as far as that goes. But second, Java is a cross-platform language that is under attack. We all know the Microsoft story, and there's no need to repeat it. Microsoft is clearly threatened by a cross-platform programming environment, and realized that if they could co-opt Java entirely, or at least break the cross-platform promise, it would cease to be a threat: it would be just another boutique language.

I think this is a serious threat, and something that can only be solved if Sun retains some kind of control in the form of compatibility testing. It's not a problem that the open source community has faced, and it's unclear how a completely open process would respond. What would happen, for example, if Microsoft decided that it was in their interest to introduce incompatibilities into Perl, and herd their developers towards some private version? I think this will happen--probably sooner rather than later. I asked Eric Raymond about this awhile ago, and he talked about Larry Wall's moral authority. I'm sorry, but moral authority and a nickel will buy you a cup of coffee in 1945, particularly if you're using it to compete against Microsoft. The open source community could conceivably react by saying "That's fine, as long as we have our tools, we don't care if other people have broken versions of those tools." For Perl, that might even be a reasonable response; the things for which Perl is used tend to be fairly static. CGI scripts usually don't migrate from one computer to another. But for Java, incompatible versions of the platform break the language's most revolutionary and enabling feature.

Obviously, there are smart ways and stupid ways to do compatibility testing. If the test can be "run at home", and the results submitted via email, and whatever certification Sun deems appropriate issued within a day or two, that would be great. Most developers understand the need to maintain compatibility, and won't have problems submitting to a procedure that's lightweight and streamlined. On the other hand, if compatibility testing is some long, drawn-out process that's administered by an understaffed bureaucracy, Sun will be in big trouble. Cooperation hasn't been Sun's strong suit--and in the open source community, they are dealing with developers who will only work on the basis of mutual cooperation.

While it's at least partially clear how commercial developers will fit into the compatibility testing picture, it's completely unclear how testing will work for open source developers. I'm concerned that Sun plans to charge for Java compatibility testing and certification. Administering a comprehensive compatibility test is time consuming and expensive, and it may not be reasonable to expect Sun to subsidize open source developers in this way. However, I'd be much happier with a multi-tier arrangement, in which non-commercial developers could certify for free, or even self-certify. Granted, running a certification suite is no simple process, so self-certification might not be a viable option. (I understand that the Jini group plans to use a multi-tier approach, with a self-certification option.) I fear that testing charges will put out the fire that Sun is trying to start.

Java and the open source community are really made for each other. There is already a lot of open source software in Java, and I hope to see more of it. Conversely, I am sick and tired of software (commercial or open source) that runs on my Windows machine, but not on my UNIX box, or that has been ported to Linux, but not Solaris, and so on.

Furthermore, it's time to start thinking about the next generation of computing, and get beyond the big eye staring at you from a monolithic computer. It's time to start thinking of the Internet as a platform for massively distributed computing; it's time to start thinking of computers themselves in terms of networks of communicating devices, rather than some parts huddled around a disk drive. One example: Dallas Semiconductor is producing a low-cost weather station based on the Jini chip they're developing. One serious problem in weather forecasting is that weather stations are few and far between, and computational models for working with weather data require supercomputers. With a product like Dallas's, it's easy to imagine a world-wide network with hundreds of thousands of weather stations, doing distributed processing over the Internet. Would this revolutionize our understanding of global weather patterns? I don't see how it couldn't.

The software with which we will build next-generation applications like this needs to travel, and needs to be able to run on multiple platforms. In other words, it really needs to be Java. If open source developers catch this vision--that the next generation of software must be able to move transparently from one machine to another--we'll really see what the Internet is capable of. Java is the best tool available for implementing that vision.