[Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL

[James Y Knight]

On Mar 9, 2011, at 6:45 PM, Sandro Tosi wrote:
> It seems introduced by the patch debian/patches/setup-modules-ssl.diff
> with description "# DP: Modules/Setup.dist: patch to build _hashlib
> and _ssl extensions statically"

Indeed you're right -- out of the box, python still builds _ssl.so as a separate module. Sorry for the misinformation -- indeed *nothing* has changed here upstream, it was just a build patch added to debian's python packaging.

[[
BTW, the actual thing causing that special behavior is not that diff, but rather is in debian/rules:
        egrep \
          "^#($$(awk '$$2 ~ /^extension$$/ {print $$1}' debian/PVER-minimal.README.Debian.in | tr '\012' '|')XX)" \
            Modules/Setup.dist \
          | sed -e 's/^#//' -e 's/-Wl,-Bdynamic//;s/-Wl,-Bstatic//' \
            >> $(buildd_shared)/Modules/Setup.local
which causes all the modules listed as "extension" in PVER-minimal.README.Debian.in to be compiled in to the python interpreter instead of built as separate ".so" files.
]]

Despite that not having changed recently, it still seems like there's a problem in upstream python, which perhaps nobody has thought much about: even if you don't use SSL, many modules indirectly import either _hashlib or _ssl, and thus your program is linked against openssl.

You can of course prevent that from happening:
  sys.modules['_ssl'] = None; sys.modules['_hashlib'] = None

Luckily, basically everything is already written to keep working if 'import ssl' fails, so that's fine. (assuming you don't want SSL support, of course).

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.

Possibly distributors like Debian should just cause _hashopenssl to never be used, and always use the fallback code, for maximal license compatibility?

On Mar 9, 2011, at 8:27 PM, Joao S. O. Bueno wrote:
> Any libraries commonly avaliable with a CPython instalation can be
> considered as "system libraries" for GPL purposes - and so
> this would fall in the "system library exception" as described by the FAQ:


The "system library" exception is often held not to apply when you are distributing your program as part of the same system as said system library. The "system library" exception would also not be applicable if it is the license of a system library itself that you're violating, e.g. if I have a BSD-licensed program which starts with "import hashlib, readline".

See also:
http://curl.haxx.se/legal/distro-dilemma.html

James