Sun Unilaterally Revokes the FreeBSD Java License

ravenII writes "The FreeBSD foundation has announced the news of Sun terminating the SCSL OEM-like license given to FreeBSD foundation. The foundation's attempts to contact Sun to renegotiate the license have gone unanswered. Javalobby.org also carries the news." It would seem that Sun has terminated all SCSL licenses across the board in preparation for the release of Java 5, and while the renegotiation process may be a bit bumpy, it's likely that Java will continue to be ported to FreeBSD.

Story is wrong

[cperciva]

I'm not directly involved here, so I don't know all the details, but I talk to people from the FreeBSD Foundation on a regular basis. Hopefully they'll forgive me if I get some of the details wrong here.

Basically, the story can be summarized as follows:

1. Sun dropped the ball by mistake.
2. FreeBSD Foundation didn't know what was going on, and mentioned the problem in their newsletter.
3. People at Sun realized that they had dropped the ball.
4. Sun picked up the ball and put it through the goal posts (or whatever the right sports analogy is).

This whole story is really just a misunderstanding. Sun wasn't trying to be evil, they just made a mistake, and as soon as they realized that there was a problem they started doing all that they could to fix it.

The new license should be announced Real Soon Now.

A case of bad communication

[phkamp]

Justin Gibbs, The foundations founder and financial officer said yesterday that this was just a case of bad communication and that it was already resolved. Poul-Henning

Re:Ah, I understand now.

[Homology]

The SUN Java is NOT under a BSD like license! Of course, OpenBSD will never agree to the terms offered by SUN, so here you must manually fetch the relevant files from the SUN and agree to their obnoxius license. On OpenBSD the port tells you where to download the relevant files as part of installation : Java 1.4_2 Makefile [openbsd.org]

My guess is that FreeBSD has to something similar.

Re:I never understood

[Anonymous Coward]

FreeBSD is distributing it. They call it Java(tm). Anyone who uses the VM sees it called Java(tm) and knows that Java(tm) apps will run on it.

However, FreeBSD has not actually paid up to have the JVM branded as Java(tm). So Sun says, that's not branded Java, and if you keep saying it is, we will revoke your distribution license. And they did.

It's still dumb, because you can still get Java(tm) directly from Sun.

Though Java(tm) is available free, if you want to distribute it and you aren't Sun, you're going to have to pay to have a TCK (certification test) performed. That costs a lot of money that a volunteer project like FreeBSD probably isn't interested in fronting.

So no more Java(tm) for FreeBSD users, unless they go get it themselves from Sun.

Re:I never understood

[arivanov]

This means that you do not understand the meaning of java as far as Sun marketing strategy is concerned.

Java as far as Sun is concerned is a method of pushing a large number of customers onto Sun's native *sparc/Solaris platform and the associated software and support contract. The only reason for the existence of ports to other platforms is to bait people into switching.

• It is the only platform with first tier support and the only platform whose scheduler is continuously updated and optimised specifically to match the Java current threading model.
• Java is a big-endinan platform. All internal data representations must be big endian (this is in the standard) and execution on any small endian platform like x86 will always incur a performance penalty. This is similar to what MSFT is doing with .NET. It is specified as little endian for the exact same reason.
• And if performance fails to help the fledging sales (Sun is having a really bad quarter), licensing comes to the rescue.

No need to attack me...

[hummassa]

A) I was reading at -1. The "this was a mistake and we cleared it up" post had not showed up when I started posting.

B) It is not relevant that the revoking was by mistake. Eventually, it can be done on purpose, too. And that is the problem.

C) No, they did not knew exactly who to ask, and at least when the FreeBSD foundation report was done they did not receive any answer. It's irrelevant for the discussion of this piece, IMHO, that they eventually cleared up the situation. Had the climate at Sun WRT FreeBSD been different, Sun could stall this and caused a lot of damage. And they still can, at any time, because Java is not Free Software.

D) I am not raving and nor is RMS, which is whom I was referring to. Java is not Free Software. If you are considering Free Software (as a lot of governments are doing nowadays with a lot of good reasons to do so... see http://www.gnu.org.pe/resmseng.html [gnu.org.pe]) you should not consider Java as a good option for software development (unless Kaffe [or other Free JVM] + GNUClassPath is good enough for you). And this was my conclusion in the end of my post.

E) As an aftertought, disclaimer, etc: I started to post my piece as soon as I saw the blurb (when I woke up this morning) and it had only 9 posts at -1. When I finally organized those three short paragraphs, and clicked Submit, it had 20+ posts, with some (3?) of those under the "A case of bad communication by phkamp (524380) (#11273654)" post. I took good 10-15 minutes to write this answer up, because I don't troll. I believe that RMS is right and that proprietary software is a legalized scam. And I really like J2EE (technically) as a platform but I really dislike the power that Sun exerts over it and the MS-like lock-in that it represents.

--
And this is not a sig.

Re:Better alternatives to Java

[bhurt]

And if you think Sun is bad, just wait until Microsoft starts playing with you.

My recommendation: learn Ocaml.

Re:I never understood

[dtfinch]

All external data representations must be big endian. For internal data, they just go with the endianness of the machine, and endian conversion is done when serializing/unserializing data.

ARM and MIPS endianness in game consoles

[tepples]

Please remember that practically every CPU architecture besides x86 is big-endian; Mac's, 99% of UNIX (AIX/HPUX/Solaris) machines, Z/OS machines, etc.

ARM7 and ARM9 can be set to big-endian or little-endian, but they're frozen to little-endian in every Nintendo Game Boy Advance and Nintendo DS handheld video game system. The MIPS processor in Sony's PS1 and PS2 video game consoles is configured little-endian as well.

Re:Better alternatives to Java

[iggymanz]

Anything more than the really simple lamdas always seemed to need macros. the short answer to macros is they're not needed; Ruby method coding really is a type of macro building. the long answer is to spend say four hours and learn some Ruby, it's fun!

Re:Better alternatives to Java

[iggymanz]

Won't argue: LISP is great, macros in LISP are Great & Powerful. Multiple inheritance? Ruby has something better called mixin methods, all the fun and usefulness of MI without being in the position of having to weld a fish to a bicycle. Could *i* implement a new Object System with MI in Ruby? If nothing else, Ruby is so very introspective one could take a list of classes and the methods from each that were of interest, and another list of proc (code with closure of environment state) objects that would modify or use each of those methods, and spit out a funky kind of dispatching class that could make objects of that funky class. and call that my MI thang.