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."
that Sun is more mixed up than a fart in a fan factory. Free hardware, no, free Java, no free Java.
Peace
Is it any wonder why they are losing business, money, and on the stock market?
Sig temporarily out of service.
...then perhaps they should look at why projects forks? If they can manage to spot things that might lead to a fork early on, they can adress it in a way that benefits everyone as well as avoids forks.
Off course, that also requires whoever is responsible for the code to be able to work with others...
Everything in the world is controlled by a small, evil group to which, unfortunately, no one you know belongs.
A change of thought often requires a change of guard. Time brings both.
- Never underestimate the power of human stupidity.
The only difference is, Sun is losing those arguments!
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.
Given how your comment about decision-making reminded me of todays Dilbert.
Are you local? There's nothing for you here!
What is interesting is Apple's integration of Java into OS X (into the OS X System Architecture), in addition to cooperation with Sun (i.e., allowing OS X specific attributes into Sun's Java).
These are unusual developments because they are not seen between any other OS and Sun.
Certainly, Apple has an interest in Java and, while holding a very small server market share, increasing its server presence. Merely that Apple is not associated with the server market and Sun is, may be very valuable to Apple.
Certainly a relationship between Apple and Sun does exist. How far that relationship develops will be interesting to see.
"There ought to be limits to freedom"
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.
From Jonathan Schartz's bio at sun.com
"Mr. Schwartz also re-established Sun on the desktop with launch of the Java Desktop System which has quickly become the industry's number one desktop alternative"
Since when? They can't commit to Open Source anywhere, you have a user agreement the size of the bible with their company-branded Linux distro that's at least a year behind the times and Redhat's new corporate desktop is going to make Sun's "Java" system another joke on Slashdot. Never seen such a leadership problem in my life. Conflicting press statements every damned month.
This guy is way out there
The reason why forks are not dangerous is because people will still want to write "standard" Java code, no matter how many different strange Java-esque things there are.
Linux is horribly forked. There are dozens of different distros, on dozens of different hardware platforms. There are many different kernels, and the different distros often have their own kernels with their own patches and changes. And here is a perfect example of a fork in Linux which has come back to help all of Linux: Because Linux was forkable, the NSA chose Linux to be the basis of its secure operating system, SELinux. SELinux is so strange and different from regular Linux that it wasn't compatible. It was a true fork, creating a different set of APIs that were mutually incompatible in many ways. The openness of Linux allowed this innovation to occur. It was something that Linus hadn't thought of years before it happened (I'm guessing). And yet it happened. And now, guess what, the work that was done in SELinux has been rolled into 2.6!
So, we had open source software, which allowed a fork, which allowed for totally innovative, off-the-wall creative development, which turned out to be cooler than people would have expected, which then ended up getting un-forked back into the main codebase!
If Sun open sources Java in the right way, that is exactly the kind of thing that will happen with Java, too. It's hard to prove this argument, because I can't say exactly what those innovative forks are going to be, becase they're things that people haven't thought of, but that's what will happen.
So do it Sun!
-------------
WAP news
Total nonsense. Sun is having a debate. If they were not having a debate, Slashdot would ridicule them for their fixed attitude and rigid management.
They are not running into Microsoft. They won a battle with Microsoft, and won big. Microsoft gave in and paid them a lot of money.
I HAVE A PROPOSAL
Ok, everyday, I get on the net and I see a story that Sun has announced something. Then the next day I read a story that Sun has backtracked on what they announced the previous day. Later that day, Sun makes a different announcement. The next day, they backtrack on that announcement. Later that day, they make another anouncement... And the cycle continuous.
So, my proposal is this. For Sun stooping to such tactics, I say we teach them a lesson about continously blowing smoke up our collective ass by boycotting news from Sun until they stop constantly backtracking on their announcements and actually live up to a promise.
Until then, I do not want to see any more news from Sun. I used to be interested in any news about the company. Now, however, I only think about how much internet bandwidth is being wasted by these fiction stories every time I see a Sun announcement.
Please don't get me wrong, I would love to continue to hear news about Sun. I just don't want to hear any more lies.
It should be done immediately.
I would like to say to any Sun employees that the very fate of your jobs hang in the balance here...if not the survivability of the company.
If Java is not opened up gcj will replace it and you will loose relevance.
As is now, gcj is on par with a good 85% plus of the Java class package sets for jdk 1.4.2 as well as native binary executables of Tomcat 4.x are just around the corner, if not produceable already.
You can work with the Open Source community to define what Java will be in the future, or risk becomming a SCO placard if you decide to sue us later on for open sourcing the language itself.
So, your fears about forking Java are already acting on that future by not doing so. Many like myself want to see gcj project move forward quickly due to Sun's questionable financial future and its historic reluctance from management to work with us.
In the end the OSC will have what we want: complete ownership of our own source code and the absolute right for anyone to possess it when the sale of development or software shrinkwrap is completed.
You can join with us and work toward setting standards for the language and the class sets...
OR
We will continue with gcj project backend for the gcc compiler toolsets and insure projects such as Tomcat and Jeromino have safe futures....with or without Sun Microsystems.
We welcome all companies to join us on this crusade to liberate source code in the sale of software and services...and any company that joins us we will utilize such services they offer.
The longer you delay, the further in doubt Sun's future existence is questioned and the more risk you put upon the open source projects.
The OSC community will not tolerate the questionable future of Java very much longer given the spectacular decline of SUN in the past 4-5 years financially and the waffling of key technologists that have built the company. (Joy's on and OFF again relationship for example...)
Investment of time and resources into the Apacje Tomcat project is too valuable now...
Will you come with us or will we leave you behind?
-Hackus
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
(i) Why aren't the people yelling for open source Java busy working on Kaffe and the others?
It seems to me this is more of a "Sun, give us your code or you suck!" type of deal, than anything else.
(ii) Who is going to put up the resources to continue to research and development the Java platform? If the open source community has not been successful in creating an open source java from scratch, what makes you think that we would be able to maintain and improve the technology?
Netscape was talked into releasing and subsequently rewriting their flagship product as open source. That did not save them, in fact they spent a ton of money doing that. This move benefited the open source crowd ( I am writing this from mozilla ), but how did this help netscape?
(iii) Has OpenOffice/StarOffice improved Sun's bottom line much? Any?
Does anyone have a denfensible on plan on continuing the R&D of Java after open sourcing it? And I mean a business plan that is backed up by data?
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
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?
It's sound business for Sun to (A) Open source licensing the Java J2SE,J2EE and J2ME framework libraries ; and (B) Release a fork of the Solaris Kernel under the GPL license.
It would benefit the entire Java based industry, including the free software, open source and proprietary based vendors, to open license the core J2ME,J2SE,J2EE libraries and Java to bytecode compilers.
Java's primary strength, the ability to write code which is constantly portable across many vendors platforms, would be greatly enhanced if all of the vendors were using the same core libraries.
To insure that the standard base core would not become polluted with incompatible forks, the source could be licensed with a clause requiring any incompatible changes or any additional classes or methods to be moved to and occupy only the vendors namespace. Another clause would require that the vendor version of the Java to bytecode compiler and any GUI IDE defaults to generating portable bytecode, without embedding any vendor specific references.
The OSF definition of an open source license clause five explicitly states: "The license may require derived works to carry a different name or version number from the original software."
Developers and vendors would only be required to shift changes to the vendors/developers namespace if the changes were incompatible with the JCP JSR open standards. This would not prevent the development/distribution of additional optimizations, ports or bug fixes. Since adoption of standards has for a long time been an open source tradition, it would not be much of an imposition on the open source community.
Vendors don't have to use *all* the same "core" libraries - just provide the same standard interface. The open source Java core can been seen as a starting common base. Each vendor would be free to "short circut" their implementation as long as the standard API behaviour remain the same. Vendors would still be free to compete on their JVM performance along with how well it performs interfacing data bases, integrated development tools, etc.
Sun could require contributers to the Java Open Core to let Sun or the JCP dual license the result as Sun does with OpenOffice.org and StarOffice. If a vendor does not wish to disclose their modifcations then the vendor could pay for a closed source license scheme. The payment could then be split up amongst Sun, the JCP and the contributers.
Ask IBM and HP what their customers are demanding and you will find out more often than not that it's vendor neutral/independent solutions. Customers don't want lock-in slavery anymore. That is why Linux is such a success and why there is more demand for Java skills than any other programming language.
It should not be necessary to open source license Sun's JVMs. In the long run it could greatly benefit Sun to develop the JVM under a dual license as it doing with OpenOffice.org and selling StarOffice.
Releasing a fork of the Solaris Unix Kernel makes even more sense when you consider Suns move towards commodity based hardware, like AMD's opteron, and enterprise desktop systems. Sun is going to need drivers to interoperate with x86 hardware and common peripherals. In comparison to Linux, the range and quality of hardware drivers available to Solaris is pitiful.
If Sun can manage to get out from under the SCO Groups claims over the old AT&T code base, by dealing direct with Novell who still appear to hold the rights and copyrights, then Sun would be free to release a fork of the Solaris kernel under the GPL license.
Sun would be then free to take any source code from the Linux kernel and incorporate it into the GPL'ed Solaris kernel fork. Sun would then free to deploy that kernel in desktop and clustered systems markets, where Linux currently does have a lead over Sun.