On 01/20/2005 05:24 PM, [EMAIL PROTECTED] wrote: > Avoid gnuplot if you can, the license is GPL-incompatible and not one we > should encourage (See bug #100612 for why).
(Checks gnuplot license and #100612) Argh, that will teach me not to assume something with GNU in its name is GPLed. Do you have any suggestions for other function graphing programs / libraries I could suggest to upstream? Ideally they would be able to display functions of 2 or even 3 arguments. In any case I guess if he uses gnuplot only via calls to fork()/exec() or whatever, that is permitted, right? Maybe the best we can hope for is that Root gets a GPL-compatible license. > I use NTL, but given it is a static-only C++ library I never felt the > need to package it. (Also it is heavily tuned at build-time, so a > generic build is likely to be slower than a tuned build, and I tend to > massage it a bit, so I need to recompile it anyway). I don't have a need for NTL aside from its use as a build-dependency of gTybalt, so you are probably a better candidate to package it than I :-) I guess a similar compromise could be made with NTL as with the ATLAS packages - compile "generic" code for most arches, and specialized code on a few subarches of powerpc and i386? Hmm, if it's a static-only library, that doesn't help gTybalt any unless it also is packaged in generic and optimized versions. Thoughts? regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/ Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
