Guido van Rossum wrote:
Not in the source distro, but it will end up in the RPMs and other binary distros.
But that would violate the Sleepycat license; we are not shipping readline or a module which statically links against readline in the binary distros for the same reason.
It only violates the Sleepycat license if (a) we don't include that license with the RPM or (b) we include closed-source code in that RPM. We're violating only (a) AFAIK and that's easily fixed.
Ok.
As I understand, the BSD version shipped with Python so far is using a standard BSD style license, so there's no problem with it. However, Sleepycat added a copyleft kind of restriction to the BSD license which makes this troublesome, esp. since the restriction is not at all clear about what "use of the DB software" really means. Their web-page on this is:
http://www.sleepycat.com/licensing.html
Also, the Sleepycat license is not compatible with the Python license in the sense that the Python license is far less restrictive than the Sleepycat one. We'd have to make it very clear that we have integrated third-party code into the archive which falls under a much more restrictive license. (FWIW, It would actually be wise to summarize all the different licenses in the Python distro somewhere...)
So back to my original question: why go through all these troubles ?
We're not planning to incorporate Sleepycat code in the python source distribution. But if setup.py builds bsddb if it finds the parts, it's hard to keep the Sleepycat binaries in the RPMs.
It's not like it's impossible, though :-). Ideal would be to have the Python module link against the shared lib of the Sleepycat DB (if that's possible). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/