John D. Mitchell's Blog

Sun considering some sort of "open source" for Java, maybe

Gee, could this be any more wishy-washy? This article in the Inquirer quotes Sun's Java Technology Evangelist, Raghavan Srinivas saying that there will be an open sourced version of Java: "It might be today, tomorrow or two years down the road."

Ah, the original source article has a bit more information.

Comments

• time to brush up those cobol and C++ skills
  because if that happens large corporations especially will seek to drop Java, destroying the marketability of our skills.

  Posted by: jwenting on June 03, 2004 at 11:13 PM

• time to brush up those cobol and C++ skills
  Heh, how stange : large corporations are dropping solaris to go for linux, even if it is open source. Large corporations have used emacs, gcc, bash and hundreds of other open source software for years, without complaining they were open source. Those are real facts. What arguments do you have to show to support your claims, besides just your opinion?

  Stop spreading lies.

  Posted by: sergiogarcia on June 04, 2004 at 01:30 AM

• FUD
  WHY would they want to do that? Post evidence to back up an argument.

  An argument without any foundation is worthless.
  Here's why:

  Just saying 'I think THIS' means nothing to anyone else but you.
  Are you trying to pursuade everyone that Libre-licensed Java is bad? If so, rational and reasoned debate is the only way to achieve that.

  --Arguably in the Java.net audience's core fields (Computer Science and Software Engineering) rational tohught and reason should be the only way to achieve anything. This isn't Slashdot. Speak sense or don't speak at all.

  Or do you think we should all start opposing Libre Java because some 'jwenting' guy on Java.net says so?

  Are you trying to simply let everyone know what you think? In that case, why should anyone *care* about your opinion, if it is not an opinion which can be shown to be based on reason and logic?

  Posted by: philwebster on June 04, 2004 at 01:40 AM

• Moderation is required on Java.net
  "What arguments do you have to show to support your claims, besides just your opinion? "
  He doesn't have any. Ideally these forums should have moderators to prevent those kinds of posts from contaminating the discussion with FUD.

  Also, you forgot to mention the Apache HTTP Server, which is also open source and has unquestionable corporate popularity.

  Posted by: philwebster on June 04, 2004 at 01:44 AM

• time to brush up those cobol and C++ skills
  That seems like an absurd proposal.

  I work for a large (3000+ employees) software development coorporation doing doing all kinds of development (PL/1, COBOL, C++, Java and .NET)

  I say that non of our Java-projects are free of open source code - for testing, development tools or library funcionality (the apache libraries and tools mostly)

  I can also say with some confidence that if it wasn't for Apache and the vibrant open source communities around Java we would be doing a lot less java and more .NET

  Posted by: biehl on June 04, 2004 at 12:02 PM

• It makes a lot of sense for Sun to open source the Java Libraries and Solaris Kernel
  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.

  
  

  Posted by: nzheretic on June 05, 2004 at 07:37 AM

• Not
  Sun has clarified it's position.
  

  Posted by: johnm on June 05, 2004 at 04:46 PM

• Dual licencing is useless.
  Your suggestion that a dual-licence could be used is not going to work.

  If a copyrighted work can be released under two different licences the content has to be owned by Sun for it to re-release its own work under an incompatible licence. So copyright has to be transferred to Sun if I post a patch to them.

  If Sun has to accept my code and my copyright has to be transferred to Sun I can tell you that Sun will want my signature or something that the code is actually mine to give.

  This papertrail will make sure that the 'original' codebase of Sun will be the last to get any patches; if at all. So if a fork exists it will surely have less bugs for that simple reason.

  Second problem here is that if I have to pass my copyright to Sun is that we are back at square one; its not much different from the current situation where fixes I submit can not be re-used in other projects (like classpath) since I can only transfer copyright of the code to one of the two parties. Personally I would always choose Classpath to sent patches to.
  Further if the code is no longer my property I have to trust Sun to release it under the open-source-compatible licence since they can always choose to just release it the closed-sourced version.

  Posted by: zander on June 07, 2004 at 03:31 AM

• Dual licencing is being used
  Firstly, the dual licencing approach is being successfully used by Trolltech, the QT ( the base of KDE ) developers, and the MySQL 4 project. Both projects require that source code contributers assign copyright over for non-trivial patches before the source is added to project. In most cases, fixes involve trivial patches to the source code and can be also safely incorporated.
  Dispite the fact that both products are widely used by in open source community and by many competing vendors , there is no plethora of competing forks of either QT or MySQL4. The major reason for this is that both the QT and MySQL vendors do such a good job managing the source code, to the point where the MySQL source code is a magnitude higher quality than any competing proprietary product.
  In reality, well managed open source projects, including dual licensed projects, lose very little of their market share to forks of the same source code. In reality, even dual licensed projects, such as MySQL and QT, are the first to receive patches to fixes.
  As for the issue of the paper trail and assigning copyrights, the Free Software Foundation has requested contributers to assign over copyright for all large code contributions. Major projects such as the GCC compiler toolset has been develop under this scheme for over a decade. There is no reason why a similar system could not be adopted, assigning the copyright over to the JCP Organization instead of Sun itself.

  
  

  Posted by: nzheretic on June 07, 2004 at 04:50 AM

• Re: Dual licencing is being used
  First off; my post explained some problems which are unique to Sun and Java due to its size and background, you did not get into them except for countering with examples that IMO are quite different, and not entirely true either.

  I have absolutely no knowledge about MySQL, but I have a long time experience with Qt (which is written with a lowercast 't' btw).
  The things you say are not really accurate; the fact that KDE maintains a CVS of Qt for its members, including patches that fix bugs is very important point that you missed.

  You say that the 2 mentioned vendors do a great job of managing the source code. While my example in the previous parag disagrees somewhat with that statement the point is useless in the Sun case; who says Sun will do just as fine? Don't forget that both cases you picked got big from writing an open source toolkit from scratch.

  Further the paper-trail I mentioned is not needed in Qt, I doubt MySQL will ask for it. Don't underestimate the difference between easily forwarding a fix and having to sign a paper so your fix may be used by others!!

  You boldy say that Qt (and MySQL) are the first to receive patches to fixes is not true; and if you have more then a couple of hours of KDE mailinglist-reading under your belt you'd know that. I have had many good hacking-session with Trolltech employees; but they all say that (rightly so) paying customers always go before open source developments. Nobody is blaming them; but don't act like thats not the truth.

  One very important point you missed is my concern that Sun may not find it in their best interrest to release my code dual-licenced in a year time. Making me loose a LOT. This is saveguarded against in Qt by a concract Trolltech has with KDE e.v. that they will release Qt under a BSD licence if no GPL releases have been made of code for a certain period of time. That contract is the sole reason why lots of developers accept the dual-licence 'problems'.

  These points make me feel dual-licence is a no-go and will make Sun as well as OSs hackers very dissapointed.
  The point from my last post which you have not countered (can't give away my property twice) only stand with that.

  Posted by: zander on June 07, 2004 at 10:38 AM

This work is licensed under a Creative Commons License.