Integrating Kaffe and Mozilla ?

[Robert S. Thau]

Michael Koehne writes:
 > 	The Java written browser, running under kaffe, could be a more
 > 	interesting thing for us, because its not crippled by the N$
 > 	licence. 

Two comments:

First off, writing a browser in Java is certainly an interesting
project, but I have serious doubts that transcribing the Mozilla C/C++
code into Java (these guys are actually talking about making Java
versions of the NSPR APIs!) is the most effective way to go about it.
Particularly since Netscape aren't terribly attached to the really
critical bits of that C/C++ code themselves --- the hard part of
writing a browser in Java from scratch is HTML processing and
rendering, and Netscape are throwing all of that stuff away
themselves.  (An early version of the replacement rendering engine,
named Raptor, is already on the mozilla.org site, embedded in a small
browser-like app, though it is ultimately intended to replace large
chunks of the Mozilla code proper).

Second, I'm curious as to what you regard as "crippling" about the
NPL.  The provision which has given most people pause is the one which
allows Netscape to distribute "modifications" of NPLed code in their
own commercial product.  However, you are explicitly allowed to make
"modifications" consisting of a few lines of hooks, which invoke
routines in files consisting entirely of your own code, which may be
under a licence which allows Netscape no special rights whatever.
(See NPL sec 3.7 --- Larger Works --- for the legalese, and the notes
on the definition of "Modification" from the annotated NPL, which is
in http://www.mozilla.org/NPL/annotated.html, for documentation of
intent).

So, the only practical effect of this provision is that Netscape don't
have to explicitly get permission to distribute little three-line
bugfixes to their commercial licensees.  If you're doing substantial
new work, you put it in a new source file anyway, and so long as those
files do not *themselves* contain any Mozilla code, you get to choose
the terms for their redistribution (which may even be binary-only!).
This is rather like Larry Wall's Artistic License for Perl, which is
explicitly intended as a "non-infectious" GPL allowing the Perl
interpreter to be embedded in a commercial product.

The problems with combining GPL and NPL code, btw, stem exclusively
from the GPL, which allows you to distribute GPLed source, or
derivatives thereof, as part of a Larger Work (in NPL terminology)
only if *entire* the Larger Work is GPLed.  (Wall gets around this for
Perl by allowing Perl redistribution under either the Artistic License
*or* the otherwise more restrictive GPL, at the distributor's option,
but the matter is still unsettled for the NPL).

The only part of this which I can see as potentially burdensome on
someone who wants to make a Mozilla-based product (involving a
non-trivial amount of honest new work!) is the requirement that the
Mozilla source, and all Modifications thereto, be available in source
form --- but that doesn't have to include the bulk of your code or
your work, and besides, disk space is cheap.  So, how is this
"crippling"? 

rst