Re: GPL applications using Python (OpenSSL issue?)
2011/3/7 Ulrik Sverdrup : > Can GPLv3+ applications written in Python exist in Debian main? The > applications in question do not use an openssl exception. > > Python uses OpenSSL so the moment the application starts, it is linking > against it too: > > $ objdump -p /usr/bin/python2.6 | grep NEEDED > NEEDED libpthread.so.0 > NEEDED libdl.so.2 > NEEDED libutil.so.1 > NEEDED libssl.so.0.9.8 > NEEDED libcrypto.so.0.9.8 > NEEDED libz.so.1 > NEEDED libm.so.6 > NEEDED libc.so.6 > > In my case I am talking about a GPLv3+ package that exists in Debian -- > kupfer > > Where do I draw the line for using/linking against ssl? > > a) Using Python2.6 > b) Unintentionally introducing _ssl or ssl into the imported modules > (import any of urllib, httplib, socket etc!) > c) Unintentionally using ssl (use urllib.urlopen on URL provided by > user -- if it's https we are using openssl) > d) Intentionally using ssl (import ssl and use httplib.HTTPSConnection > and verify certificates) > > Kupfer is today at (c) in the debian archive. It exists in development > version at (d). > > Clearly (d) has provoked thought but upon investigation I see that > "import ssl" only triggers "import _ssl" which in turn is an almost > no-op because _ssl is a built-in module in Python 2.6. > > Is this easier to answer than I think it is? I don't think this is easy to resolve. It's not the developer's (mine) issue, it's not the users issue but it's the distributors issue. FYI, it was briefly discussed on Python-dev: http://mail.python.org/pipermail/python-dev/2011-March/109032.html Of course kupfer (example app) can work without ssl. But the thread finds another problem, the inavailablity of hashlib (thus md5 and sha1): http://mail.python.org/pipermail/python-dev/2011-March/109051.html > But you're also left with not being able to 'import hashlib'. While python > has fallback > code, those modules (_md5, _sha, _sha256, _sha512) aren't built if openssl > was found > at build time. So you can't just select at runtime that you didn't want to > use openssl. > Not being able to import hashlib unfortunately makes urllib2 (and a lot of > 3rd party > packages) fail to import. md5 and sha1 are used in many desktop programs, for example to locate file thumbnails. Ulrik -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTik=_+Q�dy93wuzpmsgudbdxo63dzq0xyuw...@mail.gmail.com
Re: GPL applications using Python (OpenSSL issue?)
On Mon, Mar 7, 2011 at 7:48 PM, Ulrik Sverdrup wrote: > Can GPLv3+ applications written in Python exist in Debian main? The > applications in question do not use an openssl exception. > > Python uses OpenSSL so the moment the application starts, it is linking > against it too: > > $ objdump -p /usr/bin/python2.6 | grep NEEDED > NEEDED libpthread.so.0 > NEEDED libdl.so.2 > NEEDED libutil.so.1 > NEEDED libssl.so.0.9.8 > NEEDED libcrypto.so.0.9.8 > NEEDED libz.so.1 > NEEDED libm.so.6 > NEEDED libc.so.6 > > In my case I am talking about a GPLv3+ package that exists in Debian -- > kupfer > > Where do I draw the line for using/linking against ssl? > > a) Using Python2.6 > b) Unintentionally introducing _ssl or ssl into the imported modules > (import any of urllib, httplib, socket etc!) > c) Unintentionally using ssl (use urllib.urlopen on URL provided by > user -- if it's https we are using openssl) > d) Intentionally using ssl (import ssl and use httplib.HTTPSConnection > and verify certificates) e) use something like http://fedoraproject.org/wiki/FedoraCryptoConsolidation and port python to http://fedoraproject.org/wiki/Nss_compat_ossl Bastien -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTikNs1j0DyR9KD0ra4dZ0wU2b=wsl0ctdcyqf...@mail.gmail.com
GPL applications using Python (OpenSSL issue?)
Can GPLv3+ applications written in Python exist in Debian main? The applications in question do not use an openssl exception. Python uses OpenSSL so the moment the application starts, it is linking against it too: $ objdump -p /usr/bin/python2.6 | grep NEEDED NEEDED libpthread.so.0 NEEDED libdl.so.2 NEEDED libutil.so.1 NEEDED libssl.so.0.9.8 NEEDED libcrypto.so.0.9.8 NEEDED libz.so.1 NEEDED libm.so.6 NEEDED libc.so.6 In my case I am talking about a GPLv3+ package that exists in Debian -- kupfer Where do I draw the line for using/linking against ssl? a) Using Python2.6 b) Unintentionally introducing _ssl or ssl into the imported modules (import any of urllib, httplib, socket etc!) c) Unintentionally using ssl (use urllib.urlopen on URL provided by user -- if it's https we are using openssl) d) Intentionally using ssl (import ssl and use httplib.HTTPSConnection and verify certificates) Kupfer is today at (c) in the debian archive. It exists in development version at (d). Clearly (d) has provoked thought but upon investigation I see that "import ssl" only triggers "import _ssl" which in turn is an almost no-op because _ssl is a built-in module in Python 2.6. Is this easier to answer than I think it is? Ulrik -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik0qlvls_1ugcwbzeu3skmbfxzmeuf6na8p1...@mail.gmail.com
