On Tue, Jan 13, 2015 at 11:17:20AM -0700, Michael Petch wrote: > The downside is that we add some more dependencies to GNUbg. We'll
If you want https support without rolling your own crypto, there's no way around another dependency. Even if that dependency is normally supplied with the OS. And as long as this support is optional, there's really no issue. > require libcurl(and anything it depends on) if a user wants Random.org > support . We'd have to check for libcurl (and that it support SSL) > during the ./configure process. > There are some potential licensing issues with libcurl. It primarily has > to do with releasing binaries that use OpenSSL for TLS on the back end > when linked with GPL code. There is one possible solution. Use GNUtls as > a back end. Unfortunately it may be (and I have to look into it) the > Windows (MingW builds) and/or OS/X may be using OpenSSL. Whether they > can be easily changed I can't say. Projects like 'wget' have been using > a special exemption to deal with this in their license: It's really only OpenSSL that has this issue IIRC. libcurl supports many SSL libraries, including quite a few under GPL/BSD licenses. This gives you several options to remain GPL-compliant using libcurl on multiple platforms. An end user compiling his own gnubg doesn't even need to concern himself with the license of the SSL library (as long as he doesn't redistribute the code) while packagers can choose one of a number of SSL back-ends compatible with distribution. There's more on this topic at http://curl.haxx.se/legal/licmix.html >>> Dan _______________________________________________ Bug-gnubg mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-gnubg
