What license would you like Sun's open-source JDK to use?

My pages	Projects	Communities	java.net

Search Web and Projects: Online Books: java.net on MarkMail: Advanced Search
		What license would you like Sun's open-source JDK to use? GPL 22% (214 votes) LGPL 15% (141 votes) Apache 31% (295 votes) CDDL 7% (66 votes) A custom license 4% (34 votes) Something else (please comment) 1% (12 votes) I don't want Sun to open-source its JDK 21% (203 votes) Total votes: 965 » Login or register to post comments 608 visits Printer-friendly version how to convert server localhost filder url to standard url type Submitted by san_2012 on Fri, 2007-03-30 05:59. i have problem in to convert the current url to new design url. now i am accessing my folder "http:\\122.23.232.121:8080\sandeep" now i waht to change it in my local area network access is "www.sandeep.com" how i will convert it . Login or register to post comments licenses Submitted by vasc_pt on Wed, 2006-11-08 19:44. I would use a GPL and LGPL combo. stronger GPL for the JVM, compiler and utilities, weaker LGPL for the Java library classes and anything else intended for reuse by 3rd party apps. This would be akin to the licensing scenario for C/C++ programmers on Linux which use the LGPLed libc and libstdc++ and GPLed GCC compiler. This will enable someone to write closed source programs using such a licensed Java version, which is an understandable concern here, while discouraging forking of Java proper. The alternative of using the Apache License or any other similar permissive non-copylefted license like the MIT license, is that by not enforcing a strong copyleft as the GPL does, will IMO lead to the continuation and proliferation of forking of Java versions, as is done today by IBM and others. Another copylefted possible alternative to the GNU GPL family of licenses would be the Eclipse Public License. It is also a copylefted license, albeit a bit weaker which may raise issues with in with GPLed code. As a possible bonus is it would provide for more source interoperability with the Eclipse community. Login or register to post comments finally making money out of java? Submitted by esac on Wed, 2006-11-08 14:06. As already pointed out GPLing java will mean you are forced to use the same license for your project using java and hence avoiding to make any commercial use of java. This is obliviously not feasible, as the only license, so SUN will use dual license (mysql way) one free and one commercial targeted at two different needs finally making money out of java... And what if I contribute back to the GPLed codebase ? Will my gpl source be released under a license I may not want to agree? Also in this scenario the viral effect of GPL will make all the opensource software released under other license (i.e. BSD/Apache) to move to GPL that's not feasible either. So SUN will need a third license or another custom license? For small software I think LGPL is the best way to force contribute back but if the poll were still open I would have voted for Apache/BSD the most "liberal", since the people fixing and enhancing the codebase have all the interest to contribute back and make the changes available to all. I'm not an license expert, these are just thought from a java developer, I probably got it wrong and I wish more developer comment on my statements and this important poll in general. Unfortunatly the poll is closed... my 0 cents Login or register to post comments Please Don't GPL Java Submitted by apperson on Wed, 2006-11-08 10:45. It is very unlikely that using a more open license will lead to platform-specific forks (how many forks of Apache projects can you find? Mozilla? Eclipse? yadda^3) OTOH commercial developers are VERY fearful of GPL, as it threatens to taint every code remotely related to it. (e.g. everything that links it) If you must use an RMS license, please use LGPL ("lesser" / "library" "liveable" ) GPL. That said, I''d vote for Apache, MIT-style, BSD-style, .... almost anything but GPL. Thank you. Login or register to post comments No GPL Submitted by npavlica on Tue, 2006-11-07 23:27. Licensing the JDK under the GPL would be a disaster. I hope that they use a license that is developer friendly. --Nick Login or register to post comments No GPL Submitted by npavlica on Tue, 2006-11-07 23:21. Licensing the JDK under the GPL would be a disaster for developers using this platform. The sad reality is that most people don't understand the GPL, and they think that it's the way to go because its what the Linux Kernel in licensed under. The reality is that the GPL is a horrible solution for development libraries. Please, Please don't use the GPL. --Nick Login or register to post comments No GPL Submitted by npavlica on Mon, 2006-11-13 11:58. Suns announcement on November 13th, 2006 that they were applying the "Classpath Extension", in addition to the GPL has put my licensing concerns to rest. The combination of the the GPL and the "Classpath Extension" is a Win Win (Very similar to the LGPL). I would like to retract my earlier statements, that were made under the assumption that Sun was releasing everything under the GPL without consideration for developers. This move really opens up allot of doors for the technology world. Thanks Sun! --Nick Pavlica Login or register to post comments Clarification Submitted by chunhui on Wed, 2006-08-23 20:21. Just to make sure I don't get misunderstood....the comments for GPL meant only GPL alone without Dual Licensing as discussed and suggested. Login or register to post comments Intro to licensing Submitted by chunhui on Wed, 2006-08-23 20:18. Not everyone is a software laywer (neither am I) so heres some basic info for people who voted GPL only in case they unwittingly ruin their own livelyhood. GPL - Highlight by the "copyleft" clause that states if you use any GPL licensed stuff your project have to be open source too. The result would be millions of Java professionals (unless you work for an open source project) would lose their jobs overnight and sun would lose a lot of Java revenue and declare bankrupt. LGPL, Apache, CDDS all similar, free for modification and proprietary usage. main differences being how they require documentation of modifications. For the other minor clauses, you either need to be very interested in software licensing or a software lawyer to want or need know. In which case this comment wouldn't be long enough to explain... read the actual license and research yourself...Wikipedia is a good place to start. All these license would not prevent forking. In Dual licensing - You apply both licenses to your stuff and note that users can choose either. Users can then user your stuff under License A OR License B. Login or register to post comments Forking is the bigest fear Submitted by jmguillemette on Wed, 2006-08-23 08:44. Open source is great. Compete on implementation .. but not SPECIFICATION. If the jdk forks we are all in a world of hurt! java will no longer be a universal enviroment. and there goes every advantage we have against other languages. Login or register to post comments Forking is the bigest fear Submitted by prime21 on Wed, 2006-08-23 10:26. You mean like how Perl has forked? And Python and Ruby? Oh wait, that's right -- none of those open sourced languages have forked. There's nothing stopping someone from forking Python and doing whatever, but those projects never have a significant following and they die off or are hopelessly irrelevant to the masses. When Java is open sourced it will be completely possible to fork it, but such an insignificant number of people will use that fork. It's nothing to worry about. Again, just look at other open source langs. Nothing to fear. -Bryan Login or register to post comments Forking is the bigest fear Submitted by liono on Wed, 2006-11-08 05:14. How about looking at how GCJ on Linux has "forked" Java? Its a disaster! Everytime I encounter someone who has problems with Java on Linux the first thing I ask is what Java version they're using. And guess what? They using gcj and replacing it with Sun's official JDK the problems are usually over. So please don't suggest that these kind of problems would never exist, they already do. As for Perl and the likes... How popular is it to use Perl on Windows? Just as popular as Java? I have some doubts there to be very honost... Login or register to post comments Must disallow forking at all costs Submitted by bharathch on Sat, 2006-08-19 23:09. The license should, at least, ensure that: * There are no forks OR * If derivatives are allowed, the end result should have no mention of Java anywhere - is it acceptable if someone changes the behavior of java.lang.String, and bundles the resulting runtime environment to a customer, claiming that its a Java-derivative? No. Period. The moment you modify something in the Java platform, its not Java anymore. Even the usage of he phrase "Java-like" should be prohibited. Login or register to post comments Must disallow forking at all costs Submitted by robogeek on Sat, 2006-11-11 07:08. Well, disallowing forks would not be an OSI-approved license. Disallowing forks would not be open source. The point of this exercise is to go open source. Your other point "no mention of Java anywhere" is an issue of the trademarks. Login or register to post comments Must disallow forking at all costs Submitted by tjpalmer on Mon, 2006-08-21 07:55. Of course Sun is allowed to take whatever measures they see fit to protect the Java trademark. As for forking, if it's open source, they have to allow forking to some extent. Ability to fork is just about the fundamental feature (not defect) of open source software. Ability to fork is a good thing. And the other good thing is that it seems Sun is getting a clue that people like compatibility. There's enough momementum and interest (and an established code base) to keep people on the same page for Java compatibility. Don't worry. Be happy. Not to say Sun doesn't have to worry. That's what they hire lawyers for. But they have a lot more to gain than lose out of making Java open source. If they play their cards right. Login or register to post comments Must disallow forking at all costs Submitted by jwenting on Mon, 2006-08-21 23:50. In fact it seems that Sun has forgotten about compatibillity. Opensourcing Java and the inevitable flood of forks that causes pretty much ensures that compatibillity is lost. Login or register to post comments Dual license : GPL + BinaryLicense Submitted by bjb on Sat, 2006-08-19 07:30. Hi, Only a dual license model can acheive the goals we have : prevent fork and go real opensource. With its viral nature, GPL is the only one that will ensure "predators.net" stay away from the cake. The binary builds of the Java project source tree would be released periodically under the "BinaryLicense" (same license as now). The source snapshots would be released under the GPL terms. Doing so, you can get a build and use it for whatever software usage you want (comercial or opensource). If you plan to make your own build and make any changes anywhere then simply, your code will become GPL as well, so the Java platform will be able to benefit from it if the EG of the JDK decide to merge it into the source tree ;-) This solution IMHO have the best of the two worlds : JCP body keep control on the JDK binary (the RI of the Java SE) and community got full sources to improve the platform and submit patched directly to the source tree. Please, tell me your thoughts on this .... Rgs, JB Login or register to post comments Dual license : GPL + BinaryLicense Submitted by jwenting on Sat, 2006-08-19 22:56. GPL would drive most companies and individuals away from using Java in the future for their own products. It's viral nature prevents it from being used to create software that requires the standard library to run which is of course ALL Java software. Instead the license should prohibit forking, or make it at the very least impossible to call a fork anything that even hints at it being derived from Java. That's the only way to maybe prevent massive confusion among end users over what is Java and what is not. The community even now has access to the full source and can submit patches, so nothing needs to change to get your best solution in place. But apparently Sun has had enough of Java and wants to dump it and all control over and responsibillity for it, which is of course their right. The ideal solution would not achieve that (as it would mean a continuation of the current system in which Sun has final say and control). Instead Sun will need a solution in which they keep total control over the trademark without having any control over the language specs and source code. Such a solution I fear is not possible, and the end result will be a highly fractured platform that is pretty much useless for development or run anywhere solutions because of the large number of mutually incompatible (at every level) styles of JVM that will exist. Login or register to post comments Dual license : GPL + BinaryLicense Submitted by bjb on Mon, 2006-08-21 12:05. Please, read my post again. It says Java must be under a dual license ! (GPL plus the binary license - same one as per now) GPL alone would do what you have said, but here it is about a dual license (GPL + same binary license as now) and there is a huge difference. So if anybody (say a firm or an individual) does not want to update the source then you directly pick the binary license version ! Then, you do not have any impact on your legal concern but the same one as per now (=same license = zero impact ) ! But if you plan to update the "Java SE RI sources" then the only solution for you would be to go for the source version that will be under GPL. And here the viral nature of GPL would help us to : prevent predator (do you think "big seatle" one would agree to have their own platform viraly under GPL ?), limit forking (Java platform is still Sun brand). As per the current rules, only modified Java SDK that passes the Java SE TCK can claim to stamp "Java compatible" ! This means, that if anything is done on the sources that break the platform compatibility, you will not be legaly able to use the "Java" word and claim compatibility for your own binary. This means in such a model, that the control will be at TCK side. TCK will prevent fragmentation as this is already doing at this time (see Harmony for instance) ! And if you want to do a "platform update" (something impacting for the platform) then this has to go thru the JCP in the corresponding JSR. And AFAIK, Sun have veto on Java SE JSR ;-) So practically, in this model : - Sun would have veto on platform change, - Sun would deliver RI binaries under "BinaryLicense" - Sun would host a source tree (like glassfish is doing for instance) for us to contribute - independent bodies (say apache) can use the RI source code and update it - update RI source can be build but not branded Java unless it passes the TCK I know it is a bit tricky, but this sound quite rock solid for me. The only legal point to solve, would be when checking in some GPL code into the RI tree you have to make the code author agree for "BinaryLicense" release of the binary. This mean, that anybody can pick the GPL form and build its own tree, where people would inject any GPL code. But : - he would not be able to release this under "Java" name if TCK is not green flashing - he can not send patch to RI tree of code not under its responsability ( key point here, a discuss has always to happen between the author of a patch and the code maintainers to decide of the interrest of the contribution). At the end, Java would be opensource but not a democracy because Sun would still be in control of the reference. Ey, but Linux kernel is not a democracy as well ... and who cares ? but RMS ;-) Vive Linus ! Login or register to post comments Dual license : GPL + BinaryLicense Submitted by jwenting on Mon, 2006-08-21 12:12. Problem is that if the language spec (and thus the TCK) are opensourced (which is the next step, the hawks will not call it opensource under any other condition, pragmatic people consider it open enough as it is now), anyone can just change the TCK to match their own changed language implementation and still call it Java. Sun will be powerless to prevent that, having lost control over the language itself. If you just want to create an open source implementation of the standard, you can do that today. The only reason to scream for Sun to release their implementation and as a consequence the language definition under a forkable license is precisely that, to fork in order to corrupt the language specification. Login or register to post comments Dual license : GPL + BinaryLicense Submitted by bjb on Mon, 2006-08-21 10:18. Please, read my post. It says Java must be under a dual license ! (GPL plus the binary license - same one as per now) GPL alone would do what you have said, but here it is about a dual license (GPL + same binary license as now) and there is a huge difference. So if anybody (say a firm or an individual) does not want to update the source then you directly pick the binary license version ! Then, you do not have any impact on your legal concern but the same one as per now (=same license = zero impact ) ! But if you plan to update the "Java SE RI sources" then the only solution for you would be to go for the source version that will be under GPL. And here the viral nature of GPL would help us to : prevent predator (do you think "big seatle" one would agree to have their own platform viraly under GPL ?), limit forking (Java platform is still Sun brand). As per the current rules, only modified Java SDK that passes the Java SE TCK can claim to stamp "Java compatible" ! This means, that if anything is done on the sources that break the platform compatibility, you will not be legaly able to use the "Java" word and claim compatibility for your own binary. This means in such a model, that the control will be at TCK side. TCK will prevent fragmentation as this is already doing at this time (see Harmony for instance) ! And if you want to do a "platform update" (something impacting for the platform) then this has to go thru the JCP in the corresponding JSR. And AFAIK, Sun have veto on Java SE JSR ;-) So practically, in this model : - Sun would have veto on platform change, - Sun would deliver RI binaries under "BinaryLicense" - Sun would host a source tree (like glassfish is doing for instance) for us to contribute - independent bodies (say apache) can use the RI source code and update it - update RI source can be build but not branded Java unless it passes the TCK I know it is a bit tricky, but this sound quite rock solid for me. The only legal point to solve, would be when checking in some GPL code into the RI tree you have to make the code author agree for "BinaryLicense" release of the binary. This mean, that anybody can pick the GPL form and build its own tree, where people would inject any GPL code. But : - he would not be able to release this under "Java" name if TCK is not green flashing - he can not send patch to RI tree of code not under its responsability ( key point here, a discuss has always to happen between the author of a patch and the code maintainers to decide of the interrest of the contribution). At the end, Java would be opensource but not a democracy because Sun would still be in control of the reference. Ey, but Linux kernel is not a democracy as well ... and who cares ? but RMS ;-) Vive Linus ! Login or register to post comments GPL and LGPL should be combined Submitted by weiqigao on Sat, 2006-08-19 06:07. I would have voted for a GPL + LGPL combination had that been one of the choices. You should really combine the GPL vote and the LGPL vote in the final count. Login or register to post comments does anyone have a good intro to licenses for developres? Submitted by ilazarte on Fri, 2006-08-18 10:25. i remember seeing something before, but I can't find it. Login or register to post comments The license must address the impetus for Open Sourcing Java/// Submitted by johnreynolds on Fri, 2006-08-18 09:14. Open sourcing Java is mainly about getting the JVM onto more devices, and Java utilized by more applications. The cult of GNU won't allow the JVM in their distributions unless it is released under a GNU-friendly licence, and GNUista developers won't use Java libraries unless they are also released under a GNU-friendly license. I am under the impression that the CDDL is GNU-friendly-enough... so it seems to make sense for Sun to use this license exclusively and free us from having to delve into the terms of multiple licenses. If I am incorrect, and GNU opposed the CDDL, then I'd change my vote. -JohnR Login or register to post comments The license must address the impetus for Open Sourcing Java/// Submitted by jwenting on Fri, 2006-08-18 22:40. The license rather must PREVENT people from forking the language. It's paramount that there not be a multitude of different implementations that are all called Java yet don't allow each others' classfiles (or sources) to be used. It must also ensure that you can release code created and compiled with the implementation under whatever license you choose, something licenses like the GPL don't allow which force you to use that same license for your own work making use of anything licensed under them. In fact the current licensing system for the platform works perfectly well, there's no reason to allow the wolves to gather around what will soon be the carcass of the Java platform when this ill advised scheme is completed. Login or register to post comments Forking ? Submitted by bjb on Mon, 2006-08-21 10:29. Can you tell me if what IBM has done with their Java SDK is not already "forking" ? And what about Harmony ? Is it different from a fork (on the platform risk ground) ? Java is not a software ! Java is a platform with specifications, test compatibility kits and a reference implementation. You can already create your own implementation and if it passes the TCK you can put "Java compatible" on it ! So actually, the same risk of forking are already there with third-party implementation. A dual license (GPL for source + Java BinaryLicense for binaries) is for me the solution : no changes for enterprises, improvement for the community ! Sun has to opensource the RI and going for a well-known license would ensure Java's success for decades. If opensource is there, then be sure another famous platform will have a serious problem for the next 5 years. Look, MS did not manage to kill Linux even with billions ! Linux is gaining momentum each days .... Login or register to post comments Forking ? Submitted by pholthuizen on Wed, 2006-08-23 00:37. Of course forking exists in some extend, but I think it should be made as hard as possible to do to prevent the old Microsoft JVM issue and such. Login or register to post comments The license must address the impetus for Open Sourcing Java/// Submitted by cbj on Mon, 2006-08-21 08:05. Several of your replies to comments indicate you believe Sun should prevent forking. What you really want is already in place however, and that is control over what can be called Java(tm). This insurance is provided through compatibility testing. Take a look at what webmink has posted regarding forking and why it isn't a concern now. Login or register to post comments The license must address the impetus for Open Sourcing Java/// Submitted by robilad on Fri, 2006-08-18 11:20. Dual licensing with GPL/CDDL would be fine. Unfortunately, CDDL alone is not GPL-compatible, so code licensed under it can't be used in GPLd programs. Login or register to post comments Avoid CDDL misunderstandings... Submitted by prime21 on Fri, 2006-08-18 10:29. The CDDL is fine and it is a true open source license -- ratified by the OSI. Great. The problem is that many, many, many, many open source users/developers don't know what the CDDL is -- and that worries them. They think that if Sun had to write up their own license instead of using an existing one, they've done so for some sneaky reason. This thinking has no merit, but perception _is_ reality. I have no problem with the CDDL, but if other -- more popular -- OSS licenses can accomplish the same thing then just use one of them for the sake of boosting Java adoption. On the other hand, Eclipse is released under an uncommon license (the Eclipse Public License) and no one has a problem with that. -Bryan Login or register to post comments

Search

What license would you like Sun's open-source JDK to use?