[draft] debian_support.py relicensing under GPL2+ with OpenSSL exception
Stuart Prescott
stuart at debian.org
Fri Jun 20 01:18:18 UTC 2014
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
More information about the pkg-python-debian-maint
mailing list