Sun to Change Java License for Linux

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.'"

Comments

Re:Finally!

[moro_666]

the exploding one ?

Hard..

[ZoWnX]

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..

[CastrTroy]

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.

Re:Hard..

[Reverend528]

Screw Joe User! Bob Sysadmin is lazy too!

days of downloading Java

[JoelMeow]

days of downloading Java

That's what you get for having a slow connection.

Re: days of downloading Java

[Arandir]

I don't care how speedy your connection is, you can only click so fast on all those Sun license agreements.

Re:slackware has jre in 10.2?

[Ash-Fox]

Mandriva Linux includes Sun's JRE5 too.

We already have open source Java

[CustomDesigned]

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.

Re:We already have open source Java

[Tim C]

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.

Sun's commitement?

[SWroclawski]

I remember hearing about two or three weeks ago that Sun said it was committed to "Open Sourcing all of its software, everything they make."- this is from LugRadio and a Sun representative.

Given this /very/ progressive stance, I don't see why they're stalling when it comes to Java.

If anything, this slows Java adoption.

Java was all the rage in the late 90s. Had they made it Free, I think it would have been a tour de force. Now we see competition from simpler technologies. We're learning that we don't need a J2EE infrastructure when a simple Model-View-Controller model with a database backend will do the job just as well, and so on.

Freeing Java would spread adoption, if nothing else than by including it in every distribution shortly thereafter.

This new license system isn't good enough, it'll just frustrate people.

Re:Sun's commitement?

[fossa]

(Luke Skywalker stands hands bound on the edge of a plank)

"Java! This is your last chance. Free yourself, or die."

(laughter ...but Java the Hutt will soon learn he's too sluggish as he is choked to death by Princess Ruby)

Re:slackware has jre in 10.2?

[moro_666]

i think debian/ubuntu keep away from it because it has an uncomfortable license that doesn't match with the rest of the system ;)

most debian/gnulinux software is either gpl/lgpl or bsd (or alike) licensed, can be distributed without any restrictions just about anywhere. the license of java which you are supposed to read and accept while downloading and installnig, differs a lot from the "free as in beer" or "even more free than beer" licenses mentioned above.

for the commercial distros - no idea, but possibly the same issue.

Limits?

[J.Y.Kelly]

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...

Java as electricity

[aphaenogaster]

Odd analogy, but I guess it kind of makes a little sense maybe... http://www.forbes.com/2006/05/04/sun-microsystems- schwartz-cz_ec_0504schwartz.html?partner=yahootix In shwartz's words...

Forbes:

You're trying to woo customers with free hardware. How do you make them paying customers? You haven't monetized Java proportional to what's out there.
JShwartz:

That's a misnomer. Largely an American misnomer. Nearing 1 billion Java handsets.

Forbes:

So what's your Java revenue?

JS:

Close to $13 billion.

F:

That's not money in Sun's pocket, though.

JS:

It's like asking a company that produces generators how much of their demand comes from people using electricity. It's 100 percent.

F:

But it's about how many customers are paying you for the privilege of using Java.

S:

And I'll point out that a billion handsets fuels an enormous market in the telecommunications industry. Java running on Sun's Java Enterprise system, whether it's at American Express or General Electric or Vodafone, is fueling Sun's overall revenue. Asking us how much money we make on Java is like asking Verizon Communications how much money they make on handsets. The fact is that they lose a fortune on handsets, but they make a fortune in subscribers.

F:

So are you going to convert Java users to subscription service for Sun?

S:

Partially, we're already doing that. American Express runs on the Java Enterprise system. That's per employee subscription for core middleware for Sun. My broader point is that Java ensures Sun has access to an open market. Java allows us to reach out to customers who don't run on Sun hardware and ensure we can serve them wherever they may be--whether it's on a Dell box or HP box or in an IBM customer base.

Again, it's hard to explain to people. Here's an analogy. With the advent of electricity, Thomas Edison tried to patent a lightbulb so that you would have to use his lightbulbs if you used his dynamo. That strategy obviously failed. And what emerged was the standard plug. Asking Sun the value of Java is like asking GE--which is, I think, the largest manufacturer of power turbines in the world--what the value of the standard plug is. It ensures they can serve a global marketplace. So if you asked them what's the value of the plug, how would they respond?

Here are some stats on Java: There are more than 1 billion Java cards in the marketplace, securing everything from set-top boxes to handsets. There are more than a billion Java handsets, all driving demand for network infrastructure. There are nearly 1,000 members of the Java community process, who collectively contribute to the standard called "Java." It is the default standard for set-top boxes in Brazil. So what will the infrastructure opportunity be in Brazil to serve 100 million Java-enabled set-top boxes? I promise you it will be enormous, and Sun will be among many participants that can serve that demand.

Programs, getcha programs here!

[Chris Pimlott]

Section 5.3 of the Debian Java FAQ sums up the present licensing issues that prevent Debian from including Sun Java.

I wish Java was more like CPAN

[johnnnyboy]

The more I hear calls that Java to be more open source the more I wish all these Java libraries worked like the way CPAN does.

CPAN is great and its what keeps Perl relevant and it works well for the Perl community. All these java libraries bundled with the JDK should be more modular with a lean core distro and then the rest can be organized and installed as modules.

And like everything CPAN all these modules will be peer reviewed by other Java developers in the open source and corporate worlds.

Ah, one can only dream.

64-bit?

[escay]

well they could start with providing the mozilla-firefox java plugin for amd64 systems on linux...libjavaplugin.so, anyone?

Re:Well I do declare! (as grandma said)

[davecb]

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

Re:slackware has jre in 10.2?

[zerblat]

The Binary Code License Agreement, under which Sun's Java implementations are licensed, only allow you to distribute their software if "[...]you do not distribute additional software intended to replace any component(s) of the Software[...]".

That means that you can't also distribute e.g. gcj or GNU Classpath. The license isn't exactly clear on whether it means that you can't distribute Sun's JRE together with gcj or whether distributing Sun's software means you can't distribute gcj at all -- ever. It's also not clear exactly what they mean by "software intended to replace any component(s) of the Software". In the worst case, that could apply to any software that performs the same function as some part of the JVM, the byte compiler, the class library etc. Does distributing Swing mean you can't distribute GTK?

Re:I'd Be Happy

[LarsWestergren]

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.

These two are finally fixed in Mustang. I agree it has taken long though:

    Three new methods have been added to java.io.File class:

          getFreeSpace()
          getUsableSpace()
          getTotalSpace()
[...]

  Changing File Attributes:

  In Mustang the java.io.File API provides access to the file attributes for changing its readability, ability to write and ability to make it executable. Check out the following methods for playing around with file attributes:

  Changing readability: owner-only, owner or everybody
  Making it writable or read-only: owner-only, owner or everybody
  Making it executable or not executable: owner-only, owner or everybody