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.

I never understood how it's good for Sun to prohibit the redistrobution of Java with BSD or Linux.
It seems to me that any benefits there might be would be lost because they are opening themselves up to having an open source, or at least more easily re-distributable JVM become the most common, and therefore standard, VM.
Besides, if they are giving it away for free anway, what benefit is there to forcing anyone who wants it to get it from Sun?

One of the last standing feature points for Solaris has over most other OS's is first tier support by Sun's JRE's -- it is Sun's best interest to confuse and cripple any efforts to make ports of the VM that make good use of the host operating system's strengths, to protect what is becoming the last good reason to use Solaris in the datacenter.

Sun's SCSL was originally a poorly considered defense against a licensee trying to pull the same embrace, pervert and promote strategy that Microsoft employed with th

Apple distributes their own, with features that have only now made it into the Sun JVM for other OSes (shared memory, etc). It is most definately first tier, and has been done with Sun's full support.

The FreeBSD issue was a licensing mistake, and is now cleared up. It shows the weakness of non-free Java for the community, but it is not evidence of a vast conspiracy to make Java slow. Could you provide such evidence for your argument?

The FreeBSD issue was a licensing mistake... that with Sun's current licensing scheme, you are at the mercy of their mistakes, because the license is revokable (in other words, because Java is not Free Software).

IRT Apple, Sun did not Give support, they Sold support:-) because OSX is Not Free Software either.

That is an excellent point (which I think I also made), but not the one I was refuting. The parent claimed Sun was doing all this to keep Solaris the best Java platform. I simply think that idea had no merit.

One of the last standing feature points for Solaris has over most other OS's is first tier support by Sun's JRE's

Which is kind of funny considering the Solaris JRE is pretty much widely considered to be the worst version available. As anyone who has had the "pleasure" of working with said version will know, it has had a whole slew of issues and is to this day not on par with the Linux or Windows versions.

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

No, the FreeBSD Foundation actually paid the cash to get FreeBSD certified for Java. This means the jdk/jre package has to pass a series of tests. Then, and only then, you can distribute java and have your OS approved. The problem is that Sun has changed the licensing for Java5 and a new agreement hasn't yet been reached.

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 doesn't matter whether FreeBSD calls it "Java", "Mocha", or anything else: Sun has revoked the license to the code and the technology itself; FreeBSD can't ship it under any name.

Java is and remains a proprietary system. Running Java on FreeBSD or Linux is a risky proposition: Sun can revoke your right

Wrong... once a piece of IP is licensed to an individual under certain terms, said license cannot be revoked later.

Case in point, if I develop software under the GPL, and then decide to move to a proprietary model after I have a substantive userbase, then it would be 100% legally correct for my annoyed users to fork the last GPL version and start their own (e.g. OpenMOSIX, OpenGFS, OpenSSH, etc.)

Whilst the FreeBSD Foundation's rights to distribute the software can, in fact, be revoked at any point, Sun ca

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.

Uhm... I kinda think the big endian/little endian thing is due to CPU's used..NET is primarily designed for x86 CPU's which are little endian and Java is designed to be platform agnostic, meaning using the most common (as in models, nog numbers) format for CPU's; big endian.

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.

This is similar to what MSFT is doing with.NET. It is specified as little endian for the exact same reason.

What does Microsoft have to gain strategically from Little Endian? Practically that's where it's code runs but Microsoft isn't beholdant to Intel.

Actually, Microsoft's newest platforms are the PowerPC which is going into the XBOX. Microsoft would like to have its own platform with XBox3, so it will actually be at a loss with little-endian.NET at that point.

In the beginning, it simply was a "write once, run anywhere" for the desktop market. Nothing wrong there. Once it ended up on the server side, it was quite effective at eating up Sun's market share, however, as it brought good performance, scalability, stability to the PC market.

Actually I'm glad that Sun restricts JDK/JRE distributions. It allows other (and better!) languages to flourish in Linux/BSD environments. Perl, Python, Ruby... I'd hate to hack Java OSS (but I fear in the future we will be seeing more and more C# OSS).

Microsoft doesn't have any control over Mono: Mono combines the ECMA core (which is clearly free and unencumbered) with standard FOSS libraries like Gnome and Gtk+.

So: using Java is not safe from a legal perspective because Sun owns Java, both the major implementations and the platform itself. On the other hand, using Mono is safe from a legal perspective (at least no less safe than any other free platform) because Microsoft clearly doesn't own it.

Right now the documentation is very poor and tools are rudimentary, but it seems to bring a lot of the benefits of scripting languages like Python or Ruby the the Java VM. The ability to use the Java libraries is huge; even huger is the ability to compile to class files, which allows you to use it every place you can use java. By that I'm not talking just about operating systems but things application servers and database triggers.

The big problem is getting to work on a browser. That the main reason that I don't surf the web in FreeBSD -- getting a Java plugin to work is less fun than going over to the dentist. And I hate the dentist.

A little late, but today I was writing some shell-scripty type stuff in Perl, and I realized I could represent 4 lines with 1 complex string of gibberish. Then I realized I should learn something like Py or Ruby before it's too late.

I find Java to be way too restricting. But then again, I'm a script monkey.

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!

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 wou

Sure, if one wants to invent new syntax and grammar. But let's get back to the original idea of doing the least typing to get the most work done, and of someone who's maybe done LISP in last decade or two wanting to try something fun and interesting. Also, have to add that there are a few projects like RIPPER out there that directly manipulate (some even replace) the Ruby parser if you really must invent a new grammar or syntax, and of course the fun lexer/parser libraries like RACC for new languages.

Your macro is the core of a LISP computer, essentially. in my example, body would not HAVE to be a string, it could be ANYTHING that responds to the message "eval". Now by default, yes eval takes a string which contains ruby code. But I can override that to be, say, a LISP interpreter. And "body" could be a string, or a file, or anything else I wanted. Just as condition would likely be a flag that I set to false when I'm done doing evals & changing body. So what I really showed was a possible core

and I should have added that by all means "body" could be a list, perhaps implementated by array that could contain strings, numbers, and booleans...just as long as I made sure it would respond to the method eval by doing something like say invoking a LISP interpreter and modifying itself accordingly, and changing "condition"

the looping constructs aren't really built in, they're the result of a method being able to receive a block of code, and the ability to execute that code with closure & with arguments from within the method. In Ruby I can put code (with closure) into proc object and call later

no, COBOL is. It runs on even more platforms than java (a 30+ year old computer isn't going to run java) COBOL has objects, platform independence if you want it & code that way, GUI libraries for any gui there ever was, web libraries, networking libraries for any network there ever was, SQL and nonSQL DBMS libraries, bidirectional C API that can deal with any other langauge, compiles to assembler or machine code....heck, let's just make sure I also mention that unlike Java it's also one of the most

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]

The licence FreeBSD had extended to JDK 1.3.x binary distribution only. If you wanted a higher version, you had to do what apparently OpenBSD users have to: download the sources manually and put them in/usr/ports/distfiles/ .

On OpenBSD the port tells you where to download the relevant files as part of installation : Java 1.4_2 Makefile

Sun won't let you download the JRE/JDK source unless you agree to their license terms. If you do agree to those terms, you become ineligible for participating in many open source projects because the conditions "contaminate" you. BSD seems to be a really brilliant way for Sun to infect a lot of FOSS programmers with their viral license. And unlike the GPL, which can be said to infect software

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.NET framework has a free implementation [mono-project.com]. The Java platform has a free implementation in the combination of GCJ [gnu.org], Kaffe [kaffe.org], and GNU Classpath [gnu.org]. Which is more complete in practice?

Someone modded you as "+1 Funny":) On the more serious note, Microsoft does not claim.NET to be Open Source Run Everywhere(TM) like Sun. They do have some patents that are troublesome for the Mono project. Appart from the patents issue, Mono is GPL and thus less risky. I don't use Mono myself, though.

Unlike Sun, Microsoft isn't pretending that.NET or their.NET implementation is "open" or "free". Unlike Sun, Microsoft isn't asking open source developers to contribute or getting free labor out of anti-Microsoft nerds as part of a so-called "community process".

If you want to use a free and open source system that's like Java or.NET, just use Mono with the Gnome bindings: it's high quality, it's fast, it's easy to learn if you already know Gnome/Gtk+, and you will no

I've seen your immature post here on/. now and then. You are representing that company, perhaps started it? In case you are part of that company, it's clear that your posts is only doing damage to it. Perhaps that's your point?

What it is: Sun licenses the JVM to the FreeBSD community under the SCSL. Sun unilaterally has the right to revoke it. Sun DID revoke it, albeit in preparation to negotiate terms for new community license. Guys at FreeBSD do not know who to ask right now. E-mails from non-revenue-generating FreeBSD got unanswered.

What it really is: RMS is right. Anyone deploying Java apps under FreeBSD for a reason or another is now a hostage in this situation. Why? Because Sun *can* (and, depending on shareholders $$$ desire, *will*) pull the plug at any time. Why? Because the JVM and standard classes are NOT FREE SOFTWARE. Free Software is about freedom, not about price.

Oh, come on, everyone with prospects of starting their first Java projects, especially governments going the Free Software way, should DROP it and go to other platform.

Now, will you take to browsing at 1 before you post too? (RTFAing does not seem to be enough.)

Your point is valid - Sun can revoke the license unilaterally. However, when you shot off this post you already had a couple of factual errors: Sun revoked it by mistake, the guys at FreeBSD knew who to ask, and their emails did get answered.

In short, for not having done your research (there are not that many comments here yet, and they were fewer when you posted), you look at least a bit raving IMHO.

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.

B)It is not relevant that the revoking was by mistake. Eventually, it can be done on purpose, too. And that is the problem.Its only a problem if your an idiot and didn't read the licence that Java is distributed under. Also did you know that your 'right' to GPL software can be revoked as well if you don't follow the terms of the GPL? Is that not also a problem by your statement here?

It was relevant that Sun revoked FreeBSD's license to Java since it was a mistake. Mistakes happen.

A, B and C are irrelevent because you had to agree to it to to work with the Java *SOURCE* not the not the JRE or the SDK, used to deploy and write Java apps. The license for the JRE and SDK clearly state that if you do not abide by the licence then you no longer have the right to use it, not simply because Sun is having a fit. You do not have to agree to the SCSL to use Java or write Java applications.

You must feel like a real genius to be able to point out that Java is not FOSS, your only the millionth o

I will use whatever language I want to write software, free or otherwise, when I want to do something in Java, I will. AND you can jump off a cliff without any ropes or equipment too.What I wrote and you refused to read is: once you develop under Java, you are under Sun Microsystems' reign. I would not recommend it. There are options. Especially if you want to develop free software. You are trolling. End of transmission.

What I wrote and you refused to read is: once you develop under Java, you are under Sun Microsystems' reign.

How so? Can Sun control how I distribute my own software? Can they force me to use a specific license for my application? This thread makes me think folks are as terrified of Sun as Microsoft is of the "viral" GPL.

The scenario: an application that must be readily distributable and runnable on Solaris, GNU/Linux, Windows, OS X, and (hopefully) *BSD. The definition of "readily" is:

- build once (meaning compile once)- no installation of third-party software. In other words, the application's distribution package must have everything it needs to run- it must install correctly on all of the listed operating systems simply by running a wizard and taking the default options

I welcome a reasonable case proving I'm wrong. Claiming I'm wrong just because you happen to be good friends with half a dozen people who are Perl/Python/Ruby or C/C++ gods doesn't prove your case, though, because I'm talking about being able to find the people needed through a normal hiring process. That means geographic location, skills, quantity, etc.

Ok. My point. In my 3million people city, there are at most 10000 good developers and I'm acquainted with circa 2000 of them, having headhunted around a l

Skilled developers with 3-5 years of Python experience readily available in our Metro area. By 3-5 years experience I mean 3-5 years of serious application development, enterprise level, with Python. Not somebody who has read a couple books or a couple PDFs.

That's where your argument breaks down (as does Stallman's): its all well and good to champion doing everything only with free software, but the practical situation is quite different. The 100% as-defined-by-RMS free software means C, perl, or Python.

7. TERMINATION. This Agreement is effective until terminated.
You may terminate this Agreement at any time by destroying
all copies of Software. This Agreement will terminate
immediately without notice from Sun if you fail to comply
with any provision of this Agreement. Either party may
terminate this A

A. IRT number of available developers; I addressed this in my metro area. I suppose that if I lived and had a similar carreer in Detroit metro area, things would be similar. Obviously I was talking about people with 3 or 4 years of developing in python... and people capable of "getting into speed" when needed (p.ex., people with 4-5 years developing Java apps, that areversed in other languages too... most project teams can be composed with 30-40% of the developers in this category)

Now, as you seem not to be ethically bothered with proprietary software, then this is a moot point to discuss.

As I said, this is where your argument and Stallman's breaks down. You have to make a living wage, which means you have to have the skills that employers are looking for. The skills in demand at this point in time, in my area, are.Net (and to a lesser degree VB) and Java. It is just that simple. My family doesn't give a rat's ass about ethics if I'm not feeding them or housing them because I refu

Its only a problem if your an idiot and didn't read the licence that Java is distributed under. Also did you know that your 'right' to GPL software can be revoked as well if you don't follow the terms of the GPL? Is that not also a problem by your statement here?

Far from it, really. Sun can, more or less, at any moment revoke the license at their own discretion. This is not the case with BSD or GPL license.

People make excuses for those close to them or those things on which they depend.

Like perhaps their dearly held views that patents and copyrights are just legal scams?

So, copyright and patents are just legal scams perpetrated by the scammers, or the man, or whitey, or whatever to keep you down are they? So when the patent office opened all those years ago it was just to keep you down? Oh, sorry, I forgot about feeding your over-weaning paranoia...

As I said in another post (#11167772 [slashdot.org]), I believe every producer of what lawyers call "Intellectual Property" should be remunerated mainly by producing it and less by generating a lot of copies of it.

This is, mainly, what happens today to the real *producer*: programmers get salaries, journalists (who are the *real* writers in terms of quantity) get salaries... while Britney/Eminem gets a lot of $$$ for... well... being themselves, and Sony/EMI/*AA-affiliate gets the REAL $$$^$$$ for copying and distribut

As a shareholder of Sun I feel like I should say something. You talk about Sun, like other talk about microsoft, like is some huge control freak of a company. Sorry to say that it isn't. I am not an expert on marketing, or any of that crap. But it seems that companies like Sun, and microsoft are getting crap that just isnt there fault. Java is a good programming language. And any control that they have was given to them, by the public. We build these companies up. So we gave them teh co

Sun's Java, a programming language aimed for all platforms and operating systems, supposedly ubiquitous in any computing environment. So, let me ask, why would they, with that goal in mind, revoke *any* license for *any* operating system? They simply limit their potential users and the potential of their language as being widely adopted.

From a hacker's point of view portability is Java's raison d'être, but from Sun's point of view portability is second to profit. Sun could profit by encouraging people to deploy Java software on a variety of platforms, then pulling the rug out from under their feet by restricting Java to Solaris. Investment banks with Java on their servers would have the choice of shutting down operations for six months while they rewrote everything in C#, or meeting Sun's terms. Admittedly this would make customers f

By agreeing to Sun's source licenses, you have agreed to a lot of legal restrictions on what you can and cannot do. I hope you are aware of those restrictions and disclose them clearly when you participate in other FOSS projects. For example, you will not be able to contribute to GNU gcj or Kaffe.

Actually it's why Java should be ignored. You're just as safe using an MS product as you are a Sun product. Actually with Sun's bleek future I would say being a MS shop is significantly more secure. I love Tomcat but this is one more reason to be wary.

1/2 my companies applications run on Tomcat the other half run on IIS. They both are behind firewalls and are both very stable (you don't have to reboot for every windows update, just stop and restart the services the same way you do in Unix-based OSes).

"They both are behind firewalls and are both very stable (you don't have to reboot for every windows update, just stop and restart the services the same way you do in Unix-based OSes)."

You sure? I think one problem on most Windows O/Ses is you can't remove/overwrite a file whilst it is in use. Whereas with Unix stuff - you can. So on windows the update software has to either rename any file/executable that is currently in use, copy in the new file and then remember to delete the renamed stuff AFTER everyth

Actually it's why Java should be ignored. You're just as safe using an MS product as you are a Sun product. Actually with Sun's bleek future I would say being a MS shop is significantly more secure. I love Tomcat but this is one more reason to be wary.

I think it's interesting that in a thread about using Java on FreeBSD, you suddenly compare Sun to Microsoft, a company that has not contributed or licensed or otherwise engaged the FreeBSD community on any level.

They both are behind firewalls and are both very stable (you don't have to reboot for every windows update, just stop and restart the services the same way you do in Unix-based OSes).

Stopping and restarting a service for any OS update other than a new kernel is basically unacceptable in production.

Hell, I can even upgrade my application server to a new version in the middle of the day, when it's handling 600+ requests per second, (or update the version of libc its using, networking libraries, etc) witho