OpenSSL in Python (move to variant?)

Dan Ports dports at macports.org
Thu Nov 24 02:02:22 PST 2011


On Wed, Nov 23, 2011 at 09:46:20PM +1100, Joshua Root wrote:
> I'm not entirely sure it's a false failure. FSF's position is a little
> bit complicated and to me seems to try to make distinctions that don't
> exist in reality. They say an interpreted program is not a derivative
> work of the interpreter it runs in, which includes any libraries it may
> use. But then they say that "library bindings" that can be used by
> interpreted code do make the interpreted code a derivative work of the
> library it uses via the bindings.

Well, as it stands now, the OpenSSL dependency means that we can't
distribute any GPLed program that uses Python at all, even if it
doesn't touch the SSL module. That's obviously overly conservative, but
we don't currently have any way to do better.

> The situation for code that uses e.g. hashlib, which is considered a
> standard part of python, is thus vague. Even vaguer if it doesn't
> directly use hashlib but uses some standard library code that uses hashlib.

Yeah, now that you mention hashlib I see that there's possibly more
code depending on openssl libraries than I thought. There are also some
pretty common standard library modules that can also use SSL
indirectly, like urllib. This also seems like an argument against moving
SSL support to a variant.

> For python, gdbm could and probably should be split out into a separate
> port (again). I don't know if that's easily doable for perl, or how much
> perl code relies on gdbm being available. The perl5.8 port actually has
> it as a non-default variant.

Just to throw a couple of other data points out there, it looks like
Debian deals with this problem by splitting gdbm but not OpenSSL out of
their Python package (and relying on manual checking of license
compatibility for dependents, as they always do). Fedora views this as
a non-issue because they consider OpenSSL to fall under the "system
library" exception of the GPL.

Dan

-- 
Dan R. K. Ports              MIT CSAIL                http://drkp.net/


More information about the macports-dev mailing list