Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL
"Martin v. Löwis" writes: > Note that it is ultimately up to a court to interpret these words of the > GPL, not to the FSF lawyer. True, and in the case of a non-FSF product, any ambiguities would be resolved first by determining the intent of the copyright owner, second (perhaps even overriding the intent of the owner) by the understanding of the user, and only third by asking the author of the license. Nevertheless, in the U.S. at least the court would likely be influenced in its judgments about "intent" and "understanding" by public statements of the author, because those would tend to condition the general public's understanding, including that of the parties to the license. > > Specifically, in > > > > > "Major Component", in this context, means a major essential component > > > (kernel, window system, and so on) of the specific operating system > > > (if any) on which the executable work runs, or a compiler used to > > > produce the work, or an object code interpreter used to run it. > > > > the word "essential" would refer to running the compiler or the > > operating system or interpreter, not to a component essential to > > running the program but in general optional for using the system. > > Maybe my English is not good enough Mine is definitely not! :-) > - I read that to mean that the compiler itself is a major component > of the system (and thus doesn't need to be distributed along with > the source of the GPL'ed program). Note that it explicitly also > says that a "object code interpreter" used to run "it" (the > executable) is a major component, which would explicitly declare > Python a major component (as long as it's actually distributed with > the system). Well, English being what it is, your guess is as good as mine.<0.2 wink> My understanding is that the compiler or interpreter is not being defined as a major component. It is being defined as something which, like a major component, is exempt from the source distribution and licensing requirements of the GPL. As is typical of the GPL :-(, the English is ambiguous as to whether "major essential components" of compilers or interpreters are exempt, too. I would think so, though. This simplifies licensing of things like the runtime code distributed with GCC, Java Swing (or whatever the preferred GUI is nowadays), or the implementation of print() in Python 3 dramatically, at little cost in additional leniency that I can see. That is, the reason that Java and Python programs can usefully be GPL is unrelated to the "major component" part of that clause. Rather, my understanding of the above GPLv3 clause is that it promotes VMs and interpreters to the level of *platform*, just like the kernel. In general using a language *translator* is *not* considered to create a derivative, because a derivative is a (possibly partial or modified) copy of the original. I've asked Richard Stallman about this specifically for GPLv2, and that's what he told me about Emacs Lisp: it is possible to write and distribute non-GPL programs in Emacs Lisp (but difficult, because you have to avoid using Emacs-specific data structures and functions). This makes a fair amount of sense anyway, since the translator works on the program as data, but the translator is not (usually) copied into the program. In other words, the GPL doesn't apply to the output of GCC, not because of the generosity of Richard Stallman, but because in U.S. copyright law, at least, it *can't*.[1] In the case of an interpreter, this is a lot more fuzzy (the interpreter is linked to the implementations of the statements). The English/legalese of GPLv2 doesn't make this clear. I think that's why GPLv3 explicitly specifies "interpreters of object code" in that clause. > If your interpetation was right and Python is *not* a major > component, then any GPL'ed Python application would need to > distribute the source code of Python along with its own source > code, and with that the source of all libraries that are not major > components themselves. Yes, for the libraries. That's what James is worried about. > Also, if your interpretation was right, it wouldn't be possible to > license Java programs under the GPL, since the JVM wouldn't be a major > component, No, of course it's possible for the copyright holders to license Java programs under the GPL, and even for you (not the owner) to create derivatives, as long as you are confident that the copyright holders won't sue you. As for what the law and the GPL actually say about these matters, surely it is not news to you that the GPL sucks unless you want all software GPLed, and even then there are "regrettable" side effects. Footnotes: [1] OTOH, the bison license contains a special clause because the "hairy parser" is a fairly extensive piece of C code that is copied into a program using bison to compile yacc specifications. This clause says basically "the hairy parser is part of bison
Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL
On Thu, Mar 10, 2011 at 2:41 AM, Stephen J. Turnbull wrote: > Joao S. O. Bueno writes: > > > 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: > > Note that your interpretation would allow Python to distribute > arbitrarily licensed libraries and GPL programs to link with them. > That is surely not the intent of the authors of the GPL, and in the > past, the FSF has explicitly restricted the interpretation of "system > library". Specifically, in > > > "Major Component", in this context, means a major essential component > > (kernel, window system, and so on) of the specific operating system > > (if any) on which the executable work runs, or a compiler used to > > produce the work, or an object code interpreter used to run it. > > the word "essential" would refer to running the compiler or the > operating system or interpreter, not to a component essential to > running the program but in general optional for using the system. So tellme how the Python interpreter and the libraries linked to it are not "essential" to a program made in Python? I did not refer to distributing Python itself with GPL librareis linked into it - you had put it this way. The original question is whether a Python program can be GPLed, and the answer is: it can. You can see Antonie Pitrou's first answer to question: " A Python program is not a derivative of the Python interpreter any more than a C program is a derivative of gcc (or any other compiler)." The fact is that Python programs need more of environment t run than a C program, since besides the system libraries they run oer the Python interpreter and any libraries it links too: all these are intrinsic in order to the proram to run. Otherwise no one could ever have a GPLed program written in notoriously privative language or environments such as Visualbasic, Microsfot's .net, or even Java using Oracle's Java environment. > Perhaps this has changed with the advent of GPL v3, but the FSF used > this interpretation to block the consideration of (old-Qt-licensed) Qt > as a system library on GNU/Linux systems, even where distributed by > vendors such as Red Hat. OTOH, for some reason Motif on Sun and HP > systems, and Windows and Mac GUIs were considered essential. > They where then contradicting their own current FAQs on the GPL. Anyway, the original author has always the right to exempt some library his program links to of complying with the GPL. js -><- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL
Note that your interpretation would allow Python to distribute arbitrarily licensed libraries and GPL programs to link with them. That is surely not the intent of the authors of the GPL, and in the past, the FSF has explicitly restricted the interpretation of "system library". Note that it is ultimately up to a court to interpret these words of the GPL, not to the FSF lawyer. Specifically, in > "Major Component", in this context, means a major essential component > (kernel, window system, and so on) of the specific operating system > (if any) on which the executable work runs, or a compiler used to > produce the work, or an object code interpreter used to run it. the word "essential" would refer to running the compiler or the operating system or interpreter, not to a component essential to running the program but in general optional for using the system. Maybe my English is not good enough - I read that to mean that the compiler itself is a major component of the system (and thus doesn't need to be distributed along with the source of the GPL'ed program). Note that it explicitly also says that a "object code interpreter" used to run "it" (the executable) is a major component, which would explicitly declare Python a major component (as long as it's actually distributed with the system). If your interpetation was right and Python is *not* a major component, then any GPL'ed Python application would need to distribute the source code of Python along with its own source code, and with that the source of all libraries that are not major components themselves. Also, if your interpretation was right, it wouldn't be possible to license Java programs under the GPL, since the JVM wouldn't be a major component, and hence you would need to distribute JVM's source code under the terms of the GPL (which you may or may not be able to today, but surely couldn't over many years during which many GPL'ed Java programs were written). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL
James Y Knight, 10.03.2011 06:52: 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. Agreed. Could you file a bug report, in case there isn't one yet? Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL
Westley Martínez writes: > Is it legal to distribute GPL programs that use the Win32 API? Yes. Their use of the Win32 API falls under the "essential system library" clause. The criterion for "essential" is that normal, basic use of the system would fail without the library. Windows won't boot without Win32 API support, so it satisfies that clause. OpenSSL is needed only by a minority of programs, and Python itself will run without it, so OpenSSL will not qualify for that exception. As Martin points out, that's not relevant to Python, since it can be built without and Python is not a GPL program. And as Antoine points out, it's not relevant to Python programs unless they actually call OpenSSL functions. In that case only, the program becomes a derivative of OpenSSL, and only with agreement of all owners of GPLed code in the program may the program be distributed. (Ie, if they all agree to the special exception for specific non-GPL libraries that Joao Bueno describes.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL
Joao S. O. Bueno writes: > 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: Note that your interpretation would allow Python to distribute arbitrarily licensed libraries and GPL programs to link with them. That is surely not the intent of the authors of the GPL, and in the past, the FSF has explicitly restricted the interpretation of "system library". Specifically, in > "Major Component", in this context, means a major essential component > (kernel, window system, and so on) of the specific operating system > (if any) on which the executable work runs, or a compiler used to > produce the work, or an object code interpreter used to run it. the word "essential" would refer to running the compiler or the operating system or interpreter, not to a component essential to running the program but in general optional for using the system. Perhaps this has changed with the advent of GPL v3, but the FSF used this interpretation to block the consideration of (old-Qt-licensed) Qt as a system library on GNU/Linux systems, even where distributed by vendors such as Red Hat. OTOH, for some reason Motif on Sun and HP systems, and Windows and Mac GUIs were considered essential. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL
On Thu, Mar 10, 2011 at 12:49 AM, Westley Martínez wrote: > On Wed, 2011-03-09 at 18:20 -0500, James Y Knight wrote: >> It's well known that OpenSSL is incompatible with the GPL. [1] Python (from >> 2.6) is *always* linked against openssl, instead of waiting for you to >> "import ssl". >> >> Doesn't this mean it's now impossible (rather, a license violation) to >> distribute a GPL'd python program (or to use a GPL'd library in your python >> program)? This seems like a problem... >> >> Thanks to Ulrik Sverdrup >> (http://lists.debian.org/debian-python/2011/03/msg00082.html) for pointing >> this out... >> >> James >> >> [1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html > > Is it legal to distribute GPL programs that use the Win32 API? Of course it is -- otherwise no program running on windows could ever be under the GPL. You probably are thinking of Python programs that would specifically use the win32 extensions -- but implicitly any program, including binary programs, using Windows will have to use some API from the OS in order to communicate with the rest of the system and the world. This "system library" exception could not apply automatically to Python win32 if its terms where too restrictive or if it was a component hard to set up, or with a high commercial cost (neither is the case). But even then, since the licensing of a Software is ultimately upon its authors, they are always OK to add special exceptions to the License file distributed with the program, stating that this or that library is exempted from the GPL terms. What one can't do is to take a work under the GPL, build upon it, and in this process make use of a library or module with a license incompatible with the GPL, and redistribute that work (though, note that even then one is free to use such a work on his own systems). Because then he'd have to add that exception to the original license. js -><- That is clear from the examples on the FAQ. > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL
Am 09.03.11 18:20, schrieb James Y Knight: [1] Python (from 2.6) is *always* linked against openssl Others have already pointed that out, but let me stress it again: this statement is false. It is as possible and easy to build Python without OpenSSL as it always was. > instead of waiting for you to "import ssl". In addition, that is also false. Even if OpenSSL is used, it is easy to build Python so that OpenSSL is only loaded when needed. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL
On Wed, 2011-03-09 at 18:20 -0500, James Y Knight wrote: > It's well known that OpenSSL is incompatible with the GPL. [1] Python (from > 2.6) is *always* linked against openssl, instead of waiting for you to > "import ssl". > > Doesn't this mean it's now impossible (rather, a license violation) to > distribute a GPL'd python program (or to use a GPL'd library in your python > program)? This seems like a problem... > > Thanks to Ulrik Sverdrup > (http://lists.debian.org/debian-python/2011/03/msg00082.html) for pointing > this out... > > James > > [1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html Is it legal to distribute GPL programs that use the Win32 API? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL
On Wed, Mar 9, 2011 at 8:20 PM, James Y Knight wrote: > It's well known that OpenSSL is incompatible with the GPL. [1] Python (from > 2.6) is *always* linked against openssl, instead of waiting for you to > "import ssl". > > Doesn't this mean it's now impossible (rather, a license violation) to > distribute a GPL'd python program (or to use a GPL'd library in your python > program)? This seems like a problem... Hi - 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: http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs In GPLv2 we have """ However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. """ And in v3: """ The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. """ regards, js -><- > > Thanks to Ulrik Sverdrup > (http://lists.debian.org/debian-python/2011/03/msg00082.html) for pointing > this out... > > James > > [1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL
On Thu, Mar 10, 2011 at 00:32, Antoine Pitrou wrote: > Also, with the system Python 2.6 shipped on a Mandriva distribution: > > $ ldd /usr/bin/python > linux-vdso.so.1 => (0x7fff8456d000) > libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0 > (0x7f1a0b1e2000) libc.so.6 => /lib64/libc.so.6 (0x7f1a0ae76000) > libdl.so.2 => /lib64/libdl.so.2 (0x7f1a0ac72000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x7f1a0aa56000) > libutil.so.1 => /lib64/libutil.so.1 (0x7f1a0a853000) > libm.so.6 => /lib64/libm.so.6 (0x7f1a0a5d1000) > /lib64/ld-linux-x86-64.so.2 (0x7f1a0b583000) > > $ objdump -p /usr/bin/python | grep NEEDED > NEEDED libpython2.6.so.1.0 > NEEDED libc.so.6 (just nitpicking) but it's there on a debian system: $ ldd /usr/bin/python linux-vdso.so.1 => (0x77bff000) libpthread.so.0 => /lib/libpthread.so.0 (0x7f9abcb82000) libdl.so.2 => /lib/libdl.so.2 (0x7f9abc97e000) libutil.so.1 => /lib/libutil.so.1 (0x7f9abc77a000) libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x7f9abc525000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x7f9abc184000) libz.so.1 => /usr/lib/libz.so.1 (0x7f9abbf6c000) libm.so.6 => /lib/libm.so.6 (0x7f9abbcea000) libc.so.6 => /lib/libc.so.6 (0x7f9abb989000) /lib64/ld-linux-x86-64.so.2 (0x7f9abcdc4000) $ objdump -p /usr/bin/python | 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 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" Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL
On Wed, 9 Mar 2011 18:20:01 -0500 James Y Knight wrote: > It's well known that OpenSSL is incompatible with the GPL. [1] Python (from > 2.6) is *always* linked against openssl, instead of waiting for you to > "import ssl". > > Doesn't this mean it's now impossible (rather, a license violation) to > distribute a GPL'd python program (or to use a GPL'd library in your python > program)? This seems like a problem... A Python program is not a derivative of the Python interpreter any more than a C program is a derivative of gcc (or any other compiler). That said, with a non-shared build of Python 3.x: $ ldd ./python linux-vdso.so.1 => (0x7fffa574d000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7fd9a56d2000) libdl.so.2 => /lib64/libdl.so.2 (0x7fd9a54ce000) libutil.so.1 => /lib64/libutil.so.1 (0x7fd9a52cb000) libm.so.6 => /lib64/libm.so.6 (0x7fd9a5049000) libc.so.6 => /lib64/libc.so.6 (0x7fd9a4cdd000) /lib64/ld-linux-x86-64.so.2 (0x7fd9a58ee000) $ objdump -p ./python | grep NEEDED NEEDED libpthread.so.0 NEEDED libdl.so.2 NEEDED libutil.so.1 NEEDED libm.so.6 NEEDED libc.so.6 Also, with the system Python 2.6 shipped on a Mandriva distribution: $ ldd /usr/bin/python linux-vdso.so.1 => (0x7fff8456d000) libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0 (0x7f1a0b1e2000) libc.so.6 => /lib64/libc.so.6 (0x7f1a0ae76000) libdl.so.2 => /lib64/libdl.so.2 (0x7f1a0ac72000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f1a0aa56000) libutil.so.1 => /lib64/libutil.so.1 (0x7f1a0a853000) libm.so.6 => /lib64/libm.so.6 (0x7f1a0a5d1000) /lib64/ld-linux-x86-64.so.2 (0x7f1a0b583000) $ objdump -p /usr/bin/python | grep NEEDED NEEDED libpython2.6.so.1.0 NEEDED libc.so.6 So I'm not sure which build options led to that result. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] GPL'd python code vs Python2.6 linked against OpenSSL
It's well known that OpenSSL is incompatible with the GPL. [1] Python (from 2.6) is *always* linked against openssl, instead of waiting for you to "import ssl". Doesn't this mean it's now impossible (rather, a license violation) to distribute a GPL'd python program (or to use a GPL'd library in your python program)? This seems like a problem... Thanks to Ulrik Sverdrup (http://lists.debian.org/debian-python/2011/03/msg00082.html) for pointing this out... James [1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
