Re: [Classpathx-discuss] Re: servlet code

[Per Bothner]

"Nic Ferrier" <address@hidden> writes:

> Per said:
> > I notice most of the code there is LGPL.  
> > That certainly prevents them from being part 
> > of libjava.
> 
> Errr... why? I do not believe that can be true. If it is true then I
> think, frankly, it's mad.

After much negotiation, the GCJ project, the Classpath project, and
the FSF (i.e. RMS) have agree on a GPL-plus-modification as has
long been used with libgcc (not glibc!).

The biggest problem with LGPL is that it is fundamentally incompatible
with delivery of embedded applications.  It requires that the person
receiving the code be able to relink it - which is not an option when it
is burned into ROM. (Much of the market for Cygnus-now-Red Hat
compiler tools is the embedded market.)  Another problem is that the
re-link requirement is just another complication for commercial
developers.  Thus they are likely to look elsewhere, which hurts Gcc.

On systems with shared libraries, linking in a shared library at
run-time is generally considered to satisfy the re-linking
requirement, so on such systems the LGPL is acceptable, even for
non-free applications.

But libjava cannot accept LGPL run-time code.  I would make an
exception for code that that by default is configured out (at least on
platforms without shared libraries), and that depends on other LGPL
libraries (such as gtk).

> I can't see how this could be a problem for ANY free software project
>  - but if it is - please let me know and I'll see what I can do to
> solve it.

Remember that embedded developers pay much of the bills for gcc/gcj/g++.

> Lastly, what is the servlet thing you're working on? Paperclips is
> the FSF's servlet engine... the Paperclips people would certainly be
> interested in anything you have got to offer!

What I've been experiementing with (as part of my "day job") is
compiling a pseudo-servlet to a shared library using gcj, and having
that be loaded by an Apache-2.0 module.  It works, though it is still
rather primitive.  We think this may be a higher-performance
general-purpose server that *in addition* can serve servlets fast.

A true Java-based server as its uses too, of course, for example
where a larger proportion of a server's logic is Java code.
-- 
        --Per Bothner
address@hidden   http://www.bothner.com/per/