On 2015-01-13 7:51 PM, Russ Allbery wrote: > That's Debian's position as well, so we always link GPL-covered packages > against the GnuTLS build of libcurl in the Debian archives. >
I discovered that Debian has a notice about the licensing issues regarding OpenSSL: https://lintian.debian.org/tags/possible-gpl-code-linked-with-openssl.html I'd be curious if the checks pick up on GPL code that relies on a library that in turns relies on OpenSSL. I happened to ask this question on a private FSF mailing list and the consensus is that linking directly or indirectly to OpenSSL would be a licensing issue if you are distributing binaries. That appears to be in line with Debian's view as well. > This is all reasonably straightforward for the Linux distributions (and as > the Debian packager, libcurl is certainly fine with me). It's the Mac and > Windows binaries that will be the tricky part from a licensing standpoint. > I don't really have any further suggestions to offer other than what you > already spelled out (I know almost nothing about developing on Windows or > Mac OS X), but I concur with your analysis. > Well as of now I have libcurl/gnutls working here on Windows. So I am satisfied I can put away the libcurl based code to support Random.org. I'll send you a notice when the first release arrives where this dependency is required for that support. As for OS/X you can build a variant with Macports that relies on GNUTLS rather than OpenSSL. I haven't tested it, but I'll lay odds it works. But I won't know until I get around to doing the next Mac builds. -- Michael Petch GNU Backgammon Maintainer / Developer OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304 _______________________________________________ Bug-gnubg mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-gnubg
