[FoRK] Fwd: [Processing] download the new beta release!

Luis Villa luis.villa at gmail.com
Thu May 19 20:51:06 PDT 2005


On 5/19/05, Michael Silk <michaelslists at gmail.com> wrote:
> Hang on though. Java's code _is_ "open" (you can view it), you just
> can't re-distribute it. I actually _like_ this system. It makes it
> easier for me to distribute my java code around - don't have to worry
> about hundreds of JRE's and different-behaving API's.

Nor do you have to worry about hundreds of different libcs, or
hundreds of different openoffice file formats, or hundreds of
different bashes. The notion that open source == rampant incompatible
forking is mostly FUD- I'm not going to say it doesn't happen, but it
typically happens when:

* upstream is unresponsive to patches/improvements (which may or may
not be the case for Sun; their track record on openoffice is abysmally
poor, but even in that case (where no one except Sun distributes stock
openoffice, because it sucks so much) file format compatibility is
still maintained.)(Note that this is /currently/ the case for
Sun+Java, which is why Linux programmers have to worry about Jikes,
gcj, and other implementations that may or may not be compatible. If
Sun freed Java, those would all quickly go away and cease to be a
problem.)

* the language or libraries are designed in such a way that proper
versioning is difficult/impossible- c++ ABI compatibility in GCC is an
important historical example of this biting free software in this
case. As far as I know, Java is fairly sanely designed in this sense,
though I've heard a few horror stories between official JVM
micro-versions.

* upstream is actively hostile towards stability. this is the case
with the linux kernel, but isn't likely to be a problem for Sun.

FWIW-
Luis


> > Let me put it another way- if Sun's Java strategy was actually free
> > software/open source friendly, they could very, very easily open
> > Java's code- it would be the best way to reduce fragmentation and
> > increase code quality (which are always their claimed excuses for not
> > opening it) because it would focus all energy on one implementation,
> > instead of the 3-4 that are now floating around. That they don't open
> > the code- *the best path towards their claimed goals*-  indicates to
> > me and many others that their rhetoric and their actual strategy don't
> > match, and that mismatch inspires a distrust that no amount of claims
> > about what they would or wouldn't do to free java implementations can
> > match.


More information about the FoRK mailing list