--- On Wed, 12/23/09, Jeff Godin <[email protected]> wrote: > > > > I expect to go shopping for an implementation of SHA1 > that works for > > any architecture, regardless of int size or > endianness. Naturally its > > licensing must be compatible with the GPL. > > OpenSSL has been suggested, but has licensing issues > (advertising > clause, considered GPL-incompatible without adding an > exemption, etc). > > mhash is LGPL'd and has support for (among others) SHA1 and > MD5: > http://mhash.sourceforge.net/ > > There are packages for Debian (confirmed etch, lenny) and > Ubuntu > (confirmed starting with Hardy). > > There are probably other options, this is just another > suggestion. > > -jeff
This note is a summary of some IRC discussion on #evergreen (and inevitably reflects my own biases). The OpenSSL license requires projects that use its libraries to include an acknowledgment that the project uses OpenSSL. On the other hand if you publish under the GPL you can't require downstream recipients to include such an acknowledgment. There is a narrow exception. If the targetted platform normally has OpenSSL installed anyway, we can link to its libraries without violating the GPL. We may need to include an explicit exception for OpenSSL in the license notice. With mhash we would have the option of including the mhash code in our own distribution, the way we currently include other people's code for SHA1 and MD5. That's apparently not an option for OpenSSL due to the licensing issues. Of course it would probably be better to rely on a package having been installed as a prerequisite. The legal issues appear to be very murky and confusing, and I probably haven't explained it completely correctly. Useful links provided by jeff: http://www.openssl.org/support/faq.html#LEGAL2 http://www.gnome.org/~markmc/openssl-and-the-gpl.html ...and by phasefx_: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501145 ...and by dbs: http://www.h5l.org/manual/HEAD/hcrypto/group__hcrypto__evp.html From dbs (quoted because I don't understand it well enough to paraphrase): "IIRC, packages with sophisticated autotools setups can default to linking against gnutls but fall back to libopenssl same with readline vs libedit and other GPL-compatible vs. GPL-incompatible libraries" ...and a related link cited as an example: http://svn.php.net/viewvc/php/php-src/trunk/ext/readline/config.m4?revision=292081&view=markup ------------- IMHO we should regard OpenSSL as a last resort, regardless of its technical merits, because of the licensing issues. First we should look for a library that's GPL-friendly, available as packages for the major targeted platforms, and satisfies the technical requirements. Failing that, we may go with OpenSSL, but we'll be tiptoing through a legal minefield. Scott McKellar
