> Do you think that if OpenSSL provided its own implementation of strlen(), every text that mentions strlen() needs to acknowledge OpenSSL? Do you realize how ridiculous that is?

If that text is deemed to be advertising by Eric Young and a court of law, then absolutely yes. The license is short, clear, and does not make any exceptions for features that you might deem to be commonplace.

http://www.openssl.org/source/license.html

I also agree that this is ridiculous, but believing something is ridiculous does not make it any less real as Barnes and Nobles learned the hard way by using Amazon's one-click patent.

> The important thing to realize is that libtomcrypt is
intentionally written in very portable C.  That is great but it leaves a lot on the table. Optimizations for various platforms to take advantage of enhanced instruction sets such as SSE2 and explicit hardware crypto acceleration instructions such as [...] are not likely to be part of libtomcrypt, 

A quick glance at libtomcrypt tells me otherwise. It is portable C, but it still has inline assembler. It has optimizations using SSE2, x86, x86_64, and PPC32. Even though it might not have that new Intel AES instruction yet, this is the same argument people had for using GMP for python's integers.

If there is a problem with multiple libraries, I'd like to reiterate my support for migrating to NSS.