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/ _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev