McNealy Answers: No Open Source Java

comforteagle writes "Sun CEO Scott McNealy has finally answered the long awaited question that has been on the minds of open source and Java developers. Will Sun open source Java? No. He stated today that Sun sees no solution solved from open sourcing Java that isn't already addressed."

Comments

Re:McNealy can't see it because he's not looking.

[desau]

Uhh -- what? How about: "when's the last time you used NFS? OpenOffice?"

Like it or not, Sun is a big contributor to open source.

Re:How can we fracture it?

[Xabraxas]

Not at all. I think what holds them back is the license.

Software is confidential and copyrighted. Title to Software and all associated intellectual property rights is retained by Sun and/or its licensors. Except as specifically authorized in any Supplemental License Terms, you may not make copies of Software, other than a single copy of Software for archival purposes.

Re:Business Case for Open Sourcing Java?

[Openstandards.net]

The business case is that inviting more people to participate as an open source project will expedite its development permitting it to be more competitive. The open source advocates argue development will be faster, higher quality, and reach more platforms.

I personally wasn't aware of the degree to which this was an issue until I installed FreeBSD. Sun doesn't supply a native JVM for it, and it's current license puts a lot of restrictions complicating the optimization of a free JVM for FreeBSD.

You can get it running, but you have to jump through hoops, agreeing to Sun's source license, and then downloading it from Sun's site before you can compile a version for your PC. After you apply patches created by someone that worked very hard to get the thing to run on your OS, the compile process takes a long time.

The worst part, though, is that it is slow on FreeBSD compared to other operating systems running on the same hardware. Very little can be done until Sun truly open sources Java.

The primary solution people have taken to is creating patches to solve the problems Sun's code has running on different platforms. This has several drawbacks. One is that the patches take time to develop, creating a lag in versions. The second is that the patched versions rarely get true testing, so you can only hope it works with your application, and that something unexpected doesn't surprise you down the road. Most people creating these patches don't have access to Sun's highly priced compatibility test suite.

The irony is that the compatibility Sun want's to maintain is eroded already by Sun's reluctance to both open source Java and make the test suite more accessible. This decision also decreases the platforms that Java can run on, the opposite of one of Sun's stated goals.

A lot of people take it for granted when they install a pre-compiled JVM downloaded from Sun's website on one of the operating systems Sun happens to support. Let me know, please, when Sun releases a FreeBSD JVM, and solves problems the OpenBSD people have had getting it to run correctly.

Re:How can we fracture it?

[rimu guy]

The license does not prohibit redistribution. Debian has just decided the license doesn't suit them is all. That's Debian's issue not Sun's.

For the record here are the re-distribution clauses from the 1.4.2_04JDK:

B. License to Distribute Software. Subject to the terms and conditions of this Agreement, including, but not limited to the Java Technology Restrictions of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified (unless otherwise specified in the applicable README file) and only bundled as part of, and for the sole purpose of running, your Programs, (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software (unless otherwise specified in the applicable README file), (iv) you do not remove or alter any proprietary legends or notices contained in the Software, (v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (vi) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software.

C. License to Distribute Redistributables. Subject to the terms and conditions of this Agreement, including but not limited to the Java Technology Restrictions of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute those files specifically identified as redistributable in the Software "README" file ("Redistributables") provided that: (i) you distribute the Redistributables complete and unmodified (unless otherwise specified in the applicable README file), and only bundled as part of Programs, (ii) you do not distribute additional software intended to supersede any component(s) of the Redistributables (unless otherwise specified in the applicable README file), (iii) you do not remove or alter any proprietary legends or notices contained in or on the Redistributables, (iv) you only distribute the Redistributables pursuant to a license agreement that protects Sun's interests consistent with the terms contained in the Agreement, (v) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software.

Linux VPS hosting *with* Sun JVMs

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:How can we fracture it?

[pjt33]

Java programs larger than "Hello World" have about a 25% chance of running on a default Linux system.

Personally, I think that sentence makes your post deserving of -1 Flamebait. The reason Java programs fail to run on a Linux system is that they were written by idiots who assume that

new File("c:\\");

will work on any machine. I've only had one serious issue with getting Java programs to run on Windows, OS X and Linux, and that is that there's no documented way of changing the default file encoding. I added an item to coding standards saying that file encodings must be specified for all file I/O and the problem went away. The GUI will also want testing to make sure it looks reasonable, but that's not a failure-to-run issue.