My replies to Daniel:

...

You see what these f--ks did? Now I don't give a shit what reasons they had, they should have gotten over it like Netscape/Mozilla did.

Which f--ks are that? Borland? I was using a lot of Borland products at the time, so I remember the release of Interbase quite clearly. It definitely had the feel of a company wishing to keep dead code alive. Interbase was a good RDBMS, but it was losing marketshare to SQL Server. IMO, the move to open source Interbase was pushed by this, and not neccesarily out of any good will to the world.

These folks :-) referred to Firebird developers. Perhaps I was insufficiently clear: the context was the risks of "forking". Firebird forked Interbase and I don't care what their reasons were. They should have worked with Borland.

...

It goes against the values I hold -- respect the company for the steps they took to open their sources and work with them for the benefit of all. If you have a problem, get some self-respect and write your own damn code from scratch.

Now you seem to be talking about the Firebird developers (where did the Netscape analogy go?) What's wrong with forking a codebase? Especially if you think that the original codebase was released by a company in trouble, as a way to wipe their hands of a dying product.

There we go, whats wrong with forking Java?  And this is what concerns Sun and java developers like me.

Don't get me wrong, I'm dead again the zillion-opensource-products-to-do-the-one-thing sort of mentality (yet another emacs with wordstar bindings and tetris.... what's the point?), but in the case where you have taken a supposedly open sourced product, and found that the group in charge of it is being slow or tedious to get patches accepted, and in fact don't even seem to *care* any more, what's the problem with forking it? It is better to fork it than lose ongoing development entirely, surely?

Java gets forked because MS feels that their patches aren't being accepted fast enough.

...

As more companies open their sources, I hope that similar sentiments to mine will enter the hacker ethic.

Your sentiment being "Always write your own code from scratch, rather than take a useful codebase and work on it"? I hope not. You're missing out on one of the most powerful aspects of open source - you can take a project and modify it and release that, legally.

That is not my sentiment. But you highlight the risks of forking again.

Maybe I should point out where a fork has been beneficial: Samba and Samba-TNG (The Next Generation). Samba TNG was forked at a time where some of the developers thought the direction the main Samba team was going was wrong. TNG was aimed at rewriting parts of the core of Samba to do things much closer to the way windows does it. Now, if Luke Leighton got "some self-respect and wrote [his] own code from scratch", TNG would never have taken off. Far too much work.

This is not the same as my example. Interbase was originally close sourced, Samba was always open and developed by the community. If a large part of the community (read people who contributed code) feel the need for a change of direction, that is fine by me (similarly, I feel fine about X.org). You see these guys working on Samba-TNG and X.org contributed greatly to the original products. Now the f__ks who quickly set up their own Interbase repository and called it Firebird did not contribute a single line of code to what was a mature product (Interbase) -- they couldn't, it had been closed. They did not have the pedigree of the likes of Leighton or Packard and friends who also forked their originals. Forking in itself is not bad, it's who forks it and why. These ethical questions can be seen as relative. Hackers will vote with their fingers. If enough agree with my sentiments, these will enter the hacker ethic. (I hope I've made myself clearer).

...

To (1): This is a problem with Debian and apt. It can't be the download (I do it on my 33K) it is the hoops that /Debian/ and /apt/ require us to jump through.

If the license says you can't redistribute it, then any distribution which prefers to maintain it's own repositories will have this problem.

I don't want to get into a discussion of what the different parties mean by "redistribute". Let's just look at it empirically: Java comes on every major Linix distribution disk apart from Debian. FreeBSD has negotiated a license with Sun that allows it to distribute Java from the FreeBSD site. NetBSD are doing something similar. Apple comes with Java. Clearly the problem is the Debian stance. Distributions can choose to be flexible. We all know of Linus's flexibility wrt to binary drivers "in" the kernel just as we know of RMS's opposite view. For Debian it is a religious question. That's fine.

Sure, you can always download it manually. And you can go and set up your environment manually to path it correctly. And you can setup binfmt so that you can just run a java app without having to know it's java. What happens when you want to put a package that depends on the jvm into your repository however? It is *really* messy having a dependancy installed from source.

Then your package sytem has a weakness with "having a dependancy installed from source". You could improve your packaging system or mandate (I'm being cheeky: substutute "ask") that all software conform with your broken packaging system.

...

To (2): Yes. Let us hope that if it happens, we get a license similar in spirit to that of freedom, that Sun is given the respect it deserves and is able to profit fairly from it.

And boy if I see the Firebird faction turning their evil green eyes thataway ...

Get over it. If Borland stopped development of Interbase after releasing it, it was because Borland didn't care enough about it. Firebird did nothing wrong, other than force Mozilla to change the name of it's browser a second time in short order.

Interbase is still being developed by Borland. I will never use or support Firebird.