Showing messages 1 through 33 of 33.

• how to convert server localhost filder url to standard url type
  2007-03-30 05:59:42 san_2012 [Reply | View]
  
  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 .

• Little bit clarification on this
  2006-11-29 09:37:51 fachim [Reply | View]
  
  I think we have to read and understand the following documentations, hope these articles will give us clarification about GPL, Sun's initiative to GPLed Java and its pragmatic:
  
  http://www.sun.com/software/opensource/java/faq.jsp
  
  http://www.gnu.org/copyleft/gpl.html
  
  
  regards,
  
  fachim@dev.java.net

• licenses
  2006-11-08 18:44:11 vasc_pt [Reply | View]
  
  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.

• still not free btw...
  2006-11-08 14:29:26 esac [Reply | View]
  
  for background info on the license situation:
  http://software.newsforge.com/software/06/05/24/1154233.shtml?tid=150

• finally making money out of java?
  2006-11-08 13:06:46 esac [Reply | View]
  
  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

• Please Don't GPL Java
  2006-11-08 09:45:43 apperson [Reply | View]
  
  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.

• No GPL
  2006-11-07 22:27:10 npavlica [Reply | View]
  
  Licensing the JDK under the GPL would be a disaster. I hope that they use a license that is developer friendly.
  
  --Nick

• No GPL
  2006-11-07 22:21:27 npavlica [Reply | View]
  
  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
• No GPL
  2006-11-13 10:58:25 npavlica [Reply | View]
  
  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
  
  

• Clarification
  2006-08-23 20:21:45 chunhui [Reply | View]
  
  Just to make sure I don't get misunderstood....the comments for GPL meant only GPL alone without Dual Licensing as discussed and suggested.

• Intro to licensing
  2006-08-23 20:18:43 chunhui [Reply | View]
  
  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.

• Forking is the bigest fear
  2006-08-23 08:44:55 jmguillemette [Reply | View]
  
  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.
• Forking is the bigest fear
  2006-08-23 10:26:42 prime21 [Reply | View]
  
  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
• Forking is the bigest fear
  2006-11-08 04:14:26 liono [Reply | View]
  
  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...

• Must disallow forking at all costs
  2006-08-19 23:09:42 bharathch [Reply | View]
  
  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.
• Must disallow forking at all costs
  2006-11-11 06:08:18 robogeek [Reply | View]
  
  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.
• Must disallow forking at all costs
  2006-08-21 07:55:43 tjpalmer [Reply | View]
  
  

  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.

• Must disallow forking at all costs
  2006-08-21 23:50:49 jwenting [Reply | View]
  
  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.

• Dual license : GPL + BinaryLicense
  2006-08-19 07:30:44 bjb [Reply | View]
  
  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
• Dual license : GPL + BinaryLicense
  2006-08-19 22:56:45 jwenting [Reply | View]
  
  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.

• Dual license : GPL + BinaryLicense
  2006-08-21 12:05:06 bjb [Reply | View]
  
  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 !
• Dual license : GPL + BinaryLicense
  2006-08-21 12:12:32 jwenting [Reply | View]
  
  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.

• Dual license : GPL + BinaryLicense
  2006-08-21 10:18:28 bjb [Reply | View]
  
  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 !

• GPL and LGPL should be combined
  2006-08-19 06:07:08 weiqigao [Reply | View]
  
  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.

• does anyone have a good intro to licenses for developres?
  2006-08-18 10:25:50 ilazarte [Reply | View]
  
  i remember seeing something before, but I can't find it.

• The license must address the impetus for Open Sourcing Java///
  2006-08-18 09:14:17 johnreynolds [Reply | View]
  
  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

• The license must address the impetus for Open Sourcing Java///
  2006-08-18 22:40:20 jwenting [Reply | View]
  
  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.

• Forking ?
  2006-08-21 10:29:13 bjb [Reply | View]
  
  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 ....
• Forking ?
  2006-08-23 00:37:40 pholthuizen [Reply | View]
  
  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.
• The license must address the impetus for Open Sourcing Java///
  2006-08-21 08:05:11 cbj [Reply | View]
  
  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.
• The license must address the impetus for Open Sourcing Java///
  2006-08-18 11:20:22 robilad [Reply | View]
  
  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.
• Avoid CDDL misunderstandings...
  2006-08-18 10:29:51 prime21 [Reply | View]
  
  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

• Are you prepared to choose the next JDK license?
  2006-08-18 08:42:07 felipegaucho [Reply | View]
  
  http://weblogs.java.net/blog/felipegaucho/archive/2006/08/are_you_prepare_1.html