[draft] debian_support.py relicensing under GPL2+ with OpenSSL exception

[Stuart Prescott]

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/   stuart at nanonanonano.net
Debian Developer   http://www.debian.org/         stuart at debian.org
GPG fingerprint    90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7