"Sun today announced that Java Platform, Standard Edition 5 is now available for redistribution by GNU/Linux and OpenSolaris operating system distributors under the new Operating System Distributor's License for Java (also known as the 'Distro License for Java' or DLJ). Developed in consultation with, and for use by, the various GNU/Linux communities, the new license allows distributors to ship Sun's Java SE 5.0 Java Development Kit and Java Runtime Environment as installable packages for their operating systems." At the same time, Sun also promised to open-source Java.

Firstly, forking (fragmentation) only works if people support the fork. People may have supported {Free,Open,Net}BSD, even DragonFlyBSD, but many other BSDs (not to mention versions of XFree86 under the new licence) have fallen by the wayside, and the future of some (PCBSD, DesktopBSD) is at best unclear.

Secondly, what is clear is that choosing the GPL is the best way to prevent forks. Yes, there are plenty Linux distros, but they all take the Linux kernel from the same codebase, GNU binutils from the same codebase, and so on.

You have to keep in mind Sun said they would open source the code and allow Java to be freely distributed. They still retain control and direction of the design of java as a programming language since it is not GPL'd. So if you want feature XYZ and Sun rejects that request then you are out of luck.

Secondly, what is clear is that choosing the GPL is the best way to prevent forks. Yes, there are plenty Linux distros, but they all take the Linux kernel from the same codebase, GNU binutils from the same codebase, and so on.

That isn't necessarily true. In fact, I don't see how the GPL prevents forking at all. It seems to encourage it, just look at the hundreds of Linux distributions that exist. Not only are they different in what they package, many of them have different patches applied, etc. They may have the same sources for code, but that doesn't mean anything.

In fact, I'm not sure how the GPL ensures that people will obtain it from the same source, when obviously, the different kernel patches they use often don't come from the same source.

I think the correct thing to say is that the GPL is *one* of many open source licenses that can *encourage* a centralized project. However, I'm not aware of any that would actually *prevent* forking.

I think the correct thing to say is that the GPL is *one* of many open source licenses that can *encourage* a centralized project. However, I'm not aware of any that would actually *prevent* forking.

I didn't say it would prevent forking, any more than DRM will prevent illegal copying. What I did say is that it is the best way to prevent copying, just as making code closed-source is the best way to prevent your algorithms being copied by someone else. But it's still not impossible.

In fact, I don't see how the GPL prevents forking at all. It seems to encourage it, just look at the hundreds of Linux distributions that exist. Not only are they different in what they package, many of them have different patches applied, etc. They may have the same sources for code, but that doesn't mean anything.

I already addressed this in my post. Distros are *collections* of OSS, and as such they can differ in their choice of what goes into the collection. Yes, I know many distros do submit patches to GPL'ed programs and such (Gentoo and SuSE being two of them which I use), but since they must be open-sourced, they can't be "taken away" from the community in the way that, say, you can take FreeBSD, make changes to support your proprietary architecture, and keep the changes to yourself, such that (say) only your GUI can run on top of your architecture. Anyone who does so is in violation of the GPL.

I didn't say it would prevent forking, any more than DRM will prevent illegal copying.

Actually, you did:

Secondly, what is clear is that choosing the GPL is the best way to prevent forks.

At the very least you implied that it would "prevent forks."

I already addressed this in my post. Distros are *collections* of OSS, and as such they can differ in their choice of what goes into the collection. Yes, I know many distros do submit patches to GPL'ed programs and such (Gentoo and SuSE being two of them which I use), but since they must be open-sourced, they can't be "taken away" from the community in the way that, say, you can take FreeBSD, make changes to support your proprietary architecture, and keep the changes to yourself, such that (say) only your GUI can run on top of your architecture. Anyone who does so is in violation of the GPL.

So then, wouldn't *any* open source license with roughly the same terms as the GPL be just as good at "preventing forking" as you said earlier? Why the GPL? What makes it better than other OSI approved licenses with similar terms?

The GPL might be the best way of preventing forking, but IMHO it opens a totally different can of worms. What would happen to my code that was written and compiled by a fully GPL JVM? The compilation itself shouldn't be an issue, but if the entire JVM was GPL'ed, that would mean that my code was linking to GPL'ed code, which would then require me to release the source code to my programs.

Unless I am mistaken in my interpretation of the GPL, using such a license would spell death for Java. Instead a different license like the BSD (very unlikely) or the LGPL (more likely) would be more suitable.

You do realize that the JVM is a JIT compiler, and as such it does compile bytecode to native code? Hence my original question.

While there are GPL implementations of the JVM I am free not to use them if I disagree with the GPL. If Sun releases their JVM under the GPL, where does that leave people who have no wish of touching the GPL?

"Vendor asking for community input on how to balance open source with preventing fragmentation"

they want to ask the linux community for input to prevent fragmentation? if that is the case. i thought they were discussions about the linux community being fragmented, and that was one of the problems for linux not being able to succed in the desktop.

as other reader noted, i see no "Sun" on this information.
Also, there is a posiblity that Sun has dedicated engineers for this port or providing support-consultancy to the FreeBSD engineers which may also not be free. Of course someone from FreeBSD developers can answer this question better.

Well done Sun! I think this is a great move. Make it very freely distributable will increase its popularity and allow many users to access a great many java applets and apps that are out there. Also it will make Linux a better development platform for Java purposes.

And the open sourcing of Java is also amazing because JEE 5 is a great step in the right direction. IT is very easy to use and it got developed and released very quick if I am not mistaken. This open sourcing I hope means that Sun will still have final control over Java but the process will be more open and thus Java will evolve quicker and better with many more features and advancements with input from other big java houses. I think this is a good news for Java fans and enterprise developers and a slightly bad news for the .NET platform.

Python, Tcl and komodo (from ActiveState.com) do everything better *for me* (and many others), or do the same that Java does with less pain !
And it's cross-platform.
And it's faster than Java.
And it's easier and simpler to maintain.
And you can find other Langs and Framework that are better and more efficient than Java for multi-purpose dev.
It's just that Java has had a lot of ads and hype.
>>>

Python, Tcl and komodo (from ActiveState.com) do everything better *for me* (and many others), or do the same that Java does with less pain !
And it's cross-platform.
And it's faster than Java.
And it's easier and simpler to maintain.
And you can find other Langs and Framework that are better and more efficient than Java for multi-purpose dev.
It's just that Java has had a lot of ads and hype.

I don't know what kind of work you do with either of those, but they don't compare in any way to Java. Python is a nice scripting language but its in a different league.
I dont know if you noticed but Java is also cross platform and in NO WAY is Pythong or TCL faster than Java.

they don't compare in any way to Java. Python is a nice scripting language but its in a different league.
No way is Python or TCL faster than Java.
Java is also cross platform.

Fast is fast, anywhere.
OK Java is on a different league, there is millions of Dollars backing it up.
(I don't work for Sun or any other company).
Never seen popular aplications made with Java. Seen plenty with other Lang (Red Hat installer is made with Python, other Linux config tools also use it). Python doesn't run on mobile phones like the Java Games do (they finaly found some use for the language
Java has been better on speed lately (2 years) but swing not as much.
I don't want to get in a religious war here.
Regards,
-

Well, make up your mind:
either,
1) There are other interpreted languages today which are much better in every way.
or,
2) Python, Tcl and komodo (from ActiveState.com) do everything better *for me* (and many others)

Python, Tcl and komodo (from ActiveState.com) do everything better *for me* (and many others), or do the same that Java does with less pain !

How much simpler can you get than Netbeans 5 and Studio Creator 2?

And it's faster than Java.

Don't mean to be rude, but this isn't slashdot, you'll need to provide a link to some numbers.
Considering that JDK 5 is competitive with C++ (and thrashes mono), I seriously doubt your claims: http://www.shudo.net/jit/perf/

Have you ever compared Java with Python code? Python is much simpler and more compact than Java. Python programmers can write a program off the top of their head. Java programmers have to resort to the documentation much more often because the language is so huge and verbose.

Don't mean to be rude, but this isn't slashdot, you'll need to provide a link to some numbers.
Considering that JDK 5 is competitive with C++ (and thrashes mono), I seriously doubt your claims:

It all depends on what you are testing. Python is faster in some instances although I would say Java is faster overall. For example Java sucks at small apps because the VM initialization time is so much longer than Python.

Have you ever compared Java with Python code? Python is much simpler and more compact than Java. Python programmers can write a program off the top of their head. Java programmers have to resort to the documentation much more often because the language is so huge and verbose.

I wouldn't say the Java *language* is huge. It's quite a simple language (compared to say C++, or C# 3.0). I would agree that the set of Java class *libraries* for Java, and open source libs available is HUGE.

Python code is more compact, shorter, etc. but that is offset by the fact that Java has better tools support. Sure, the python code will be more compact, but there are many other factors to consider (vendor support, tools, number of classes and libraries available - don't mind using docs if there is a richer set of functionality).

It all depends on what you are testing. Python is faster in some instances although I would say Java is faster overall. For example Java sucks at small apps because the VM initialization time is so much longer than Python.

I'll agree Java startup is slower. A small Java app takes aboud 300 milliseconds (JDK 6 b82) to startup on my system if it is a warm start, but about 4 or 5 seconds for a cold start. Not the most suitable for small utility type apps.

On the other hand, if you focus too much on startup time, it's a bit like saying DOS is faster than Windows, or that Access is faster than Oracle simply because it starts faster and uses fewer resources.

Python programmers can write a program off the top of their head. Java programmers have to resort to the documentation much more often.

I know most of the core Java APIs and regularly code in Java for days at a time without needing to refer to the docs.

Overall it's really just a tradeoff between the terse syntax of dynamically typed langauges, and the raw performance of their statically typed counterparts.

I wonder what impact this will have with Mono? If this is done correctly then Java will be in a good position to bury .NET and Mono just might go with it. But I think this will hurt Mono much more than it will .NET ...If Mono was poorly justified before I can't see it go any further after Java is open sourced.

I guess RedHat and GNU were doing too good of a job in making Sun's Java implementation irrelevent. Most distros today now come with GCJw/Classpath(No thanks to Sun.) My guess is that this is a desperate attempt by Sun to keep its Java implementation (and Solaris) relevant. However, I think most people have already pretty much committed to making GCJ a real alternative. Shame on Sun always trying to fragment the open source community. First it was Solaris, then it was their Directory Server (versus Fedora Core Directory Server), and now it is Java. When will Sun show it is truly committed to opensource and actually opensource something the OS community has not already made irrelevent.

No, I am not (unless you mean Sun is.) I am just disturbed with the way Sun acts. If they want to be an open source player, be my guest. But please do not play the half-ass game (where Sun is half-ass open and half-ass closed.) Before all this, Sun said they will not opensource Java because it will cause fragmentation. That is their decision, their right and it is something everyone respected. Now, they have changed their minds. Now why is it that they changed their mind?

My concern with Sun is that they use opensource as a reactive measure. My challenge to Sun is to lead, not react. If you want to opensource Solaris, good. I love Solaris. If you want to opensource Java, better. I love Java even more. But I will beg Sun & co, opensource because you believe in your model. Please do not constantly react to everything to stay relevant. One time is ok (Solaris). Twice is a little fishy(their enterprise suite). Three times is outrageous(Java).

i am sorry if i offended, it was a joke, apologies for that word.
But i dont understand your last point here. why are you trying something evil on the changes in Sun? in the recent years basically they changed their strategy. it is perfectly ok for a commercial company to change their strategies. aparently in the OS arena they understood that it is difficult to live without open sourcing it. Same way, their enterprise suite was not selling they preffereed to open source it and focused on service.

The thing is, Java should be treated a little differently when subject is Open Source. it is being used by so many third party companies, open sourceing it should be done with extreme care, they cannot allow code to be changed without strict test and quality measures and i guess they feared fragmentation may break backward compatibility and VM or language may change in not so experienced hands. Also, being open source does not add too much vaue to SUn's Java since code is perfectly downloadable and comunity contributions are already accepted by Sun. To me , All they need to do is to make contribution easier, provide version controlled source access and building much easier, thats it.

Not really true.
most people actually uses sun's implemetation. Especially in servers, i dont think nobody actually uses Classpath and gcj.
Classpath, especailly GCJ still needs to mature. Java 5 is out for almost 2 years and GCJ does not support it (stable versions). also both of them are very slow comparing to Sun or IBM's Java.
Sun does not fragment OS comunity, open sourcing Solaris or directory server is a bold move if you ask me. if something is better then linux kernel or Fedora's directory server implemetation, just be happy that there is an alternative, instead of throwing meaningless crap.

I've used the make-jpkg script to use 1.5.0_6 but now that Debian has it in Unstable I'll have to see what, if anything is still missing. So far it looks like they've debianized the source tree under such intersting paths as /usr/lib/jvm. Of course it was all once under /usr/lib/j2sdk1.5-sun/

1. If it's even distributable with GNU/Linux (they only mention the Linux kernel in the license), it's not distributable with any other free OS's (besides their "OpenSolaris").

2. It misses the whole point of open source and doesn't allow you to modify the source and redistribute.

3. It leaves the door wide open for sleight of hand by saying that, "Subject to the terms and conditions of this Agreement, as well as the restrictions and exceptions set forth in the Software README file, ..." (my emphasis).

All this new license does is supposedly allow you to package and distribute it with GNU/Linux. It's just a silly trick to try and get distro's to distribute Java instead of users having to download from Sun's site. That's it. Nothing to see here.

“Rich Green, Sun executive vice president of software, told InfoWorld open-sourcing of Java will happen at some point. "I think at this point, I think it's not a question of whether, it's a question of how," Green said. "So we'll go do this."”

Well I for one am kinda blown away at the moment. So many questions and now a few answers this year especially.
For those of you that have felt that IT was in so much flux these past few years, and almost felt like quiting; you're not alone.

At this point because money isn't the prime issue with Free software, it's the strongest who survive, not the richest. Depends on what richness means I guess too. The Bible explains it in various ways. I'm not against money, but I think it's more morphed into online transaction data, because, think about all that info we have now to know exactly what your customers are purchasing and how they purchase it, all the time retaining their privacy, we hope. It's so much more informative then simple credit. As far as knowing what your customer wants, it seems better.
When you don't ask for money you can demand more from your customer.

Forks???
How many people use Overclockix?
C'mon, there are about 5 top distros that are mainstream and then a few very quality Slackware spinoffs. To me that's pretty healthy.

As a matter of fact with all the distros, none really seem redundant and the ones that are are at the bottom of the barrel.

Well, hmmmmmm. I really don't know too much about Java but a decent amount about .NET. With .NET, when I was working with it, it seemed limited unto itself. Interop and stuff.
Is this the same with Java? Will Java not have that problem now? It seems like Java is very cross platform obviously when you can run it anyware unlike .NET and the Eclipse project seems to emphasize that. Now liberarting it, who knows...

If I understand the implication correctly, this is great news for me. I have a Gentoo server (headless) that uses the Sun JDK, and currently updating means I have to:

- Identify when a newer version's appeared in portage
- Attempt to download the package (fails) to get the URL for download
- Go to said page on another computer with a GUI browser (before anyone chip in, the Sun click-thru EULA page uses Javascript so Lynx is a non-starter) and download the binary
- If the URL is out-of-date because Sun update faster than Gentoo release ebuilds (this has happened more than once), forage around the site for the older binary
- SCP the binary over to the distfiles directory on the server
- emerge the package
- repeat all the above for the jdk-doc package

If the move means the days of these shenanigans are over, Sun will certainly have brightened my day.

Will any of this help the native compiler implement the whole of Java 5? I like the language, but it's just not practical to right small unobtrusive utilities when you need the jumbo/slow to startup JRE either bundled or assumed to be installed on the target PC.

Have you looked at the dependencies of GCJ compiled applications? Do an ldd of a generated executable and see all those libraries it links to. Is that going to be any smaller than just bundling the JRE with your program? Another thing people seem to be misinformed about is the assumption that GCJ will somehow speed Java up. It doesn't. Ever tried running the GCJ compiled version of Eclipse? Try it and then you'll run straight back to the Java version of Eclipse.

Will this allow the BSDs to distribute java now too? I realize that freeBSD has binaries now, but it is a major hassle if I want to install it on OpenBSD (enough of a hassle that I avoid it all together).

Will this allow the BSDs to distribute java now too? I realize that freeBSD has binaries now, but it is a major hassle if I want to install it on OpenBSD (enough of a hassle that I avoid it all together).

don't know. but i would think so after java is opened sour,ce and since freebsd the the rest of bsds are also oss projects it might as well apply.

Hourra for sun, for many linux users, we wont have to maintain our own /usr/local/java-sun-jre-blah-blah... to avoid poluting the distro base.

Now what about GCJ and other? How do developers of these projects feel (like: "Oh shit, I have been doing all that while I could just have copy/paste most of it!")? Not sure about the future of these projects also.