| By Coach Wei | Article Rating: |
|
| November 17, 2006 12:00 PM EST | Reads: |
29,582 |
After looking at Sun’s announcement a few times, let me first clarify what "open source Java" means: It is not about Java; it is about open sourcing the implementation. The license is the GPL V2 license:
Java SE: Java HotSpot virtual machine, the Java programming language compiler (javac), and JavaHelp online help software, and JDK. 
Java ME: Sun is first releasing the source code for Sun's Java ME Feature Phone implementation based on Connected Limited Device Configuration (CLDC), which currently enables rich mobile data services in more than 1.5 billion handsets, and the source code for the Java ME testing and compatibility kit (TCK) framework. Later this year, Sun will release additional source code for the Advanced Operating System Phone implementation for based on the Connected Device Configuration (CDC) specification and the framework for the Java Device Test Suite.
What does it mean to the community? In my take, it is neutral for vendors, positive for developers and great for Sun.
For developers, the immediate effect is the possibility of having some 5-year old bugs fixed (Java has been suffering from a list of bugs that have been rated high priority by the community but Sun never assigned someone to work on it). Going forward, it is possible that a growing and healthy developer community around world will contribute to this open source effort. Though it begs the questions that are unclear from Sun’s announcements: Who controls code commit? What is the decision process for code commit?
For vendors, GPL license is a big challenge to deal with. GPL is sometimes called “commercially unfriendly” license because GPL license requires value-add software that is based on GPL code to be licensed under GPL. So the result is that it prevents vendors from leveraging the "open source Java" stack to create proprietary software with proprietary IP. In reality, if a vendor is going to use Java implementation from Sun in a proprietary commercial environment, it is probably better for the vendor to license Java commercially from Sun instead of opening up proprietary code to GPL. So from a vendor perspective, Sun's "open sourcing Java" does not really bring any benefits - unless it is licensed in a commercially friendly manner. For example, Rod Smith from IBM has been suggesting that Sun should use an Apache-like license already.
From the perspective of Sun Microsystems, this is a smart move and makes a lot of sense.
The immediate benefit I see is the possibility of increased commercial licenses from Sun (though it looks counter intuitive). Additional commercial licenses are driven by the two factors:
“Open source” branding: customers are more willing to adopt open source products and technologies; The GPL license model: GPL is great for Sun! GPL is challenging for other vendors who are interested building proprietary value-add. For such vendors, it is actually safer to purchase a commercial license from Sun instead of going through the GPL license, which would otherwise force the proprietary value-add to be GPL open sourced as well.
The next benefit is the possibility of reducing the cost of building and maintaining the Java software stack. As “the only company who has not made money from Java,” Sun has spent a lot of money on this software stack, which has been freely downloadable for a long time without any direct revenue. My guess is that the Java software stack has been consuming over one thousand full-time engineers at Sun per year. Overtime, the community can potentially take over some of the work and make it less costly for Sun.
The industry is in transition in general. Web 2.0 is a driving force. Community is a driving force. Open source is another driving force. Open source, in particular, impacts how customers buy products, how developers use product and how vendors do business. Venture investors and smart entrepreneurs are leveraging these forces well. So are some smart vendors. Though a long way to go, I salute Sun for the series of good steps that it has taken in the last 12 months: open sourcing Solaris, supporting x86 and AMD, and now open sourcing Java implementation.
Now my remaining hope is that Sun can get its Java software strategy right and be able to leverage Java to build a profitable business for itself.
Published November 17, 2006 Reads 29,582
Copyright © 2006 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
About Coach Wei
Coach Wei is the Founder and Chairman of Nexaweb (www.nexaweb.com), developers of the leading software platform for building and deploying Web 2.0 and AJAX applications. Previously, he played a key role at EMC Corporation in the development of a new generation of storage network management software. Wei has his master's degree from MIT, holds several patents, is the author of several technology publications including JDJ, Web 2.0 Journal, and AJAXWorld Magazine, and is an industry advocate for the proliferation of open standards.
![]() |
scott 11/16/06 06:40:32 PM EST | |||
1000 Full time Engineers per year ??? No company could stay in business if that were true... |
||||
![]() |
scott 11/16/06 06:40:02 PM EST | |||
1000 Full time Engineers per year ??? No company could stay in business if that were true... |
||||
![]() |
Federico Vela 11/16/06 01:41:59 PM EST | |||
Correct me if i'm wrong, but the license is not "pure" GPL but GPL+E which basically makes it a LGPL, meaning that my code can use java without being GPL'd. If this is not correct, then Sun might have just shot itself in the foot. |
||||
![]() |
DragonWriter 11/15/06 05:54:44 AM EST | |||
> I expect to see several more versions of So? There already are several more versions of Java. What keeps the ones that succeed largely compatible isn't licensing (as the non-Sun, non-Microsoft ones are reverse-engineered, not licensed) but the fact that there is no interest in incompatible "Java". Releasing Sun's implementation under the GPL isn't going to change that. |
||||
![]() |
skeptiker 11/15/06 05:52:25 AM EST | |||
I expect to see several more versions of Java, most of them incompatible with each other, coming out soon. |
||||
- Performance of Java Compilers: An Empirical Study
- Java Kicks Ruby on Rails in the Butt
- Ulitzer’s Amazing First 30 Days in Public Beta
- 1st Annual Government IT Expo: Call for Papers Deadline July 15
- REA Is Where RIA Becomes the Norm
- Why an Application Grid?
- Will Ulitzer Dominate News Content on The Web? -Gartner
- Clear Toolkit 4: The Road Map
- Profiling Netbeans within Amazon EC2
- Java Persistence on the Grid: Approaches to Integration
- Performance of Java Compilers: An Empirical Study
- Java Kicks Ruby on Rails in the Butt
- Developing Rich Client Applications Using Swing - II
- The Right Time for Real Time Java
- Xpress Suite Adds Automatic Java to iPhone Conversion
- Ulitzer’s Amazing First 30 Days in Public Beta
- Initial Thoughts on IBM Acquisition of Sun Microsystems
- 1st Annual Government IT Expo: Call for Papers Deadline July 15
- Maximizing Java Performance with Bespoke Programming
- REA Is Where RIA Becomes the Norm
- A Cup of AJAX? Nay, Just Regular Java Please
- Java Developer's Journal Exclusive: 2006 "JDJ Editors' Choice" Awards
- The i-Technology Right Stuff
- JavaServer Faces (JSF) vs Struts
- Rich Internet Applications with Adobe Flex 2 and Java
- Java vs C++ "Shootout" Revisited
- Bean-Managed Persistence Using a Proxy List
- Reporting Made Easy with JasperReports and Hibernate
- What's New in Eclipse?
- Creating a Pet Store Application with JavaServer Faces, Spring, and Hibernate






































