[OPEN-ILS-DEV] SHA1 code in sha.c

[Mike Rylander]

On Wed, Dec 23, 2009 at 10:23 AM, Scott McKellar <mck9 at swbell.net> wrote:
> --- On Wed, 12/23/09, Jeff Godin <jeff at tcnet.org> 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.
>

I was one pushing for OpenSSL linking, but after reading some of those
links, I totally agree.  I'd still prefer linking to an external
library -- gnutls sounds promising -- but OpenSSL has licensed itself
pretty much out of the running for now.

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com