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
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?