Tech
New Java license: Smells like open-source. Looks like shared-source.
Sun has once again -- this time with Java -- opened the kimono on some of its most coveted code (the last time was with OpenSolaris) but may be falling short of what open source advocates had been hoping for. "One of the new licenses," reports News.
Sun has once again -- this time with Java -- opened the kimono on some of its most coveted code (the last time was with OpenSolaris) but may be falling short of what open source advocates had been hoping for. "One of the new licenses," reports News.com's Martin Lamonica, "called the Java Internal Use License, is targeted at corporate customers that use Java to build business applications. The JIUL, pronounced 'jewel,' makes it simpler for these customers to view the source code and so to root out the problems a Java application is having." This sounds an awful lot like the shared-source license that Microsoft uses to let large customers and governments look at its source code.
So, why won't Sun just go and open source Java? Read LaMonica's report and you'll see how James Gosling, chief technology officer at Sun's Developer Products Group, talks about the company's concerns over forking and compatibility. Forking happens when multiple groups take a single technology and go different directions with it in a way that produces different and often incompatible versions. Looking at another large open source project, Sun doesn't want history to repeat itself.
Sun has never been that impressed by the Free Standards Group-maintained Linux Standards Base (LSB) project. According to the LSB mission statement the goal is a follows: To develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux.
When you talk to Sun president and COO Jonathan Schwartz about the open sourcing of Java, one of the first examples he'll point to as a key reason why it shouldn't happen is Linux. For all of its good intentions, the bottom line is that up until now, the LSB may be succeeding in its mission to increase compatibility amongst Linux distributions, but it so far it has not been able to guarantee it and it's unlikely that the LSB ever will. Enough incompatibilities between the various distributions exist -- especially the distributions that appeal to enterprises -- that you can't not call them proprietary or say that Linux has forked Schwartz has argued.
Schwartz defines "proprietary solutions" in CIO terms (and in terms that I agree with): when, because of incompatibilities with alternatives, the cost to switch to a more attractive alternative is just too much to stomach both financially and logistically. This is a fair assessment of the situation with Linux. It's in neither Red Hat's nor Novell's best interest to make it easy for their customers to
So, why won't Sun just go and open source Java? Read LaMonica's report and you'll see how James Gosling, chief technology officer at Sun's Developer Products Group, talks about the company's concerns over forking and compatibility. Forking happens when multiple groups take a single technology and go different directions with it in a way that produces different and often incompatible versions. Looking at another large open source project, Sun doesn't want history to repeat itself.
Sun has never been that impressed by the Free Standards Group-maintained Linux Standards Base (LSB) project. According to the LSB mission statement the goal is a follows: To develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux.
When you talk to Sun president and COO Jonathan Schwartz about the open sourcing of Java, one of the first examples he'll point to as a key reason why it shouldn't happen is Linux. For all of its good intentions, the bottom line is that up until now, the LSB may be succeeding in its mission to increase compatibility amongst Linux distributions, but it so far it has not been able to guarantee it and it's unlikely that the LSB ever will. Enough incompatibilities between the various distributions exist -- especially the distributions that appeal to enterprises -- that you can't not call them proprietary or say that Linux has forked Schwartz has argued.
Schwartz defines "proprietary solutions" in CIO terms (and in terms that I agree with): when, because of incompatibilities with alternatives, the cost to switch to a more attractive alternative is just too much to stomach both financially and logistically. This is a fair assessment of the situation with Linux. It's in neither Red Hat's nor Novell's best interest to make it easy for their customers to