Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×

Sun to Change Java License for Linux 226

daria42 writes "It looks like the days of downloading Java every time you re-install a Linux box may be at an end. Reports are trickling in that Sun plans to alter the Java license to make it easier to bundle the JRE with Linux. From the article: 'Sun has faced calls several times to open-source Java, which advocates say would foster innovative open-source development. The company has resisted formally open-sourcing all of the Java software, but it has dramatically changed the development process around Java and changed licenses to make it easier to see Java source code.'"
This discussion has been archived. No new comments can be posted.

Sun to Change Java License for Linux

Comments Filter:
  • Hard.. (Score:5, Insightful)

    by ZoWnX ( 710685 ) <[moc][tod][xnwoz][ta][xnwoz]> on Friday May 05, 2006 @08:49AM (#15269350)
    Because downloading the JDK or the JRE after installing linux was hard? If it wasnt for this, I wouldnt be periodically using the latest version.
  • Re:Hard.. (Score:3, Insightful)

    by $RANDOMLUSER ( 804576 ) on Friday May 05, 2006 @08:55AM (#15269368)
    Exactly. Especially if you're running multiple versions of Java. What really annoys me is RPMs that expect an RPM-installed Java.
  • Re:Hard.. (Score:5, Insightful)

    by CastrTroy ( 595695 ) on Friday May 05, 2006 @08:55AM (#15269369)
    I think it has more to do with having the distro do it for you. If we want Joe User to be able to use linux for their desktop needs, then we are going to have to make it as easy as possible for them to use. Of course the people in control of the distro are the ones making the decision. If they don't want to include it because of some ideological values, then that's their business. If they feel the people using the OS has can just install it themselves, then that's their business. But if they're trying to put out an easy to use desktop distro, then they'd probably be smart thinking twice about including it.
  • by CustomDesigned ( 250089 ) <stuart@gathman.org> on Friday May 05, 2006 @08:58AM (#15269385) Homepage Journal
    Sun provides an open spec (actually multiple specs). There are open source implementations of the spec. Sun and others have proprietary implementations. There are applications where the open source implementations are superior (typically small memory and embedded). If you have tons of memory, Sun's Hotspot VM is very fast.

    If there are areas where the specs need improvement to get closer to the "Write Once Run Anywhere" goal, by all means complain about those areas.

    We want multiple competing implementations, both open and proprietary. That said, I could see Sun open sourcing the Java libraries - at least the Java parts. The SDK comes with Sun source for the publically visible parts of libraries. However, the licence precludes using that source in an open source VM. Instead, the GNU classpath project has to rewrite them from the spec.

    Keeping the Sun VM proprietary but opensourcing the libraries seems like a good compromise between maximum interoperability and competition.

  • Limits? (Score:4, Insightful)

    by J.Y.Kelly ( 828209 ) on Friday May 05, 2006 @09:00AM (#15269396)
    Unfortunately the article is a bit light on details. It says that Sun are going to make the JRE easier to redistribute but that on it's own isn't enough for many distros. It would also have to be at least able to be repackaged (so it goes somewhere more friendly that the Sun supplied RPM) and preferably modified (to make it play nicer with the rest of the system) before it's really useful.

    Also, it's a shame it seems they're only going to include the JRE. Nice and easy for linux users to run java programs. Shame they won't be able to write any...
  • by davecb ( 6526 ) * <davecb@spamcop.net> on Friday May 05, 2006 @09:11AM (#15269441) Homepage Journal
    Now that they've released their newest chipset under the GPL, they're going around and looking to see how much they can loosen their other licenses.

    Java, due to MS's efforts to subvert it, is probably the hardest to free up, but this is a good, workmanlike step in the right direction.

    --dave

  • by The Warlock ( 701535 ) on Friday May 05, 2006 @09:13AM (#15269449)
    The problem is that the open-source implementations of Java tend to be a version or two behind the official Java, which can be a problem for some Linux users (such as CS students like myself).
  • by Anonymous Coward on Friday May 05, 2006 @09:14AM (#15269452)
    Keeping the Sun VM proprietary but opensourcing the libraries seems like a good compromise between maximum interoperability and competition.

    Which is exactly why it'll never happen. The giant Java library ensures that, even with a 100% compatible JVM, most Java applications will only run on the Sun runtime. (Especially applications that use "sun.*" or "com.sun.*" packages in open defiance of Sun themselves saying not to do that. But that's beside the point.)

    Sun learned from their experience with Microsoft. When Microsoft had their own JVM implementation, Microsoft added various extra libraries and functionality to their runtime that Sun was missing. Sun responded by sueing, and forcing Microsoft to remove their JVM from Windows. (And then Sun responded to that by sueing Microsoft for removing their JVM from Windows...)

    By having a massive and hard to implement class library, Sun ensures that anyone else trying to create a compatible Java runtime will always be playing catch-up. They'll never be able to be 100% compatible with the "latest and greatest" Java runtime.

    And that's just the way Sun wants it - they're able to keep control of Java that way. Open sourcing the libraries would cause them to lose that control. And that's why it'll never happen.

    (It's worth noting that the source for all the classes that appear in java.* and javax.* are, indeed, available with the Sun JDK. However, the license prevents doing anything useful with them, and much of those classes rely on large amounts of code implemented in com.sun.* or sun.* packages, for which the source is NOT available.)
  • foster? (Score:4, Insightful)

    by dghcasp ( 459766 ) on Friday May 05, 2006 @09:15AM (#15269456)

    ... advocates say [open-souring Java] would foster innovative open-source development.

    Because there are so few innovative open source java projects right now? Heck, I can hardly keep track.

    Leaving aside the politics of open source, and the "I can't play with your toys" argument, the main issue here seems to be the license incompatability that keeps Java from being bundled with the 267 different Linux distributions.

    If people want to be innovative, how about working to unify the basic functionality of all those distributions, specifically one common, simple way that works on all distributions and architectures to install 3rd party packages, like, say, Java?

    ObMetaDig: And besides, why do you care? Every time I see java on /., the whole thread seems to be "it's slow / no it isn't / GC sucks / no it doesn't / .NET rules / no it doesn't"

  • by tomcres ( 925786 ) on Friday May 05, 2006 @09:16AM (#15269460)
    That's because Mr. Volkerding cares more about his users' experience in providing something that just works, works reliably, and is complete than ideology and software politics.. Slackware has been including xv (a shareware image viewer) since like Slackware 1.0..
  • by gvc ( 167165 ) on Friday May 05, 2006 @09:38AM (#15269576)
    I don't see how this is any different from tainted binary kernel drivers. They'll allow redistribution of the JRE run-time environment. Big deal.

    If they allowed redistribution of JDK compiler and libraries, we'd be making progress.

    Nothing to see here. Move along.
  • by Anonymous Coward on Friday May 05, 2006 @09:39AM (#15269586)
    This really comes down to marketing. Even if Java is useful for a majority of customers, Microsoft will not provide it because Java could diminish the effectiveness of their business strategy.

    This is a dangerous game to play - at what point does Microsoft stop supporting their customers for the sake of their business strategy? Some will say that that time came long ago, and that it is an implicit sign of anti-competetive, monopolistic practices. I disagree - as some could claim that Java is simply not appropriate for most users, and if it is required, then the user may install it.

    I think Microsoft's lack of proper open document support, as required by some local laws, is a much more glaring example of Microsoft's overt anti-commerse behaviours.
  • 64-bit? (Score:4, Insightful)

    by escay ( 923320 ) on Friday May 05, 2006 @09:43AM (#15269607) Journal
    well they could start with providing the mozilla-firefox java plugin for amd64 systems on linux...libjavaplugin.so, anyone?
  • by davecb ( 6526 ) * <davecb@spamcop.net> on Friday May 05, 2006 @09:51AM (#15269652) Homepage Journal
    Because MS tried so very hard to embrace and extand Java, it's reasonable to expect that the Sun lawyers are going to be very reluctant to change anything, for fear of starting the war back up.

    Sun engineers, on the other hand, arguably agree with your desire to move to free reference implemntation, and in the short term, to fewer restrictions on the JRE.

    --dave

  • by /ASCII ( 86998 ) on Friday May 05, 2006 @09:54AM (#15269670) Homepage
    The way I see it, there are three relevant levels of openness here:

    * A standard which is well defined, whose license can not be arbitrarily terminated and is provided to everybody free of charge or at a reasonable cost. (This is the most important one)
    * An open sourced reference implementation of that standard, prefereably released under the BSD licence so anybody can extend it. (This is nice but not crucial)
    * An open standards process. (If the standard is stable and well written, this is not all that important)

    Sun is doing the first but is avoid doing the second by giving the strawman argument that it would somehow imply the third.
  • by /ASCII ( 86998 ) on Friday May 05, 2006 @09:56AM (#15269685) Homepage
    Yes, but my argument is that the standard and an implementation of that standard are two completely separate things. They are using the argument that by opening up their reference implementation, the standard itself is opened, and that is just plain false.
  • Re:whocares (Score:1, Insightful)

    by Anonymous Coward on Friday May 05, 2006 @10:01AM (#15269710)
    If you really don't care, why are you posting here? Me thinks secretly you must care a lot.

    Why do you care what he cares? Furthermore, how can you justify Java on Linux? Java isn't needed, it's not Free or open source, and compiling it is a pain in the ass. Why should Linux users use a proprietary language born out of a greedy corporation when there are better FOSS alternatives available?
  • by benmhall ( 9092 ) on Friday May 05, 2006 @10:06AM (#15269752) Homepage Journal
    I've never really understood why Sun doesn't just dual-license the Java VM and libraries like it does with OpenOffice. This would allow Linux distributions to include both the JDK and JRE and wouldn't preclude commercial developments. This wouldn't be that different from what Trolltech does with Qt. With Qt, this limits commercial KDE development, but Java already enjoys strong commercial support. If they GPL'd (not LGPL) the JDK, they would open doors to the Open Source community while still supporting their commercial contracts.

    I wouldn't think that forks would be a big problem either, as everyone would likely stick to Sun's JDK by default. I certainly haven't run into IBM's JVM very often and one needs to look no further than Mozilla, OpenOffice.org and Qt for evidence that dual-licensing doesn't necessarily lead to uncontrolled forks.

    The truly bizarre thing to me is that this hasn't already happened. It's not like Sun is trying to keep Java sources secret. They've already exposed them to the world with their fairly liberal research license.

    Mayber things will change. I'm reminded of Eric Sink's comment on Slashdot years ago regarding open sourcing OOo:

    "The only glimmer of hope has been Sun, which seems to have a practice of being smart during the even-numbered years and downright silly during the odd-numbered ones."

  • We already have open source Java
    Yeah, and they don't work correctly. Just yesterday I was helping a person at work with their code. They had a Java program that was doing an LDAP query. It worked fine on other machines but not on one of the test machines. Turns out some JRE called Kaffe was in the path before the Sun JRE. Changing the path to the java executable fixed things.
  • by LnxAddct ( 679316 ) <sgk25@drexel.edu> on Friday May 05, 2006 @10:19AM (#15269835)
    Dumb idea, and that is why you aren't in charge of these things. One of the biggest pains in the ass with perl software is that whenever you run it you have to read a 20 page reamde saying "Before you run this program, you need to run this list of commands in this order so you can install the dependencies." In good scenarios you just run a script first, or in some circumstances you can use the distro's package management, but regardless it is a pain in the ass. Java's "everything and the kitchen sink" approach is way better. You no longer concern yourself with such nonsense. If you distribute a java program, you'll know the receiver has the capability to do graphics, encryption, compression, sound, XML handling, networking, etc... all without having to lift a finger. Java is a platform. I only wish more languages, in particular Python, would get a set of libraries that is as comprehensive as Java's and comes by default. Keep in mind that since the 5.0 JDK you've been able to create a minimal redistributable JRE that includes only what your program needs to run (you use pak200, which is a utility that comes with Java 5.0), but by default the JRE should definitely include everything... it makes life and integration soooo much easier in the end.
    Regards,
    Steve
  • by Tim C ( 15259 ) on Friday May 05, 2006 @10:23AM (#15269853)
    Microsoft. When Microsoft had their own JVM implementation, Microsoft added various extra libraries and functionality to their runtime that Sun was missing. Sun responded by sueing

    MS added classes to the java.* package hierarchy, in contravention to the terms of their licence. That's why Sun sued. Had MS put their classes in a com.microsoft package hierarchy like you're supposed to, Sun wouldn't have cared (or had a leg to stand on).

    The restriction was/is in the licence to prevent exactly what started to happen - people started using the classes, and thus were writing code that could only run on MS's VM, which is completely against the core Java ethos of "write once, run anywhere". (Ok, so in practice that's often easier said than done, but this was threatening to make it completely impossible)

    For what it's worth, MS didn't have to stop shipping a VM with Windows; they just had to stop shipping their non-compliant VM. They were perfectly at liberty to remove the offending classes and continue developing a compliant VM. Instead they chose not to do so, shifting their efforts to .NET instead.

    Especially applications that use "sun.*" or "com.sun.*" packages in open defiance of Sun themselves saying not to do that.

    That's a really dumb thing to do if you care about cross-release compatibility. There's no guarantee whatsoever that classes that are present in one release will be present in the next.
  • by JakusMinimus ( 49854 ) on Friday May 05, 2006 @10:32AM (#15269908) Homepage Journal
    that is a smart distinction to make, but i feel comfortable in declaring that sun's position (for the now) is that they will have better long term control over the standard/spec by maintaining control over the reference implementation. it is also worth noting that the reference implemnentation is of very, very good quality.

    and no, im not a sun fanboi, but i am primarily a j2ee developer.
  • Re:I'd Be Happy (Score:1, Insightful)

    by Anonymous Coward on Friday May 05, 2006 @10:35AM (#15269924)
    There's no way to get OS-Specific permission settings on a File. For that reason if you try to archive some files in Java using an InputStream that takes Files, you'll lose the permissions settings on them and the files will restored with something both generic and useless like 644. They make a halfhearted attempt to address this in 1.5, but it's still useless.

    It would appear that the only way to get disk space left on the volume is to open a file and start writing 1 byte at a time until you get an IO Exception.


    Might want to read up on Java 1.6 as I believe both of these issues have been solved.
  • by raitchison ( 734047 ) <robert@aitchison.org> on Friday May 05, 2006 @10:53AM (#15270064) Homepage Journal
    All joking aside, Windows users actually would stand to benefit the most from open sourcing Java. The Sun JRE, which virtually ALL Java apps are arbitrarily dependent on is one of the worst apps I've ever seen when it comes to memory utilization.

    I've seen Win32 apps consuming 150Mb of RAM.

    If Sun were to open source Java it could open the door to different, better JVMs that might even be able to spoof itself as "Sun JRE" for the myriad of poorly written Java apps that refuse to run on anything else.
  • Re:Hard.. (Score:3, Insightful)

    by master_p ( 608214 ) on Friday May 05, 2006 @11:15AM (#15270256)
    Not everyone has internet access all the time or fast internet access. Don't forget that Linux is also distributed by magazines, then the Linux CDs are passed around to people that might not have internet access at the time or not have fast internet access.
  • Re:Hard.. (Score:1, Insightful)

    by Anonymous Coward on Friday May 05, 2006 @12:39PM (#15270942)
    > That's the fault of lazy packagers

    Well yes, the lazy packagers at Red Hat, SuSE, on the Fedora project, etc... It doesn't help that you can do something if none of the official packages actually do it.

    Debian is the same way, though it provides a (rather hard to use) workaround of "fake" packages.

    BSD did things the right way, and Gentoo was wise to pick it up.
  • by DragonWriter ( 970822 ) on Friday May 05, 2006 @12:49PM (#15271052)
    From the Debian FAQ entries, it doesn't need to be open-sourced, but it does need a license which doesn't prevent it from being bundled with other software that replaces any function of JVM, which allows it to be distributed other than for the sole purpose of running an application or applet distributed with it, and doesn't require you to agree to indemnify and defend Sun from any lawsuits by the people you distribute it to, before it can be bundled. The GPL isn't an issue. Sun's license is the issue.
  • by cecom ( 698048 ) on Friday May 05, 2006 @12:49PM (#15271060) Journal
    Sorry, but this is ridiculous.

    apt-get install java-package
    fakeroot make-jpkg jdk-1_5_0_06-linux-i586.bin
    sudo dpkg -i sun-j2sdk1.5_1.5.0+06_i386.deb

    If this took you a whole hour, you are in BIG trouble my friend :-)
  • by nissu ( 823183 ) on Friday May 05, 2006 @06:30PM (#15273950)
    Not sure how they did it but the installer said something along the lines of "Sun JRE not detected" and offered to install it for me, wouldn't let me continue if I did not. Don't reall exactly which JVM I was trying to use at the time, perhaps it was LaTTE?
    From LaTTe homepage: [snu.ac.kr]
    • No AWT or Swing
    • Not Java 2 (only supports 1.1).
    • No bytecode verifier.
    • Lacks JNI support.
    • Incomplete class library.
    • No support for JAR or compressed ZIP archives.

    No wonder the installer refused to continue. In fact, it's a small miracle that LaTTe (a result of a research project, apparently) was able to start it in the first place, as it seems to implement only a small subset of Java 1.1 features rendering it totally unusable for running anything real - even when Java 1.1 was the latest release. Java 1.2 was released eight years ago.

    I've never quite understood why people seem to think that open sourcing Java would magically solve all the problems. For example, memory usage and relatively slow GUI performance seem to be one of the major gripes. Does someone really think that a bunch of open source coders who have never seen the sources before would be able to improve it in any reasonable time if the engineers at Sun cannot?

    And how many (smart) OS coders would actually care?

    However, fixing the relatively small bugs and annoyances in the standard Java libraries is certainly something that could be done by the 'community', as Sun seems to be notoriously slow in fixing some of the bugs..

  • by eddeye ( 85134 ) on Friday May 05, 2006 @07:51PM (#15274390)
    which can be a problem for some Linux users (such as CS students like myself)
    As a CS student you should be able to get the sun JRE/JDK going on your linux box. (I speak as a former CS student who just did it... (again)...)

    As a former CS student *and* instructor, take my advice: run away from Java as fast as you can. I'm not saying it's a bad langage/environment or doesn't serve some audiences very well. But Java's like cigarettes, starting on them too early stunts your growth.

    CS students need to learn as many different programming approaches and concepts as they can. Procedural languages (C et al), iterative (generators, Python/Ruby), functional (lisp), declarative (prolog), message passing, object oriented, generic programming, closures, static vs dynamic typing, etc. Breadth of exposure to different approaches is crucial to knowing what approach to take with real-world problems. This should be coupled with a depth of understanding of what the system does 'under the covers' at each level. It makes all the difference in the world when facing unexpected problems and differentiates a code monkey from an engineer.

    Unfortunately Java covers only a couple of these areas and none of them particularly well. Standardizing classes on Java is one of the worst things a CS dept can do. If you're stuck in this boat, all I can suggest is play around with other languages every chance you get.

2.4 statute miles of surgical tubing at Yale U. = 1 I.V.League

Working...