Hi zack, I don't believe a licence change like this is a good move and I think there are downsides to doing so.
I'm unconvinced there is a problem to begin with and relicensing like this states that there is a problem. In some way that then sets a precedent in the same way an undisputed post to debian-legal is later used to set a precedent. (I know that's not how Debian is supposed to work, but with licensing matters, that is the de facto procedure.) Rather than rushing to relicense, I would rather ask the people whose opinion really matters on questions of licence compatibility: ftp-masters. We should ask whether they think there is a licence compatibility problem here. A month or so ago I informally asked one of the ftp-* team about this and he was quite unconvinced there was any problem at all. If the answer is "there is a problem" then we can pursue this across every single GPL'd python file, while if there is no problem we should stop right now. In a discussion with ftp-* we can work out what (conditional) module loading means and how that fits in with the normal run-time linking that we find acceptable in other situations such as for plugins. We've always held runtime loading and compile-time linking as being two different things and we allow programs (even the kernel) to load GPL-incompatible objects/modules/plugins into a GPL'd work at run time. As a quick illustration of the problem, let's take two files that are (modulo GPL+hashlib) indisputably OK in their licensing: ---- 8< -- foo.py -- 8< ---- # WTFPL import sys if len(sys.argv) > 1: import hashlib ---- 8< ------------ 8< ---- ---- 8< -- bar.py -- 8< ---- # GPLv2+ import foo ---- 8< ------------ 8< ---- (a) If I run "python bar.py" hashlib is never loaded into the process so openssl is never loaded. I don't believe we can claim there is a licence incompatibility if the objects are never even in the same process and that has always been our standard test for C code. (b) Does running "python bar.py quux" suddenly become a licence violation because now openssl is loaded? What the user does on their system is their business. The GPL does not restrict them from doing as they please with the code on their own machine. (c) Does having foo.py as GPLv2+ instead of WTFPL change the licensing situation? If (a) and (b) were both OK, no it doesn't. So my argument is that these three things are all fine. Zack, based on your comments in this bug report, I believe your position is that there is a problem here with all three scenarios. Claiming that (a) and (b) are problems licence-wise would mean GPL'd code couldn't use stdlib's logging, threading, multiprocessing, os ... because they (and many other stdlib modules) transitively and conditionally import hashlib. I don't believe that the intention of or the wording of GPLv2 or GPLv3 want that. For reference, if we accept GPL'd python code cannot use hashlib, and relicense debian_support accordingly, then the following packages that import debian_support need to be dealt with similarly: mini-buildd: GPLv2+ ubuntu-dev-tools: GPLv2, GPLv2+, GPLv3, GPLv3+ (I assume that's done in a compatible way) There are few enough users of debian_support to make this check simple to do with codesearch.d.n and manual licence checking. Further, we would also be deciding that all GPL'd users of stdlib's hashlib, urllib, random, threading, multiprocessing, subprocess, os, logging, trace, Queue, cookielib, email, uuid, distutils/upload, imaplib, poplib, ... (and probably others that I missed) were problematic because each of these standard modules directly or transitively and sometimes conditionally imports hashlib. (And we'd be applying that to transitive use too.) One final comment, you would also need to relicense test_debian_support.py, not just debian_support.py cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ [email protected] Debian Developer http://www.debian.org/ [email protected] GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-python-debian-maint
