TLS libraries and licenses

[Jerry James]

For one package for which I am part of upstream, we are talking about
adding TLS support.  The upstream project is GPLv3+.  We're looking at
the preferred list of crypto implementations on
http://fedoraproject.org/wiki/FedoraCryptoConsolidation and have a
couple of questions.

The most preferred option is NSS, which is MPLv2.0.  The license list
at https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses
says that MPLv2.0 is "sometimes" compatible with GPLv3.  If I'm
reading the MPLv2.0 page correctly, then compatibility is strictly a
function of the MPL-licensed package.  In that case, wouldn't it make
sense for us to have two license tags for our RPMs:
MPLv2.0-GPL-compatible and MPLv2.0-GPL-incompatible?  (Not necessarily
with those names, of course.)  As it is, anyone in our situation has
to independently evaluate the MPLv2.0 package to figure out whether it
is GPL compatible or not.  (The NSS source code fortunately contains a
note on GPL compatibility.)

The second option is gnutls, which is various flavors of GPL and LGPL,
and so is fine for us.  We did have one developer wonder why gnutls is
preferred over openssl, though.  Can anyone answer that question?

The third option is OpenSSL, whose license is GPL-incompatible, and so
not an option for us.

The fourth option is libgcrypt, which is LGPLv2+, and so is fine for
us in terms of license (haven't looked at available functionality
yet).

Our plan, then, is to add an abstraction layer to hide the
implementing library, and prepare implementations for nss, gnutls, and
libgcrypt if it isn't too much work.  Does this seem reasonable?
-- 
Jerry James
http://www.jamezone.org/