On Tue, Jan 13, 2015 at 01:21:56PM -0700, Michael Petch wrote: > On 2015-01-13 1:11 PM, Dan Fandrich wrote: > > 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. > > Please read what I said " It primarily has > to do with RELEASING BINARIES that use OpenSSL for TLS on the back end > when linked with GPL code"
I'm aware—binaries are what packagers release, after all. > The problem is that GNUbg does official binary builds for Windows and > OS/X. So this issue directly impacts our production of binaries. I am > well aware that the issue isn't one that concerns those who build from > source themselves. That makes your job even easier, since you you're not even dependent on which SSL libraries are available on the platforms you're targeting. > The MingW environment I use doesn't even have GnuTLS as a package. So I > happened to build Nettle (and had libgmp installed) and wouldn't you > know it the GNUtls build fails (and apparently I'm not alone with that > issue) > > So I'll have to find a back end that actually will work under MingW. It > just so happens that OpenSSL just works on Msys/Mingw which is why it > would have been convenient. CyaSSL and PolarSSL are two that seem to support MinGW, and are fairly lightweight and self-contained (read: easier to compile than OpenSSL), too. > So it is worthy to at least note that supporting Random.org will require > new dependencies and that should be communicated to the downstream > maintainers. So your view that it really is a non issue is not one I > agree with. It's definitely worth documenting. My view is only that the OpenSSL license is a non-issue when developing an app using libcurl. >>> Dan _______________________________________________ Bug-gnubg mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-gnubg
