| By Coach Wei | Article Rating: |
|
| November 17, 2006 12:00 PM EST | Reads: |
32,586 |
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 32,586
Copyright © 2006 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Coach Wei
Coach Wei is founder and CEO of Yottaa, a web performance optimization company. He is also founder and Chairman of Nexaweb, an enterprise application modernization software company. Coding, running, magic, robot, big data, speed...are among his favorite list of things (not necessarily in that order. His coding capability is really at PowerPoint level right now). Caffeine, doing something entrepreneurial and getting out of sleeping are three reasons that he gets up in the morning and gets really excited.
![]() |
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. |
||||
- It's the Java vs. C++ Shootout Revisited!
- Patterns for Building High Performance Applications
- Asynchronous Logging Using Spring
- Java for Programmers (2nd Edition)
- Cross-Platform Mobile Website Development – a Tool Comparison
- Three Buzzwords That Every CIO Hears but One They Should Listen To
- Write Once Run Anywhere or Cross Platform Mobile Development Tools
- Immersing into JavaScript Frameworks
- Workday Reportedly Prepping to Go Public
- Cloud Expo New York: The Java EE 7 Platform - Developing for the Cloud
- Book Review: Sams Teach Yourself Java in 24 Hours
- OpenOffice.com Lives
- Book Excerpt: Introducing HTML5
- Adobe Sends Flex to the Apache Foundation
- Five Years Waiting for JRE 7: Is It Justified? (Part 1)
- Book Excerpt: Java Application Profiling Tips and Tricks
- i-Technology in 2012: Five Industry Predictions
- It's the Java vs. C++ Shootout Revisited!
- Patterns for Building High Performance Applications
- OpenXava 4.3: Rapid Java Web Development
- The Next Web Architecture
- Asynchronous Logging Using Spring
- Java for Programmers (2nd Edition)
- Is Write Once Run Anywhere Ever Going to Be a Reality?
- A Cup of AJAX? Nay, Just Regular Java Please
- Java Developer's Journal Exclusive: 2006 "JDJ Editors' Choice" Awards
- JavaServer Faces (JSF) vs Struts
- The i-Technology Right Stuff
- 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
- Creating a Pet Store Application with JavaServer Faces, Spring, and Hibernate
- Why Do 'Cool Kids' Choose Ruby or PHP to Build Websites Instead of Java?
- What's New in Eclipse?
- i-Technology Predictions for 2007: Where's It All Headed?





















