“Mustang” Java more Open?
Sun is hopscotching towards opensourcing Java, by providing weekly source code snapshots of the upcoming version 6, codenamed “Mustang“, and having recently unveiled a new licensing scheme.
The meek announcement of Mustang’s proposed new desktop features reads almost like a garage project’s roadmap:
Note that we are attempting to be as open and honest as possible here; we are telling you the things that we would like to do in Mustang; it is entirely possible that some of these items may not make it into the release for one reason or another. Mustang is, after all, very much mid-development right now. Also, any API additions or other enhancements to the J2SE platform specification are subject to review and approval by the JSR 270 Expert Group. But beyond these caveats, this list should contain, at any given time, the features that we are currently hoping to deliver in Mustang.
It seems the company is earnestly eliciting outside developer cooperation and opting for openness of development, this time around, but copyright ownership issues might scuttle the plan in it’s inception. ZDNet quotes Sun VP Graham Hamilton:
To submit their own code, programmers will have to transfer copyright ownership to Sun[..]. The bigger barriers will be cultural[..]: outside programmers convincing Sun programmers that their code is up to snuff; and Sun programmers helping outside programmers learn the ropes of the Java code quality review processes.
Although community goodwill to help in improving the weaknesses of the Java Platform has been mounting in recent years, I can’t see many Open Source, and especially Free Software programmers, forfeiting the sustainability of their contributions within the community, in the slim hope that Java might one day become truly Open Source.
Companies, organizations, and even some individuals, have routinely collaborated with Sun for years towards the development of Java API’s, under the auspices of the much maligned Java Community Process, but real political power afforded to even some Open Source groups involved has led to positive revisions of the process, as well as the introduction of the Java Specification Participation Agreement. It is doubtful, however, that the mass of Open Source talent Sun would like to harness towards refurbishing the Java Platform could navigate their way around such convoluted procedures, or even want to participate in a process where they, as individuals, would have no political power.
Perhaps this could be made to work if proxy parties would consent to represent coders, but the copyright transfer issue outright bars participation from, for instance, the GNU Foundation. This, of course, sheds new light to the recent attack on the GPL by Sun’s president, Jonathan Schwartz, who alleged that Free Software’s mainstay license imposes on it’s users a “predatory obligation to disgorge all their IP back to the wealthiest nation in the world” (that is, the United States, where the GPL originated).
The new licensing scheme, which is slated to replace the ageing and unwholesome SCSL, introduces it’s own fair share of complications as well. According to Infoworld’s Paul Krill:
Key to the company’s licensing plan is Project Peabody, which introduces a new scheme called a JIUL (Java Internal Use License), pronounced “jewel.” Under JIUL, users can change Java source code for their internal use only. JIUL is based on an honor system in which Sun expects compatibility to the J2SE specification but relies on users to ensure that compatibility. Use of Java under JIUL is free.[..]Also being unveiled on Wednesday as part of Peabody is the JDL (Java Distribution License), a narrowly focused license for developing full-scale commercial deployments of Java on different operating systems.
Sun previously has created the JRL (Java Research License) as part of the Peabody effort. Intended for the research community, it allows for sharing of binary-based research distributions of Java. The company has been releasing source code for J2SE under the JRL.
James Gosling’s spin on the new licensing scheme:
We’re trying to respect needs of both sides, to create a licensing and collaboration atmosphere that’s as close to open source as possible while not violating the expectations of the rest of the world around interoperability and compatibility.
Although a onetime moderate supporter of the idea of opensourcing Java, it’s inventor and Sun’s developer products CTO has grown increasingly grumpy in recent months towards the notion and it’s advocates. To be fair, he had to put up with quite a lot of inane flak on the subject. But to be also honest, the above statement reads like a massaged sales pitch, and is quite unbecoming of his mega-geek status and freespirited nature.
Where Open Source is concerned, Sun is slowly getting it. To it’s credit, the company has managed to grow out of the fear of Microsoft’s “embrace and extend” stratagem, which governed it’s every move, in respect with Java; it even managed to seemingly shuffle off IBM’s constant overtures (some would say harassment). However, time is not on it’s side, as a host of new and flexible languages, let alone Microsoft’s .NET, are slicing away at it’s developer mindshare. Having given the world the most extensible and portable object-oriented language, Sun must at some point own up to the fact that the bulk of Java’s popularity stems from community and corporate efforts.
As Timothy Prickett Morgan of ITJungle points out:
It is ironic that having just taken the real jewel of Sun open source–the Solaris operating system–to the open source community as OpenSolaris, Sun can’t seem to do the same thing for Java. Sun makes money on Solaris, but only has influence through Java.
I really hope that Mustang will roam freer than Tiger, and prove to be a healthier animal altogether, with the help of new developer mindshare and “horsepower”. Perhaps it’s a good omen to start naming the next versions after birds, in the hope that someday, Java will really take flight to the Open skies.