Joshua Marinacci's Blog

An Analysis of Open Sourcing Java

I'm going to try to really tackle the issue of opensourcing Java and state my opinion of why it's a bad idea. Then I'll propose a way would could do it without all of the problems. It's a long one but please read to the end and provide your feedback. This is an issue that many feel strongly about and has the potential to influence Java's long term future. And as a career Java developer, it's something that personally concerns me.

Note, I don't want this to become a Microsoft slam. I think they have made many fine products over the years in addition to some really bad ones and some very questionable business practices. I do have to respect them for the fact that they never give up. They keep working on a good idea, even if it takes five revisions before their product is succesful. In this post I am only discussing Microsoft's actions in relation to Java. Who knows, had I been in the shoes of a VP trying to grow the desktop market (which is hard with 95% penetration) I might have done similar things.

I'd also like to mention that here I use Java and JVM interchangably. I am more than familiar with the difference between the language, the VM, and the libs that make up the runtime (and dear god, please don't make me explain again the difference between Java and JavaScript. :); but for the purposes of this discussion I will consider them all part of what makes up Java. I think this makes sense for the kind of highlevel issues we are talking about.

The Debate: Open Sourcing Java

A lot of people have been talking about the war of words between Sun, IBM, and related parties on the issue of open sourcing Java. Even James Gosling and the Slashdot crew have gotten in on the act. But what would open sourcing Java actually do? What kind of benefits would we, as a community, get?

As a Java developer, and I'm assuming that most of my audience for this post is a Java developer, I really don't care about the politics of a license. RMS may opine that without a free Java you can't implement a completely free desktop, but I really don't care about an abstract sense of free. I care about what an open source Java would actually mean, and how it would actually affect me. To me it breaks down like this.

The Benefits of Open Source Java:

• Multiple eyeballs fix all bugs
• The ability to fork Java if you want to add new features or fix bugs
• The ability to take Java (non-forked) in new directions that Sun wouldn't think of
• Keeping Java alive if Sun tanks
• The ability to make sure no one else can 'take Java away from us', ala Microsoft's embrace and extend policy

The Problems with Open Source Java:

• Multiple incompatible Javas (both language and environment)
• People from one team not listening to other teams. Standards wars.
• Someone else co-opting the entire system to make it proprietary without a large company to defend it.
• A monoculture of VMs (which is not incompatible with the idea of multiple VMs)

Now, as a developer, I don't care about competing with the Jones' (.NET, perl, C) or about the politics of freeness (RMS). I care about making and deploying great applications, and deploying them everywhere. For this reason I love the advantages of open sourcing Java. It makes Java better and lets me play with it. Still, I really hate the disadvantages. #1 on the list is multiple incompatible environments. The current JVM situation, with multiple revisions and platform specific bugs, is bad enough. Imagine if there were 10 or 20 JVMs out there each with their own idea of what "Java" is. Chaos for the developer. I think this is the number one reason that J2ME has failed. There are too many propriatary extensions and platform incompatibilities to make it easy (or even feasible) to develop J2ME software. I'd hate to see that happen on the desktop or server. That makes my life as a Java developer, (and let's face it, we are the only ones who really care this passionately about a programming language), simply hell. In the end we would still need a validation to ensure that all widely deployed Java environments are compatible, and we'd basically be where we are now, with Sun's compatibility tests and control over the spec, only with more fighting and less work getting done.

So what else do we have here. Multiple eyeballs fix all bugs. Well, you can already download the source and fix a bug if you want to. You can even submit the fix to Sun. You just can't get the fix to your users (or the rest of the world) in a timely manner. This is a problem but one that doesn't require GPL'ing Java. In a world with Open Source Java we could still have these problems. The only solution is an active developer team with an interest in accepting feedback. (more on this down below).

Next up, the ability to add custom features. People have been doing that for years with custom JVMs and compiler extensions. GPLing won't change that. Taking Java in new directions already happens with the JCP. The process may have some problems with infighting and general slowness to decide anything, but open sourcing would mean we'd have even more people bickering about trivial issues. (And if you think that's bad, trying sitting in on a city council meeting sometime.) This would make the problem worse, not better.

Next is the issue of Sun going out of business. I think that Java would be fine without Sun. It's a language, carefully spec'd out, with multiple implementations from many organizations, some with billions of dollars. (Hint. It's a TLA). If Sun went out of business tomorrow we'd be fine. I can't say the same about MFC and Win32.

One really odd issue is the monoculture problem. We could have all JVMs derived from a common source (and why not since it's freely available, and in fact the GPL encourages a single source), so one flaw would affect them all. This is the danger of a monoculture. This is a problem even if we have multiple JVMs with incompatibilites. Having multiple implementations of a single spec helps prevent this. I like the idea that a bug in the Windows VM doesn't necessarily affect the OSX one, just as I like being immune to Outlook viruses by using a different IMAP compatible email client.

Finally, open sourcing, particularly with the GPL, would protect Java from an embrace and extend attack from a hostile company, which pretty much means Microsoft. I don't think that it would since they have already done it twice. The GPL wouldn't have stopped what they did. First was an incompatible JVM. Lawsuits happen, years pass, MS settles, and the damage is already done. The GPL wouldn't change this. Second, MS takes the good ideas of Java and makes their own in the form of C#, adding lots of cool new research. Again, the GPL wouldn't stop that. No license (or contract, or law), will stop a determined foe. Only humans with their own interests can stop other humans. Any license can be powergamed around.

So now we can see that opensourcing Java doesn't solve anything. We have problems, and I'd like to see some changes in the way that Sun handles things, but by and large they do a good job and just GPLing it all would introduce great headaches for very little gain. I urge anyone who thinks otherwise to submit an opposing analysis. This really is an important issue and I'd like to have some frank realworld discussions about it.

As a final note (and I'll stop bugging you, I promise) remember that open source excels at building software where the solution is already known (like most of the Unix utilities we take for granted. No one wants to reimplement grep) or where the advantages of customization out weigh the costs of usability, installation, or integration (like Apache). I think this may apply to some parts of Java but not to others.

So I have one suggestion: I would like to see Sun partially open source parts of Java. Development of new standards and specs are pretty well taken care of by the JCP, but I'd like to see them open up the implementation to Swing (my personal interest). I want them to basically put the whole thing into CVS and start taking patches. Make a few Sun employees the architects and lead product managers. They still make the final decision about what makes it into an official release (JRE 1.6, 1.7, etc), and non official releases can't be sold or distributed as Java, but we'd still the the advantages of faster turnaround, multiple eyeballs, and customized versions for certain situations. This would sort of be like what happens with the Win LAF, (a project created to fix the problems with Swing's built in Windows look and feel), but more official and with the ability to move Swing along faster. There's a large community of people who want to make Swing better (and soon).

Comments

• There already are incompatibilities
  There already are multiple incompatible versions of the JDK and JVM. These are Classpath, Kaffe, SableVM, IKVM, and many more. Don't you think these would only be helped to be more compatible if the JDK and TCK sources were released?

  Posted by: keithkml on May 03, 2004 at 01:44 PM

• #if STDARGUMENTS #include stdreply.h #endif
  One benefit is that an open source Java makes Java a first generation language on open source operating systems (like the BSDs and Linux). This means people deciding what language they should write their next cool app in will give Java equal footing along with C, Mono, Python, and (god forbid) perl.

  Along with being treated as a first generation language is the itch-scratching of architecture portability. Some keen developer would port the JVM to their toaster, to their game console, to their RISC-based IP telephone. This turns "Write-Once-Run-In-Three-Places" (Mac, Linux x86, and Windows) to the real Write-Once-Run-Everywhere that keep the sparkle in developers eyes.

  You claim that open sourcing Java will create a bunch of incompatible Javas and that the world will be thrown into chaos; but I can't think of a historical example of this.

  All languages uses under Linux are open sourced, yet they seem to be resilient against forking. There is only one PHP, one Perl, one C, and one C++. One could argue C# has this problem, but I'd say that's more because they're playing catch-up with Microsoft than on purpose. You could imagine Mozilla as a "HTML/JavaScript/CSS" compiler, and it doesn't suffer from forking which affects its ability to process those standards.

  Java already suffers from standard wars (SWT vs Swing), and I believe this is partial because of the closed nature of Java, where "what needs to be fixed" needs to meet a much higher signal level to be heard over the noise.

  I worry that if Sun *doesn't* open source Java, that the community efforts to produce a Java-like language will be far more detrimental to Java. At some point, the language will become usable, and good enough, and people will start coding for it - and around its idiosyncrasies - it may not be called Java, or pass the TCK, but it will gain the mindshare of being Java-like and become a defacto standard.

  And since Sun has decided they won't, this reality has begun brewing....
  

  Posted by: idcmp on May 03, 2004 at 04:15 PM

• We have been here before...
  To quote my response to an earlier Java.net blog on Libre Java:
  "before any serious discussion of the merits of 'Open Source Java' can begin, concrete definitions of terms must be agreed on. Most online forums currently attempting to discuss ESR's comments have failed to do this, and consequently have not reached any kind of useful or even rational conclusion - not because the participants are illogical, but because they are working from different definitions."

  I also made the following comment, which got quoted a couple of times by other people on non-Java.net discussions. It's relevant enough to be worth re-posting:
  "It might also be interesting to have a related discussion on partially open Java, ie. the merit of having a Libre implementation of the Java Platform (VM and JFC APIs) while still leaving the Java Language specification under Sun's stewardship."

  For anyone interested in hearing the already quite substantial Java.net debate over Free Java, the following blog threads are worth reading:

  Sun's Phipps rants on Raymond's open-source rant
  http://weblogs.java.net/pub/wlg/1030

  IBM to Sun: Make Java Open-Source
  http://weblogs.java.net/pub/wlg/1050

  IBM's open lettter to Sun: Open-Source Java
  http://weblogs.java.net/pub/wlg/1052

  Currently, almost all of the 'antis' have made the fallacy of assuming that Open Source / Free Software Java is somehow either black or white, all or nothing. It isn't, and I have explained numerous times why this is so.

  
  

  Posted by: philwebster on May 04, 2004 at 02:43 AM

• FUD
  As most people not involved in open source you have fallen into the basic FUD trap:
  > Multiple incompatible Javas (both language and environment)
  > People from one team not listening to other teams. Standards wars.
  > Someone else co-opting the entire system to make it proprietary without a large company to defend it.
  > A monoculture of VMs (which is not incompatible with the idea of multiple VMs)

  
  All these issues can happen with a propriatairy implementaion as well. Some can't even happen with an open source implementation.
  But most importantly; all those are just fears that could possibly happen, but have as much change of happening as Bush migrating to Iraq.

  In numerous places these points have been explained, but thats the problem with fear; isn't it? Its an emotion; rational explenation will not take it away.

  I guess open source has more of an "Think different" attached to it then any of Apples commercials ever did.

  Posted by: zander on May 04, 2004 at 03:23 AM

• Re: Fixing bugs does not need GPL
  > So what else do we have here. Multiple eyeballs fix all bugs. Well, you can already download the source and fix a bug if you want to. You can even submit the fix to Sun. You just can't get the fix to your users (or the rest of the world) in a timely manner. This is a
  > problem but one that doesn't require GPL'ing Java. In a world with Open Source Java we could still have these problems. The only solution is an active developer team with an interest in accepting feedback.

  Currently SUN accepts no patches at all, at least all the Swing patches I sent in (or even the problem descriptions) have gotten no fix in any beta of 1.5

  This alone is my biggest problem; I can see the source; but not touch it. I can't even compile it.

  So; how do you suppose we can fix this problem so we can get a better Java any time soon?

  Just saying "There are other solutions" will not help the discussion, only suggestions will.

  Posted by: zander on May 04, 2004 at 03:33 AM

• monoculture.
  > We could have all JVMs derived from a common source (and why not since it's freely available, and in
  > fact the GPL encourages a single source)

  Instead of assuming these people think like you do; that monetairy value is more important then the actual implementation, you should have googled a bit where you would have found a dozen implementations of JVMs currently available.

  You also missed that monoculture is not bad if enough people actually contribute to it; fixes will be made faster. Look at openBSD, it has a track record of 1 remote exploit over a period of 8 years. [1]
  In other words; a bad implementation (one windows exploit per week..) is a couple of magnitutes more problematic then a monoculture.

  1: http://bsd.slashdot.org/article.pl?sid=04/05/01/0110247&mode=nocomment
  

  Posted by: zander on May 04, 2004 at 03:46 AM

• Fragmentation Night in Canada
  I found this a timely indication of fragmentation. The Federal Government of Canada has come up with a system called "epass" which is designed to allow you to do interact with different federal government agencies using a single login.

  This service uses Java, but it only works with the Microsoft JVM. It checks for and asks you to disable the Sun JVM.

  The link is here.
  

  Posted by: idcmp on May 04, 2004 at 07:45 AM

• A bit of a strawman
  First, I deal with JVMs from multiple vendors right now. And, I do see incompatibilities, right now. They do not manifest in casual use, but when you have very large applications running under high loads, subtle differences in memory management or code translation can surface bugs that never appear in other JVMs.

  Second, the issue of incompatible forking only occurs under some variations of open source license. Variants like the Mozilla license allow contributions but require that the contributions be submitted to the main stream of code. Thus, the core group maintains control of their distribution. Other parties can create their own distributions, but they must be branded differently. It is clearly possible to create a strong brand around Java that requires any forked distribution to pass the compatibility tests before being called Java.

  But, that only addresses the subject of incompatible changes to the existing base. None of the open source licenses would addres vendor-specific extensions. Nor can a suite of compatibility test check for the absence of extensions to the API.

  That way lies the destructive path of SQL-92, a fully standardized language that was useless in its standard form. Applications that eschewed vendor extensions suffered relative to their competitors that embraced the vendor.

  A mitigating force working against the vendor extensions could be the community itself. I suspect that the Java community in its present form would reject any proprietary extensions to the language or core API. On the other hand, much wealth and power would accrue to a vendor that could successfully capture a significant portion of the community. This would provide vendors with a powerful incentive to create extensions to lure developers. Whether the collective immune system is strong enough to resist that lure for a few years remains to be seen, though history would indicate that there is not.
  

  Posted by: mtnygard on May 04, 2004 at 08:09 AM

• A few comments
  "I think this is the number one reason that J2ME has failed"

  Where? Actually J2ME is the only Java client doing great right now, and Sun willingnes to let mobile vendors to tinker with it is one of the reasons of its success (as far as deployment is concerned, with developers going for volume). Actually MS's way of "here's one BIG Smartphone API and all phones will look and work the same" failed miserably. Although having a J2SE on every possible device would be great for programers, tehnical reallity is something different. But presence on most of the shipped mobile phones leaves options for something like SavajeOS (full blown J2SE OS for mobiles/PDA) to appear on next or next-next gen mobiles. I would like to see Java more flexible where it makes sense, like SMALL fast game oriented VM with tuneable GC (with ports to consoles, heh).

  As far as fragmentation goes, eh, that's no brainer: MSVM vs JVM, differences between Sun's VM's (still waiting for focus managment written for 1.3 to just work even on 1.5-beta1), SWT vs Swing, apple's 1.4x without hw accel for 2D, no server VM on Apple, server VM on Sun's Linux JRE's by default, but no server VM in windows JRE, all off different J2ME profiles (which isn't necessary bad, but requires more work), etc.

  As far as OSS-ing java goes.....there are rumours about just ONE Java sound programer. And just one Java compiler programmer. Java3D is dead, and will be reanimated as OSS (funny, ha) project just because of Looking Glass. Swing crew is relatively (compared to what MS has put in WinFX and Avalon) small, which actually affects Swing a lot (no, it is not fast enough, because I can't ask my every customer to buy a new PC, and it is not small enough, and can I please get my antialiased fonts and jtreetable in this decade?) In current economic reallity, will Sun be able to keep the pace with other platforms? And for how long?

  And, let's consider "Sun dies" scenario. Those guys MUST fight for shareholders interests, right? Now, isn't it possible that they will, if everything else fails (which I hope will not) , sell Java? Trademak, patents, copyright, everything? Or only patents? To the higest bidder? How are you so sure that Java will survive Sun's potential demise? Not to mention the damage that Sun's SLOW death would bring to Java? How many projects won't be started in Java if they continue to sink?

  Posted by: selendic1 on May 04, 2004 at 08:21 AM

• Opposing Analysis
  Joshua, you asked for an opposing analysis, here
  you go:
  How to properly Open Source Java:
  http://jroller.com/page/murphee/20040225

  More info about OpenSource Java:
  http://jroller.com/page/murphee/20040305

  Finally: an extensive list of arguments against Open Source Java... and my arguments countering them:
  http://jroller.com/page/murphee/20040426
  

  Posted by: murphee on May 04, 2004 at 08:33 AM

• You Could Open Source Without the GPL
  1) Open up the source.
  2) Add legal verbage stating it must meet the spec to be considered Java.

  Why does it have to the GPL? It doesn't.

  Posted by: geoffrobinson on May 04, 2004 at 08:42 AM

• Re: Fixing bugs does not need GPL
  I agree completely with this. Since Suns JDK is not only the reference implementation, but also the one most of our users will have, I would like to improve it by submitting patches. I have tried several times to work with the HTMLEditorKit to no avail. I know where the bugs are but can't fix them because they are in protected or private methods. I think that Sun would have a lot to gain from partially opening up the reference implementation of the JRE. These are the parts that nobody writes themselves and only gets from Sun.

  Posted by: joshy on May 04, 2004 at 11:38 AM

• A bit of a strawman
  I think that this may be the root problem. Sun does not derive much revenue from sales of the JRE. I think that they are worried about a large vendor capturing a significant portion of the community, most likely IBM. It would be a concern for me as well. IBM has a habit of giving a great deal to opensource and also absorbing opensource projects into it's own proprietary ones.

  Posted by: joshy on May 04, 2004 at 11:45 AM

• Another rehash of the open source issue
  Here is what really needs to happen:

  Some really bright open source guys need to create an alternative platform to Java just as a test to show it can be done. They should also produce a test kit to ensure compatibility of new implementations.

  When they have this test platform complete, which runs great on Mac, Windows, Linux, Solaris and BSD. with different CPU configurations (Intel/amd). then there will be no doubt that it is safe to open source Java ;-)

  Posted by: rabbe on May 04, 2004 at 12:30 PM

• Don't open-source Java, stop wasting bandwidth
  Open-sourcing Java is a bad idea at this time and it's just a waste of time that everyone's talking about it. There's plenty of folks eyeballing the code and fixing bugs, there's plenty of innovation and evolution going on (BEA jRockit JVM, Kaffe, Jikes, Classpath, Groovy, AOP, etc.), you CAN change the JDK source code (you just can't redistribute it) OR use an open-source project implementation if you need a "fork" for some reason, Sun is NOT about to tank, Sun is NOT controlling Java as much as everybody thinks they are, and the current reality is JUST FINE. Again, THERE IS NO NEED TO OPEN-SOURCE JAVA. When I think of how much code could have been fixed or created while I and everyone else is jabbering about this it makes me nauseous. If anything this discussion is doing more harm than good to Java, IMHO.

  Posted by: gerryg on May 04, 2004 at 01:56 PM

• Don't open-source Java, stop wasting bandwidth
  I agree, In a year of such great progress, I can't believe we're even discussing this anymore.

  If Java were stagnant, then I would agree that something needed to be done.

  Posted by: rabbe on May 04, 2004 at 02:52 PM

• Ability to legally Fork = Handing the whole shebang to Microsoft with a big sloppy kiss
  Open Source Java? Oohh yeah! Gotta get me some of that action!

  *hands jar of crunchy peanut butter to Microsoft*

  *bends over*

  Posted by: rickcarson on May 04, 2004 at 03:28 PM

• Another rehash of the open source issue
  check out kaffe please :p

  Posted by: sejo on May 05, 2004 at 01:11 AM

• Eating Sun's lunch...
  "Some really bright open source guys need to create an alternative platform to Java just as a test to show it can be done. They should also produce a test kit to ensure compatibility of new implementations.

  When they have this test platform complete, which runs great on Mac, Windows, Linux, Solaris and BSD. with different CPU configurations (Intel/amd). then there will be no doubt that it is safe to open source Java ;-)"

  If someone did that, we wouldn't NEED Java!
  

  Posted by: philwebster on May 05, 2004 at 02:33 AM

• There are at least two sides to every debate.
  "Open-sourcing Java is a bad idea at this time and it's just a waste of time that everyone's talking about it."
  Because:
  1) "There's plenty of folks eyeballing the code and fixing bugs"
  But not enough. There are items in the Java bug list that are quite old, and still unfixed...

  2) "there's plenty of innovation and evolution going on (BEA jRockit JVM, Kaffe, Jikes, Classpath, Groovy, AOP, etc.)"
  Classpath and Kaffe exist because of the licenseing problems with Java.

  3) "you CAN change the JDK source code (you just can't redistribute it)"
  If I fix any J2SDK bugs, I can't distribute the fixed version. Other posters have had trouble even getting Sun to accept patches. Distributable/modifyable source is close to useless without the right to *re*distribute it after modification (under certain restricitons).

  Read the arguments by both myself and 'murphee' if you don't understand why people are asking for Libre Java. My posts have links to earlier discussions, and his posts have links to his blog. Both are worth reading, as is the Slashdot thread linked in Joshua Marinacci's original post.

  
  4) "use an open-source project implementation if you need a "fork" for some reason"
  Nobody seriously wants to fork Java. That isn't the reason why people are asking for Java (meaning the VM, the API implementation) to be released under a Libre license.

  Have you read any of the arguments presented by pro-Libre advocates? If so, post some of their points, and present counter-arguments. Just repeating the same old thing again and again does not impress anyone.

  There is nothing wrong with Sun having 'control' over the Java specifications or enforcing compatibility. But neither enforced compatibility or central control would be abolished if Java was under a Libre license.

  What I and others have been proposing all along is this:
  Sun retains the Java trademark, control over the specifications remains with the JCP, and the VM/API implementation is dual-licensed under the LGPL together with another license of Sun's choice.

  This would prevent forking, retain the JVM licencing revenue for Sun, allow bugs to be fixed faster, allow the JVM to be ported to numerous other platforms (which currently do not have up-to-date Java support) and allow a modern implementation of Java to be distributed in Libre operating systems (increasing the size and influence of the Java community). Sun still controls the language. Sun still issues the programmer/developer certifications. Sun still performs the TCK testing on implementatins of the standards.

  Again, this has been explained numerous times, both my 'murphee' and myself, not to mention the posters on Slashdot. PLEASE follow the links provided and try to understand the other side of the debate.

  At the very least, Free Software/Open Source offers cheaper, faster bugfixes and greater ubiquity for the Java platform. This benefits us all.
  It could also allow existing API implementations to be refined to take up less memory, to execute faster, etc.

  Posted by: philwebster on May 05, 2004 at 03:14 AM

• FUD
  "In numerous places these points have been explained, but thats the problem with fear; isn't it? Its an emotion; rational explenation will not take it away."

  The thing that annoys me the most about this discussion is this:

  When the Libre Java debate starts, both 'sides' present their arguments. So far, so good. This is how debates *should* start.

  But from here things go downhill.

  Pro-Libre advocates have listened to the 'anti' arguments, and provided rebuttals and/or clarifications. But the 'antis' don't seem to be playing by the same rules. Why aren't opponents of Libre Java countering the pro-Libre arguments instead of repeating the already-answered opening statements ad infinitum?

  What kind of debate is it when one side turns up with a megaphone and earplugs?

  Posted by: philwebster on May 05, 2004 at 03:32 AM

• Which license?
  Dual licensing may be better. And for the 'Libre' license, in this case the LGPL would probably be more suitable, for a number of reasons.

  The other license would probably be the SCSL.

  I think this solution would be agreeable for all sides - GNU, BSD and Sun.
  

  Posted by: philwebster on May 05, 2004 at 05:23 AM

• Just the Java J2ME,J2SE,J2EE Libraries
  As posted before
  It would benefit the entire Java based industy, including the free software, open source and proprietary based vendors, to open license the core J2ME,J2SE,J2EE libaries 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 vendors were using the same core libraries.

  To insure that the standard base core would not become polluted with incompatable forks, the source could be licensed with a clause requiring any incompatable changes or any additional classes or methords to be moved to and occupy only the vendors namespace. Another clause would require that the vendor version of Java 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 would only be required to shift changes to the vendors/developers namespace if the changes were incompatable 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.

  Contributions to the core standard would be required to licensed under the same open source license. The existing JCP standard body could decide what becomes part of the Open Java Core. Sun would still retain the veto, and the Java J2ME, J2SE and J2EE brand would be still be protected under trademark law.

  Developers would only be required to shift changes to the vendors/developers namespace if the changes were incompatable with the JCP JSR open standards. This would not prevent the development/distribution of additional optimizations, ports or bug fixes. Since close adherance to standards has for a long time been an open source tradition, it would not be much of an imposition.

  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.

  In fact, according to Jonathan Schwartz, Sun's recently appointed president and chief operating officer, Sun is considing GPL license for Solaris.

  Posted by: nzheretic on May 05, 2004 at 05:30 AM

• Pity Sun's write once Java dream, which Microsoft continues to screw
  Sure, Sun's CEOs claim that they need to maintain tight control over the Java library source code and standards to insure Java cross vendor "write-once" portability. This was the main point for Sun's lawsuit against Microsoft. In fact, in the DOJ case the federal appeal court did find that Microsoft had deceived Java developers, which the court decided was in breach of the Sherman Antitust act.
  For Sun to call their settlement anything but a sellout, Sun could at least persuaded Microsoft to create or adopt a modern release of Java to replace the 1997 eon MSJava JVM. Instead Microsoft gained the right to extends life of its Java Virtual Machine to December 31, 2007 . Microsoft have stated that it will not be improving ( or updating ) the old JVM and Microsoft's J# "upgrade path" still uses non-standard interfaces for GUI's and .NET libraries. This leaves Microsoft free to play the old "standard" embrace, extend and enclose anti-competitive tactics.
  Sun's CEO has already spread the cheeks.
  

  Posted by: nzheretic on May 05, 2004 at 05:36 AM

• James Gosling, are you really listening? Here's what's wrong with SCSL:
  Well, OK, I keep hearing that SCSL is 'as good as open-source', 'not viral like the GPL', 'provides safeguards for java developers' and what not.

  The trouble with that sort of 'marketing spin' of SCSL is that it's plain wrong. I've looked at the SCSL that covers J2SE source code, and it's one of the most restrictive licenses I've ever seen.

  Not only is it not nearly as open-source as James would like you to believe (it meets just 2 out of 10 criteria for open source), it is also way more viral that the GPL (it claims that all Java code you'll ever write is covered by SCSL), prohibts you from licensing your code as you wish (you may not GPL your libraries), it also forbids debugging the library code, talking about Sun's specification compliance, or god-forbid, writing your own tests.

  I've blogged about some the nuggets that can be found in the 'as good as open-source without 80% excess freedoms' SCSL here: http://www.advogato.org/person/robilad/diary.html?start=46

  Copyright notice as per Terms of Participation:
  Copyright (c) 2004, Dalibor Topic, All Rights Reserved.
  All Code In This Post Is Covered By The GPL.

  Posted by: robilad on May 05, 2004 at 09:56 AM

• Another rehash of the open source issue
  Novell's Mono project (http://www.go-mono.com/download.html) is the closest... but it has its own problems....

  Posted by: pulse1014 on May 05, 2004 at 06:41 PM

• Don't open-source Java, stop wasting bandwidth
  No, it's not stagnant and it's strong - but it's going to lose if it doesn't gain more momentum. Riding with the fastest growing OS in the world (once Java becomes open) will make Java even stronger - and untouchable by .NET and related MS technologies like XAML crack (http://www.xaml.net/).

  Posted by: pulse1014 on May 05, 2004 at 06:45 PM

• Don't open-source Java, stop wasting bandwidth
  I can run Java programs on Linux just fine right now. Consumers do not give a damn if Java is open source or not.

  If Java did not exist for Linux, then I'd agree.

  Posted by: rabbe on May 05, 2004 at 07:58 PM

• Another rehash of the open source issue
  It's really not cross platform either. The byte code generated is not ever the same as what is generated under Windows.

  Mono is a far cry from being a Java replacement.

  Posted by: rabbe on May 05, 2004 at 08:00 PM

• Eating Sun's lunch...
  Yep and then the whining would finally stop!
  

  Posted by: rabbe on May 05, 2004 at 08:00 PM

• Another rehash of the open source issue
  kaffe doesn't cut it. if it did we wouldn't be having this discussion.

  Posted by: rabbe on May 05, 2004 at 08:01 PM

• I will look at those links
  I will look at the links you referenced, except Slashdot (haven't bothered to read anything there since '98 or so due to too much noise). Your response to #1 doesn't address the seriousness of the 'bugs'. Couldn't a JSR or something through the JCP address this if it's really a problem? Your response to #2 implies that Classpath and Kaffe will die off if Java is open-sourced? I would think open-source advocates would not want that to happen. My gut feeling is that forking will still happen because testing with the TCK won't happen, but I'll need to reed your's and murphee's references first. Also, these 'other' platforms that are not up-to-date, what's preventing them from getting up-to-date? There was certainly a groundswell from Linux users that got a JVM off the ground and up-to-date. I wonder if it's not the platform users that aren't paying enough attention to Java rather than Sun? Not sure. Gotta go do some reading...

  Posted by: gerryg on May 05, 2004 at 08:46 PM

• Don't open-source Java, stop wasting bandwidth
  Nothing is untouchable. Nothing should be. Java will get replaced, and so will .Net and XAML. Characterization of Java as falling behind or in a tenuous position have more effect on Java momentum than whether it's open-source or not. I do agree that there should be the ability to ship Java binaries with Linux distributions, though. Not sure if that requires an open-source license, though.

  Posted by: gerryg on May 05, 2004 at 08:51 PM

• Just the Java J2ME,J2SE,J2EE Libraries
  Vendors don't usually like to all use the same "core" libraries, because with profit as a motive they want something to differentiate themselves. Whether all vendors could survive as purely service and training companies is unknown, but most vendors would like to have a hook, which is a technology difference or uniqueness that only they have, in order to reel in customers. Force a lot of requirements and take aware all the differences and I think the vendor pool will dry up as they go figure out something else to do.

  Sun wants to open-source Solaris because they're losing market share to Linux. Solaris is still the best OS implementation on Sparc, and that's their hardware bread & butter. Java is in a different situation that either Solaris or *Office, so comparisions are more apples to oranges to pears.

  Posted by: gerryg on May 05, 2004 at 08:57 PM

• Vendors don't have to use *all* the same "core" libraries - just provide the same standard interface
  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.
  

  Posted by: nzheretic on May 05, 2004 at 10:16 PM

• I will look at those links
  Q) "Also, these 'other' platforms that are not up-to-date, what's preventing them from getting up-to-date?"

  A) A license problem, for starters:
  http://www.debian.org/doc/manuals/debian-java-faq/ch5.html

  This might already be linked in one of my other posts.
  

  Posted by: philwebster on May 06, 2004 at 01:46 AM

• Don't open-source Java, stop wasting bandwidth
  You're right consumers don't - then again consumers don't know .NET from Java. Developers do care though. More developers woud be programming in Java if they shipped with Linux distros. Currently, it is a lot of trouble to install java on linux - if you're new to the language and what to just try it out. Unlike other languages that ship with Linux you actually have to go out and grab the download, etc...

  Posted by: pulse1014 on May 06, 2004 at 06:23 AM

• A few comments
  Perhaps I was exaggerating when I said failed. J2ME is finally starting to come together. But it's taken several revisions and five years for it to happen. I played with the J2ME demo at Palm One 1999. It's taken five years for Palm to actually ship a JVM, and it's still fairly limited. Every time I have tried to write a J2ME app I have had to struggle with platform specific bugs, missing (but required) features, or simply being hemmed in with no access to do something useful unless I used proprietary extensions which rendered my application non-portable. Now that it's 2004 I think J2ME may finally be ready for prime time. Incompatible JVMs was one of the prime reasons it's taken so long for this to happen.

  On fragmentation you are completely right. We have a ton of jmvs with differences, and I fear that those differences would grow with opensourcing. This is not to say that it would necessarily happen, but we would need a very carefully considered license, which would in some ways be more restrictive than todays, to make it happen.

  I do think that as far as desktop Java goes Sun has bitten off more than it can chew, or at least no longer has the resources it once did. I'd like to see the implementation for Swing be available under some sort of open license so that we can all contribute and fix the bugs. My concern is once again the compatibility issues. What happens when people are running under beta distributions or have proprietary changes. In large companies, when they standardize on a JRE they stay there for years. If they happen to standardize on a variant with some issues then three years later the issues may be fixed but you, as a developer, can't be sure your code will work. This is always the problem with point releases. Any plan to open source Java needs to take this in to consideration. When Sun releases, say 1.5, that will be the offical 1.5 and anyone who writes to 1.5 will know that it will really work.
  

  Posted by: joshy on May 06, 2004 at 07:47 AM

• Why to stick to exactly one of two extreme positions?
  I don't understand why the two sides keep holding extreme positions?
  One is saying “only one-company ownership will prevent java from chaos and forking”, other side is arguing “only GPL will save java from being pushed to legacy status by C#”.

  Why should we stick to GPL or any other existing license? Don't we have brains to create a license specific to our needs?

  The obvious way of solving the issue is creation of nonprofitable corporation by all interested vendors and major OS projects like Eclipse project did. That corporation will hold java IP rights and will maintain the platform development just like Linus maintains Linux OS core development.

  Special license and corporation statute should protect java from possible destructive attacks by gaining control over the corporation or forking the technology.

  IP belonging to a legal entity will prevent from forking, public status of this entity will prevent the platform from becoming proprietary and encourage ISVs and OS developers' contribution.
  

  Posted by: tarasd61 on May 14, 2004 at 07:31 AM

• Which license? Dual license
  Several open source projects already have dual licenses and isn't it such a kind of thing with Open/Star Office?

  Posted by: avdyk on August 05, 2004 at 08:37 AM

• Miscellaneous responses
  I don't understand how both the monoculture argument
  and the anti-forking argument can both be true.
  Isn't every difference, no matter how minute, really like
  having a fork? Doesn't this always hurt Java WORA
  property? It seems to me that it does. Even minor
  differences have to be debugged and actively worked
  around, I've seen this many times in real code. I've also
  had to add compatibility hacks, more than once, to gcj
  in order to run real java applications, as the spec is unclear or they rely on implemenation peculiarities of
  one VM.

  I rebut some of the other points

  here. There are some older posts here explaining some other facets of this debate as well; in particular
  in there somewhere is an explanation of why forking is a non-problem. Dalibor explains this somewhere too.

  I think this quote is interesting: "I think that they are worried about a large vendor capturing a significant portion of the community, most likely IBM." What would
  that mean in an Open Source context? Only that IBM
  is donating a lot of work to the project. This is positive,
  not negative.

  Posted by: tromey on August 05, 2004 at 09:57 AM

• This is not a waste of time!
  I don't care Java to be opensource, but I'd like to be able to distribute Java to my users. With the actual license of the JDK/JRE, I can not distribute Java in Debian. That is really important to me! Debian supports 12 GNU/Linux ports, plus GNU/Hurd, GNU/NetBSD (i386 and alpha) and GNU/FreeBSD. Debian runs everywhere... Java not!
  

  Posted by: avdyk on August 05, 2004 at 03:17 PM

• Java does not run everywhere!
  Sun has a x86 and AMD64 implementations of Java. Thanks to IBM for the powerpc port (but where is the webplugin for 1.4? and where is the 1.5? sorry, I meant j2sdk5.0). And we can not ship our OS with Java!

  Posted by: avdyk on August 05, 2004 at 03:33 PM

• Hello.

  If anyone is interested in the Java Media Framework, we have a few configuration pages for it:

  JMF on coderslog

  Thank you for your time.

  Posted by: screenedtwenty on June 01, 2007 at 05:30 PM

This work is licensed under a Creative Commons License.