Re: [guppi-list] Re: use of GSL in guppi

["Asger Alstrup Nielsen" <alstrup diku dk>]

> OK, I'm convinced.  I think that it is important to create a situation
> where it is in the best interests of commercial software providers to
> contribute to the free software community.  So I'll stick with LGPL.

I'm very glad you have come to this decision.  I hope I won't let you down on
it.

> So now the question is, how to do that?  The only code I'm interested
> in "borrowing" from other projects, for right now at least, are
> numerical routines for special functions and matrix operations.  This
> is really just a small part of what Goose will be, though.
> 
> Here is what I propose to do:
> 
> (1) I spent all day Sunday working on Goose, and mixed in some R code
>     for numerics.  (It is all very localized and carefully labelled.)
>     In the process, I switched everything over to GPL.  I'm going to
>     release this GPLed version as Goose 0.0.2 today, mainly because it
>     has a *lot* of improvements over the last version and I want to
>     keep up some momentum.

Yes, it does look like an improvement.  Unfortunately, my gcc 2.7.2.something
won't compile it properly so I can't test it, and hack on it.  I'm upgrading my
system to the latest Debian tomorrow, and will install egcs 1.1.  Hopefully,
that will help.  Also, I'll install the Cygnus win32 stuff to get configure
going under Microsoft Windows 95, and then test it under Microsoft Visual C++. 
This will probably be my development platform in the future, but we'll of
course keep things portable to Unix (the biggest problem should be CR/LF stuff,
but I'll work this out.)
 
> (2) I'll contact the R people and see if they will either:
>     (a) Switch their numerical stuff over to LGPL.
>     (b) Give me a special exception to redistribute stuff derived from
>         their code as LGPL.

Please let me know if you need any help in this regard.
 
> (3) If that doesn't work, we'll just have to re-implement the
>     necessary numerical routines from scratch.  Luckily, a lot of the
>     R numerics have references attached --- so at the worst case, I'll
>     have to spend some time in the library looking up the various
>     books and journal articles they got the algorithms from, and then
>     code them up myself.

In the worst case scenario, it is important that the reimplementation is done
as a reimplementation(!), but I'm sure you know that.  It is not enough just to
change a few trivial things.  Of course, some algorithms are so simple that
they can't be changed substantially anyway, and then you might just as well
leave the original implementation and change the license.  Nobody will be able
to drag you in court for that.
 
> (4) Repeat steps (2) and (3) with the GSL people.  Goose doesn't use
>     any of GSL yet, since I found their special functions library to
>     be a bit short on statistical stuff.  But once we get our own
>     versions of the necessary functions, we can (and should)
>     contribute them to the GSL project.  Then, if GSL goes LGPL, we
>     can just use them from there.

I would be very glad if GSL turned LGPL.  Also, it might be a little
troublesome for me to convert the stuff I contribute to GPL for inclusion in
GSL.  Of course, GSL can be mixed GPL and LGPL if this turns out to be the
case, so this should not hold us back.
While we are at it, you can do this for Goose now:  The code that you have done
can be LGPL as it used to, and the other stuff can be GPL until things resolve.
This way, people would be able to take out the GPL stuff and get a clean LGPL
library without waiting for a license settlement/rewrite.  The danger is that
the process drags out (maybe because the R people are slow), more people
contribute code to Goose under the GPL, and suddenly we are in a situation
where the licensing is very hard to change.  I'd like to prevent that.
 
> (5) Once the dust settles, I'll produce a non-GPL-tainted, LGPLed
>     Goose 0.0.3 that will perfectly match 0.0.2 in functionality, but
>     with all GPLed internals replaced by LGPLed code.

Sounds like a good plan overall.  Once again, thanks for considering my point
of view.

--

Enough of this boring license stuff for now.  Let's talk about Goose.

Do you have any ideas for what you would especially like be to
implemented/improved in Goose now by somebody like me?  Before I and my
statistical co-worker start on the non-parametric statistics stuff, we still
have to make some design decisions for our own program, and in the meantime (it
could be a few weeks, since this depends on other people as well), it would be
a good idea for us to hack on Goose to get to know to code better, and maybe
get the chance to change it a bit to meet our needs a little better.  I have
had a look at it, and I think I would like to change some data structures in a
few ways that shouldn't impact performance. How fixed do you consider these?

A really important thing is to add exception handling to everything to improve
error
handling (which, as you say, is practically non-existant at this point in
time.)  I think this has high priority in order to shape all new code:  It
should do error handling once the dust of introduction has settled.

One other thing that is important is the addition of a "remove item" in the
DataSet class.  On the surface, it should be pretty similar to add, just the
other way around.  If this is added, the DataSet class is a fully dynamic class
that allows interactive editing.

Another thing that would be useful for us, would be to able to sort
corresponding to a DataSet.  The idea is to let one DataSet be the sorting key,
and have many other DataSets depend on this. Each of these DataSets would
implicitly be ordered the same, and when the key DataSet is sorted, the other
datasets are shuffled around similarly in order to keep them synchronized. 
I.e. to simulate a vector-DataSet.

I'm ready to have a look at these things (and others) according to your
comments.

Greets,

Asger Alstrup