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/ -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
