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."
good ideas gone awry!
that Sun is more mixed up than a fart in a fan factory. Free hardware, no, free Java, no free Java.
Right now, Sun is acting like a headless chicken, running into Microsoft and one end of the court, pecking its way back into the Free Software side. It's ridiculous, really.
I wonder if they just "announced" it the first time around to get the Slashdot traffic?
This sig was blatantly stolen from someone else.
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.
Sun's going kepp on waffling until the last of their money left over from the dot-com boom is gone.
Expect some real decisions made in desperation as they run out of money but for right now there's definitely a leadership problem at that company.
This guy is way out there
And they still haven't realized it yet.
- 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.
Sun seems to be doing a wonderful job of creating publicity for itself despite accomplishing anything. That's pretty clever, if they just keep announcing stuff then deannouncing for the publicity they stir up. I'd still like to see Java opened, but this furthers the thought that it just won't happen. Not any time soon, atleast.
Given how your comment about decision-making reminded me of todays Dilbert.
Are you local? There's nothing for you here!
Peace
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"
(tinfoil)I'm sure the risks of someone "embracing and extending" are considerably lessened now that Microsoft is out of the picture.(/tinfoil)
But seriously, all Sun has to do is respond correctly to the market over time to maintain their leadership role with an open-source Java. If they can be like Linus then their code will be the reference everyone accepts otherwise some other player will eventually fill their role as the de-facto implementation.
Shh.
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
How Ironic! Back in the 90's rumour had it that Sun was out to aquire Apple
-- "At Microsoft, quality is job 1.1" -- PC Magazine, Nov. 1994
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
Why is that, exactly?
File under 'M' for 'Manic ranting'
Waffling, waffling, waffling.
Java, everyone loves their own brand, especially Sun!
It has a bad case of schizophrenia.
The world hasn't been standing still waiting for Sun to make up its mind. The hacker community has been busy as bees cooking up some Open Source Java. Here is complete rundown.
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
try this strange brew, that's good for you, & freely distributable too.
I've been saying this since the whole idea of OSS Java came up. It's a simple but excellent solution to prevent (non-amicable) forks.
Why doesn't anyone else (but the parent poster) seem to see this?
The Free desktop that Just Works
For me, the OSS community is what makes Java such a good platform. There are so many cool tools and APIs. On any one of my projects it seems as if more work has gone in to making the OSS tools that I import than whatever I use from closed packages. It's a shame Sun don't give these developers any credit.
Even though I love Java I don't feel any particular loyalty to Sun and would prefer to not use their products. I just have no idea how near or far GCJ and the GNU Classpath are away from letting me do this.
I've seen that GCJ can produce a natively compiled Tomcat or Eclipse but I'm stumped if I want to natively compile my own 'hello world' example from an ant script.
Code forks because Microsoft wants to take over or fragment the market by creating an incompatible implementation, as it has done before. I think that's what Sun's primary concern is.
Anyway, why is this so difficult? Can't they just add a term to an open source license that says that compatibility has to be maintained in some form and to some degree, verifiable by third parties? Sure, this brings up the issue of how to test for that, but that's what the compatibility test set is for, right? If someone complains about incompatibility, they test the code in question and send of cease and desists for redistribution until the problem is solved. As long as it doesn't place an undue burden on people who are honestly trying to maintain compatibility, I don't see why this couldn't work. (Though I expect that someone else here will. Anyone?)
Proof again that America runs on greed! :(
Don't worry....China will have a new version of Java for us in a couple of weeks anyway.
Isn't there open source libraries to Java now? Java seems to already be 'forked', people just haven't shunned Sun's libraries and go with the totally re-engineered and free ones, yet.
RMS talks all about this in The Java Trap.
3dinfo@maficstudios.com
But that sort of diversity is one of the reasons some at Sun (and other places) are against open sourcing. The instant they start losing compatability means the language begins to lose it's (imho) main advantage.
Java is not intended to be fast (though it's respectable) or concise (come on, ArrayIndexOutOfBoundsException). Java is about highly structured, controlled, compatable code. Sun cites readability and accessibility as the reason it doesn't include operator overloading, for example.
Even if there are people who continue to write "standard code," there'll still be enough version/flavor specific code to cause headaches.
If you want innovation, you probably wouldn't be using such a highly structured language in the first place. You'd be using something more tweakable, hackable, and screwing-around-able.
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.
That is exactly why forks of something like Java are dangerous.
The thing is, Java is a major part of the software industry today. There are companies who actively want to fork it and produce incompatible non-portable versions that become the de-facto standard: Microsoft.
Really, when you have so many disparate voices discussing the course for the future, shouldn't there be someone to focus them and come up with a strategy? Who lets these people get in front of a mic without clearing their announcements first?
I am convinced Sun is dying. Not BSD dying, but real dying. Don't quote me on that.
Surely, forking only occurs when either a project can sensibly go in two directions, or if the maintainers of the main project give up on it?
Maybe in a perfect world, but in the real world forking also occurs when there's money to be made or lost. Surely Java's enemies would love to encourage forking it (if it were possible) simply to undermine the portability of Java code (Java's best feature).
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?
The issue isn't forking, the issue is how to generate revenue.
It's the usual balancing act: open sourcing software would have many benefits, but what effect will it have on revenue? For a company with revenue problems this is a legitimate concern.
Forking isn't a big deal that they are making it out to be. They are using it as an excuse. Yes, yes, I know what MS tried to do to Java - note that not open sourcing it didn't stop them.
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.
There are companies who actively want to fork it and produce incompatible non-portable versions that become the de-facto standard: Microsoft.
Yeah, thank god gcc can't be used on MS platforms, 'cuz lord knows they'd dominate and ruin the compiler! Oh, wait... I guess the assertion has proved entirely false so far, but keep up the senseless fud. The entertainment value of intelligent people drawing erroneous and spurious conclusions is pretty high.
The only way SUN could loose control of the main code base is if they refused to fold in highly usable and innovative forks developers want to work with. If there had been negative repercusions when Mingw was created, I could see a clear argument. So tell me, where is this GPL'd codebase ruined by MS developers?
If MS didn't percieve open source as one of the greatest threats to its market dominance, the bias against their dev's wouldn't seem so hilarious. Catch a clue guys.
Yeah, thank god gcc can't be used on MS platforms, 'cuz lord knows they'd dominate and ruin the compiler! Oh, wait... I guess the assertion has proved entirely false so far, but keep up the senseless fud.
This is an irrelevant comparison, as its been decades since anyone expected either code or binary compatibility from different C/C++ compilers.
Java is totally about binary deployment and the protection of investment. Java is the ability to code to a known and tested set of libraries and to produce WAR and JAR files that are pretty much guaranteed to run on any certified Java VM.
The entertainment value of intelligent people drawing erroneous and spurious conclusions is pretty high.
I agree.
The only way SUN could loose control of the main code base is if they refused to fold in highly usable and innovative forks developers want to work with.
They nearly did lose control, when Microsoft produced significant windows-specific forks and labelled the result 'Java'. Developers used those libraries and produced Java binaries which could only run on Windows.
Sun is justifiably worried about what other companies with equivalent power to Microsoft could do, such as IBM.
If there had been negative repercusions when Mingw was created, I could see a clear argument. So tell me, where is this GPL'd codebase ruined by MS developers?
MS developers aren't interested in low-volume development systems for Windows - they already have the overwhelming market share. They are interested in the server software market. When something threatens their long-term ambitions in that area, as Java does, they try and wreck it.
It's called x86. There's even hardware acceleration of the bytecode these days. It's cool, you should check it out.
(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
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.
There's a possibility "standard" Java will mean the most popular distribution of Java, and if popularity varies greatly with time problems might arise. A situation similar to IE and CSS might also develop, where a bad effective standard prevents the adoption of the proper standard.
Get it through your head: A fork does not necessarily mean changes to the bytecode or java.*. People who don't realize that don't have imagination...
One caveat here is that there is an Open Source JVM called Kaffe, and guess what, there are a lot of Kaffe forks and it is used in all kinds of innovative research projects. The problem with Kaffe is that it isn't a full implementation of Java 1.4 so its use is somewhat limited in real production environments. It is also not as mature as Sun's Java. I wish it would catch up, but implementing Swing, etc, is a huge amount of work. This just makes the case for Open Source java even stronger.
As I said in a previous post, when you're talking about Microsoft, which is really whom we're talking about, the trademark isn't as strong. Microsoft has enough money and clout to put out something that's close enough to draw people in but different enough to thwart Write Once, Run Anywhere, and to have it be adopted under a slightly different name. Take GNU (GNU's Not Unix), for example. Close, but not actually UNIX. GNU has an incentive to be compatible with UNIX. MS has a counterincentive to be compatible with Java. All MS has to do is call it MUNJ (Microsoft UN-Java) or J++ and say it's better than Java but not actually Java and bundle it with Windows and now you have a divided market, with half the Java software only working on Windows.
Instead, Sun needs to write something into the Open Source license which guarantees some level of compatibility to be permitted redistribution. So MS can create extensions, but you must be warned prominently and frequently that those extensions won't work with Java, and whatever MS puts out must be able to compile standard Java in a way that's compatible with a standard runtime environment.
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
Thanks Sun! I'm begining to despise this company as much as Micr*soft. Two years ago when I began my CS degree, I noticed the local university based their degrees on Java instead of C++. When I queried, I was told because they wanted to be vendor-neutral. I then sought the CS curriculums from various SW schools (Arizona, UCLA, USC & Stanford) and found most were based on Java. What a dilemma, I'm programming in a language 'invented' by a company whoose every public move sickens me.
They nearly did lose control, when Microsoft produced significant windows-specific forks and labelled the result 'Java'. Developers used those libraries and produced Java binaries which could only run on Windows.
And as I recall, this was resolved through trademark litigation. Copyright licensing, proprietary or Free, didd not enter into it.
Google confirms: Ruby is the world's most beloved programm
If the licence allows code to be copied into Linux or whatever, doesn't it also allow code to be copied from Linux or whatever? Maybe Sun can gain directly from this, too?
Ceterum censeo subscriptionem esse delendam.
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.
:)
Sure, just like people want to write website that follow the standard, like most linux apps work perfectly on any system as long is has the right libs in the correct version, the correct version of gcc, the correct kernel version and the right package manager, just like C(++) is write once compile everywhere and like SQL statements that work agains any database...
But, hey, one can allways dream
And as I recall, this was resolved through trademark litigation. Copyright licensing, proprietary or Free, didd not enter into it.
Irrelevant. The issue of forking still arose.
A Freudian slip perhaps?
There was Java 1, and then Java 2, but Java 2 was really Java 1.2, which could be used with Swing derived from AWT, but AWT is supplanted by JFC, and don't confuse JavaScript with Java, where JScript is JavaScript by Microsoft, but C# is Microsoft's Java for .Net, and .Net is like Java, but ... oh forget it.
Anybody try using Maestro, a Java applet for the Mars Rover project. I downloaded it with full anticipation, but it was slow as molasseses.
Silly Java Rabbit!
for one of those annoying Parrot parrots to chime in.
Parrot can not run any language at this time except some bastardized version of Basic and Parrot assembler which changes by the day. Perhaps in another 3 years they might have something to show.
Still nothing to see here - move on.
Substantive opinion by anon Sun employee.
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).
Initial Swing support is coming to Kaffe soon via GNU Classpath's implementation [1], as well as a third, Gtk+ based AWT (beside the Xlib and Qt based ones). If you need Swing on Kaffe right now, you can use SwingWt for a 'Swing over SWT' implementation, which is also on my list of things that I'd like to see merged in.
;)
If you really, really need Sun's Swing implementation badly, you can use Sun's Swing 1.1.1 jar with Kaffe.
But deep in your heart you know you want to hack on GNU Classpath's Swing and create a better, faster, leaner, meaner implementation
cheers,
dalibor topic
kaffe dev, robilad on #kaffe on freenode
[1] Patch hitting CVS head tomorrow, I hope
Kaffe doesn't use Sun's code. It's an independant, clean room implementation.
It is way more cross platform than Sun's implementation: Kaffe has been ported to more than 70 different platforms, includig WinCE, DOS, Playstation2, and mainframes. Sun supports just a handful of i386 platforms and sparc-solaris.
cheers,
dalibor topic
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.
Decaff: I've got a question for you if you're still reading this thread.
What do you make of the fact that there are no significant Perl or Python forks? Not trying to fuel a license pissing-match, I'd just like to get your thoughts on it since you're obviously an intelligent person and I don't understand your position. Thanks, -T.
Google confirms: Ruby is the world's most beloved programm
I guess Sun figured out pretty quickly that they couldn't pull the wool over people's eyes as easily when it comes to "open source" as when it came to "open standards" and their "community process" cop-out. With OSI and a well-defined set of criteria for what constitutes "open source", Sun would have had to produce something that was genuinely "open source" or faced a PR disaster.
And, of course, Sun is rightfully concerned about forking. Well, "forking" is really a euphemism for "losing control", since Sun knows that they minute they permit people to take Java and maintain it independently, Sun's version of Java will be history and the independent version will take over. Once Sun releases Java under a genuine open source license, there would still be only one version of Java, it would just not be Sun's.
Sun is a dying company and Java is the only thing that gives them any kind of credibility or presence. They are going to hold on to it like a starving dog to its bone.
I think Sun's been forking it up for ages...
:S
No concern there!
The only damn language that has extensions for it's extensions...
Open Sourcing it, whilst keeping a control-body over it seems a much better idea. IBM could then definately get their teeth into it (they have much more invested in Java then Sun these days!). It's got to be benefical to Sun for just the help IBM can throw their way...
Allow users to branch if they like... though I can understand that the likes of 'supported extensions' like the MS debarcle makes some sense...
Anyone got a solution to stop that happening under a OSS model?
I agree completely. Forking is only an issue when the library tree is young and not matured. Java's base is highly mature and the 'main line' of java releases are after the 'Open Sourceing' of Java will be carried as the primary fork. All enterprise Java applications and implementations will follow the primary fork. Any subsequent forks that will exist (and they will), will only be for applications that need very specialized performance enhancements. I am sure that most forks will still follow the main line but they will add or enhance subsets of the API. This type of development can only be seen as positive. Any worthy tweak or enhancement would be eventually be merged into the primary java line. Sun knows this. They are just playing a marketing game right now. They have nothing else that is as big as the OS of Java. They'll probably let this drag out until they actually have a hard plan in place to OS Java.
What do you make of the fact that there are no significant Perl or Python forks?
But there are significant forks, especially for Python: There is CPython, Jython and IronPython, and there are incompatibilities between these.
There were also major differences in Perl versions - lots of things broke in Perl 4 scripts when you move to Perl 5.
These languages are often held up as examples of how Open Source systems don't fork and are portable, but I don't think they are good examples.
Significant, to me, does not mean there are huge differences. The point is that even minor language changes can cause a lot of trouble. Its when you have to take time to develop and test different versions of software for different platforms.
What is the big deal with open source Java? Java has been open source for years - when you down load it, you get the source code along with it. You can make changes to it, and submit them to JCP for inclusion in future versions of the language. And Sun doesn't even, really control the language any more because that is done by the JCP - so from time to time changes they would like to make get rejected by the JCP as a whole. It seems to me that this is Open Source, corporate style. You might prefer the Linux approach but keep in mind that for Java code to run correctly on Linux, Windows, Mac X, Solaris, OS/390/Z-OS and all the other platforms it works on someone has to keep control of it. When they didn't, in 1996/1997, Java was a real pain in the bum.
Sun also started some pretty big Open Source projects: Open Office and Tomcat are two that spring to mind. Its not like they haven't contributed a lot to the open source community.
is that the free/open source mouvement is a much more important thing than Java.
Java is just a language and free software will do with or without it.
So Sun should seize the occasion which is offered to team up with the free software community. It is better for them to be with us that against us because, in the end, open source WILL prevail.
These languages are often held up as examples of how Open Source systems don't fork and are portable, but I don't think they are good examples.
Sure, but good examples of what? The lead developers are still in charge of the base years later, and still doing excellent & creative work, so the forking hurt the base exactly how again? And if old code (perl 4 -> 5) requires a rewrite to work, why is that a 'bad thing (TM)'?
I'm seriously not trying to piss on your Wheaties, just trying to understand the downsides to GPL'ing when there appear to be so many success stories.
Hi,
:)
:)
All the 'give us your code' bitching really comes from the sidelines, from people that are not actively working on free runtimes for java programs, as far as I can tell.
Open letters to Sun to make their implementation of Java VM and libraries open souce are about as useful as open letters to Microsoft to fix windows: waste of time. Sun can parfectly well think for themselves and figure out what's in their interest and what's not. If they don't want to have their runtime implementation everywhere, then it's their decision. Meanwhile gcj, Kaffe and others will happily take their place. We already are.
So yeah, it'd be nice if more people started contributing instead of begging.
cheers,
dalibor topic
kaffe dev, robilad on #kaffe on freenode
Sure, but good examples of what?
Good examples of there either being either no forks, or forks being a minor matter.
The lead developers are still in charge of the base years later, and still doing excellent & creative work,
Absolutely.
so the forking hurt the base exactly how again? And if old code (perl 4 -> 5) requires a rewrite to work, why is that a 'bad thing ?'?
I find this hard to answer, because I feel its self-evident why its bad, but here goes.
The really big deal about Java is portability. If I write for Java 1.2 or above, that code will almost always run fine on Java 1.3, 1.4, 1.5 etc. It won't just compile fine, the binary code itself will work, and I can re-use old compiled libraries from years ago. This code will run on VMs from Sun, IBM, HP apple etc... mostly with not a single line change in apps that are hundreds of thousands of lines in length. For significant software projects, you could be dealing with a code base of over a million lines in length. The real benefit of Java is that you have that single code base for all those platforms, and you can be pretty certain that the code will still be fully functional years from now.
(It is possible to write Java so that it uses only one vendors VM, but the point is you virtually never need to, and its considered bad practise).
This is why Java is not just a language: its also a bytecode definition and a set of guaranteed core libraries and a set of compatibility standards for things such as threading.
If it ever gets to the stage where when you write substantial Java code you have to think 'which supplier's Java' the primary advantage of Java will be gone for good.
Many developers like me have been waiting for Write Once Run Anywhere for a very long time. C++ looked close, Smalltalk very nearly got there but it fell apart, and now we have it (or at least something very close) with Java. Its not something that should be given up lightly.
Read open source definition. Read SCSL. Use brain. Thanks.
Sun can't work out what they're doing (http://www.zdnet.com.au/news/software/0,200006173 3,39149502,00.htm) so I'm going to move to and stick with C#/.NET. Sun chop and change so often that I'm not comfortable with a big commitment in Java moving forward. With Mono/etc C#/.NET looks like a safe enough investment. Even if Microsoft use patents to lock down what they introduce in .NET in the future, there is enough open now that a fork will develop.
Don't like the license? Pay for a different one. But stop this "closed source" nonsense. It is open and freely available to anyone to download, browse, compile, port to run on your toaster, modify, post the modifications anywhere.
Just don't distribute it and the results of your compilations without permission...
In Soviet Washington the swamp drains you.
The direct consequence of forks in C is autoconf.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
If you don't see the post I'm referring it, it's marked at -1.
... huh?
... what?
"I want the sources of the JVM's root!!! Anymore!!!"
"You are hiring to the community"
Troll hell, there should be a "-1 unintelligible" rating!
It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
Unless it is particularly wanted by every single person who has the skill to code, permanent forks are impossible for works under the GPL. Projects under the GPL follow the natural tendency of unifying useful code. This is as long as a single technical person exists who wishes it to unify.
This is why the temporary forks in Linux are one of its most important strengths. It makes Linux agile and flexible. And, just as important if not more so: from the user standpoint, it is nearly transparent.
= 9J =