Slashdot Mirror
Sun Demurs On Open-Source Java
Tarantolato writes "A Sun spokesman and James Gosling now say that there are no set plans to distribute Java under an open-source license. According to Gosling, 'the debate is still going on, fast and furious'. Concerns about forking are cited, as usual."
Peace
make their own virtual machine and bytecode, and then make mods to existing language compilers to complie to bytecode the OSS virtual machine can run.
Then make a plug-in for Mozilla, Firefox, Opera, and others and leave the IE plug-in up to Microsoft to adopt and create.
Imagine a virtual machine that can run code made from C, C++, Python, Smalltalk, Perl, XBasic, Real BASIC, Delphi/Kylix, Pascal, FORTRAN, COBOL, and other languages in a bytecode format.
If Sun won't do it, screw Sun and shut them out!
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
even though Java is improving (1.5 is *much* better)
and the upcoming chips look good as well.
My opinion: Sun's own marketing is screwing them.
A deal with Microsoft? I could believe it, if Sun
could explain it and what it means for developers.
Java open or closed, both ways have pros & cons--
so pick one, stick to it, and give us a roadmap!
-A former Sun Javasoft employee
I don't see many forks of Open Office or Perl out there.
According to Sun, Java and JVM are registered trademarks. Since Sun owns the trademarks, can't they fight the unwanted forks by exercising the trademark laws?
The forks that are compliant and please Sun Micro can use Java(tm) and can distribute JVM(tm). The forks that Sun doesn't really care about and the ones that pollute the Java world would just have to be something different, call them Jaba, Jamboree or something else, but no one is allowed to use the trademarked terms without Sun's permissions.
...then perhaps they should look at why projects forks?
Projects fork because the software doesn't support new features which are required, or have more features than are required for a particular application.
For example, one version of an application my not support multithreading. In that case, a fork is performed and the multithreading code is added. To merge the projects in the future, the differences are identified and #ifdef'ed. Another example is the case in which a desktop application is being ported to an embedded system. The embedded system GUI (PDA's) may not support all the features of the desktop GUI, and so use of these has to be removed and compensated for.
Already, JAVA has two variants; Embedded Java (J2ME) and Enterprise Java (J2EE). The language has not changed, but there are whole set of API's available: Foundation classes (JFC), Media Framework (JMF), Advanced Imaging (JAI), Java 3D API (J3D), to name but a few. The existance of all of these reduces the likelyhood of any fork from occurring, since the features are already supported. So long as the entire system is split up into small sections, developers can choose which components to support. Sun could always refuse to provide any assistance to anyone who needlessly forked the Java programming environment (they could set up a certification program, and refuse to certify any application which did this).
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
try this strange brew, that's good for you, & freely distributable too.
Personally, and this is just me talking here, I rather prefer LISP to Java anyway. It seems to be a lot less awkward to use, without the confusing standard libraries that try to maintain backward compatability from the time the language was invented. Seeing as how it offers the same advantages as Java (garbage collected, objects, etc) I don't know why we don't just go that way.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
So the Java source should be open for the public but the decision processes should not?
I would not call this a disagreement. Even though Sun owns Java, there are many other members in the Java community as well. By creating discussion, everyone can state their opinions and Sun gets valuable information to support their decisions.
I think openness involves much more than just source code, and out-of-the-blue strategical moves certainly would not support that.
What is Sun's problem? They have cited that redhat linux has been forked. However, there is still only one product that can be called redhat linux. Sun still retains trademark rights on the Java name and they can restrict what is called Java. In fact Sun can restrict the name Java being used with respect to programs and programming languages period.
The fact is that of course there will be forks. Look at all the redhat forks. However, the fact is that those forks, Mandrake for example, ARE compatible with each other. It would be stupid to have a Java Runtime that doesn't run Java programs.
Now, what about certain Java Libraries. Lets say there is a fork that becomes really popular and lets say it is called foo. Lets say foo integrates a 3D Library that all Developers want to use. Well, no other forks have foo's 3D library, what would other forks do? The key would be to require that any for any runtime to be called Java have no integrated libraries. Therefore all libraries would have to be modularized and therefore like C modules portable, and installable by a rpm or deb, whatever.
What if one of those modules is proprietary and only for lets say, x86? I would scoff at any sizable portion of people in the Open Source Community on trading their lives away for a Java Module. Therefore I doubt those modules would receive enough prominence to cause any problems. In fact the only bodies that have enough promenence to actually have restrict people by the modules would be Sun itself, Microsoft, IBM, Oracle or maybe Computer Associates. Now Sun is supposed to be Open Sourcing everything in this hypothetical scenario so I am going to pull them out.
Microsoft has already screwed Java with this kind of scenario. What is going to keep Microsoft from doing it again? The fact is their own technologies are going to do everything and more than java. They have no incentive to work with Java anymore because they have already destroyed it on Windows. By making java the C# of *NIX Sun would be creating a niche in which every Computer Science Major would be able to work in.
Lets say Java becomes very popular on *NIX and therfore can move into Windows again. Well, Microsoft could create a new fork. If Microsoft so much as mentions Java in any of their products Sun could file a suit. However, it would be in Microsoft's interest to leave Java alone because they can simply point at it's quote "inferiority" to C#. They can claim they have a better product.
Now what about IBM? IBM has created SWT, a library that is becoming popular. What if IBM decides to stop shipping Sun's Swing? Well again IBM can't call their product Java. Now IBM DOES have enough stability and muscle to convince companies to start using their product that is sorta "like Java." However, it is not really in their interest to fragment the Java community. Also a said company might not have any need for the Swing runtime. Furthermore, if for some reason Swing becomes neccessary, that said company could always switch to another fork with both SWT and Swing. Any home PC user won't want to use a runtime that doesn't run their programs, so a Swingless Runtime would not gain popularity for home purposes.
The biggest problem for incompatible forking would be a demand for a change in the Java Language that Sun tries to be a jerk about. For example, incorporating native C code is a pain Sun's way. If one fork (like GCJ), decides to do native code a better way, and another fork decides to do it another way, you have two incompatible forks. Frankly native coding is a bad example but, lets say Sun wants say, "nope, the 100% Java way is that you really have to do all that pointless work to code with C," Sun could require that no matter the language features in any given compiler, to be a trademark Java compiler it needs to do two things. 1) Have the ability to compile java binaries out of 100% Java compatible code and 2) Produce no matter what the compiler's features only 100% Java compatible Bi
Apparently Sun doesn't know what they want to do other than create a whole lot of hype. Instead of making Java Open-source or their little free hardware dream, I think the actual Java language should be standardized. I haven't heard much on the topic of Java being standardized lately and think it deserves some attention.
It is a great tool in my opinion, but under the control of Sun it's been a mess. The core API is constantly changed, alot of times in a good way, but they tend to deprecate portions of the API far too often. More thought into the design of these API's would help, but why bother? Sun has 100% control over the direction of the language and its core API's.
Standardization of the language would force them to put a little more time and thought in their additions/changes to the Java API/language. I personally use C++ way more than Java, but have always stood behind it as being a great tool...that could be made even better.
Can you imagine a C or C++ compiler message similar to "Warning(5): Use of deprecated entry point 'int main()'. See 'void main()'"...hmm, god bless ANSI standards! Standardization would do more good for Java's future than anything else, in my opinion of course. =)</comment>
This poster is beginning to break the problem down into parts that need to be handled separately.
For the runtime part of Java, maybe what is needed is a license scheme that can parent copies of code licensed as both GNU and BSD.
How about another level of licensing abstraction?
Lets explore dual licensing for Java's runtime: the Java runtime and runtime modules ought to be dual licensed. A BSD style license is for Sun to create a family "run anywhere" runtime products for many operating systems. The same starting source code (with proprietary API calls replaced) should be released under the GNU license.
The point to a dual license is to preserve an intellectual space for Sun to market a product and to also allow development and extension in the GNU style.
The problem with a pure BSD license is it causes a dead end proprietary product like Mac OSX. I mean dead end in the sense that BSD code doesn't migrate back to Linux or X11.
Another example of how the BSD license stagnates a product is PostGresql. Open as it is, system extensions and interfaces and complete implementations appear as prototypes, and the refined products appear only as proprietary products for sale.
Yet another BSD license problem is appropriation and extension by Microsoft. BSD blocks others from seeing the source.
The reason for keeping a BSD license is it does enable the existence of proprietary product that potentially can be certifiable and secure.
For the sake of creating a proprietary, supported product, actually included with OEM browsers and operating systems, and for something that can be downloaded and upgraded fast, license a primary Sun brand name runtime with the Berkeley Style.If Sun has access to Microsoft proprietary APIs, then let this instance of the runtime be made with those proprietary system calls.
The Microsoft Windows and Microsoft Internet Explorer environments and business computing users need a Java product that can be sold with a guarantee or warranty or certification status. It seems to me that a BSD license is better for parts of a Java runtime product.
But we need a simulotaneous license for the runtime as GNU open source. GNU licenses lead to fabulous juggernauts like the Linux kernel and the Gnu utilities.
Dual licensing does lead to a problem: the dreaded code fork. And in particular, there is no way for developments accomplished on the GNU side to be rolled into the BSD or proprietary licensed side.
Dual licensing suggests that the two code bases would drift apart.
The problem is to keep one GNU code base for the runtimes AND dual license the Java runtime AND not give the source to Microsoft under a BSD license.
Suppose Sun creates two code bases, one GNU and one BSD (for it's own use). "what happens in the future as open source develops one way and the proprietary BSD runtime develops another way?" Well it is a disaster.
Lets engage with that conflict: Create a parent structure that can supply both License code bases with the same source.
As a possible example, could the GNU license applied to the initial Sun codebase be modified with a time limited grant to Sun (say 5 years) to use a specific developed block of open source code under the BSD license?
This could lead to parallel Java runtimes: A Sun product that they sell and warranty, complete with versions for business computing uses. A similar pure GNU runtime that passes the same suite of tests with source code GNU licensed (with proprietary API calls removed and proprietary licensing stuff commented out).
So.
A company that has been promoting UNIX since the early 1980s sickens you.
A company that has pioneered open standards for decades sickens you.
A company that has freely contributed APIs and protocols such as NFS to development community sickens you.
A company that gives away free compilers and runtimes sickens you.
A company that uses Linux sickens you.
Do I detect a slight bit of exaggeration here?