One easy(?) option may be to use the python rdoclient module: https://pypi.python.org/pypi?:action=display&name=rdoclient
Jon On 14 January 2015 at 02:51, Russ Allbery <ea...@eyrie.org> wrote: > Michael Petch <mpe...@gnubg.org> writes: > > > This isn't my view. Hypothetically assume we use OpenSSL on the back end > > of libcurl. Since our project is GPL'ed and we are linking with libcurl > > we are also linking against openssl (to support that backend). The end > > result of building binaries of our project is that it is going to link > > directly or indirectly with OpenSSL and I believe that it would still > > require our product to contain an exception to allow for this (or > > alternatively use something on the backend with a license that is > > compatible). > > That's Debian's position as well, so we always link GPL-covered packages > against the GnuTLS build of libcurl in the Debian archives. > > 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. > > -- > Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> > > _______________________________________________ > Bug-gnubg mailing list > Bug-gnubg@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-gnubg >
_______________________________________________ Bug-gnubg mailing list Bug-gnubg@gnu.org https://lists.gnu.org/mailman/listinfo/bug-gnubg
