[GNUnet-developers] Java, C, GPL, FSF, GNet, GNUnet

[Christian Grothoff]

Hi everyone.

I am sitting at indymedia.org @ seattle, really nice place, anyway, I'll have
to be brief...

History: GNet started in C and Java, C for the server, Java for the GUI.
The rationale was, that the server must have a small memory footprint,
and pretty much any usable (fast, etc.) VM out there has more like 16-64MB
footprint, and not 2-4 MB which is more reasonable for a bdeamon (stupid 
keyboard, backspace does not work).
Java was chosen for the GUI since I wanted to learn Swing, speed and space
do not matter for it, and since Swing is probably the most portable graphics
toolkit out there (or at least one of the more portable ones, please no
qt/gtk/swing/xlib/motif flamewar on this one). 
The code was always under GPL and that is fine with everybody, including
FSF, GNU and whoever else you may care about.

When we joined the GNU project, one of the conditions is, that 
you make the software only depend on free software (and there is
even now no free Java implementation with SWING support out there,
only AWT!!!). Also, GNU projects should use other GNU projects as
their primary dependencies, which says that we should *prefer* GTK
over QT. This does not mean that we can not include a Java client
or a QT client. It just means, that the reference implementation 
(or the primary development effort, etc.) should go into the GTK
GUI. While the core team can and will not force anybody to follow
this doctrine, I personally am perfectly happy with the GNU philosophy
in this point and am willing to follow it.

If you want to write a Java GUI (or a QT GUI) for GNUnet, go ahead.
If it is under GPL, there is no problem with including it in the
distribution or linking it on the webpage. Note that GNU does NOT
allow linking to non-free software (but even if you use Java/Swing
and depend on non-free software, we can link to it as long as your
software is free itself).

I would discourage an implementation of the GNUnet core (gnunetd,
transports, application service modules) in languages other
than C (except maybe if they can interface with C without a VM,
so C++ may be ok for an application service), since maintaining
two versions of the same protocol implementation will lead to
inconsistencies (think Jxta with a Java reference implementation
and various other bindings (C) trying to catch up [forever?]). Also,
moving the main development to a higher level language (Java, C#, etc.)
would be bad since we definitely do not want to pay the overhead
of a VM for a deamon. 

The performance of Java is a very minor issue, modern VMs can be
fast enough, given enough memory. But there are people who wanto
run GNUnet on a PDA or a PI or even less, and there is hardly any
other widely known (!) language out there that would give us all
of that. 

I hope this clarifies a bit how we got where we are and why we
are where we are. I

later

Christian