
It's similar to GPL's "copyleft". I think it's no different from what we do with e.g. GNU readline, so I think it's okay. Redistributors of Python in binary form will have to beware though. I wonder if we're on thin ice with the RPMs (since we don't clarify any of this)?
... but we're not including readline in the standard Python distribution. Why would we want to include the database code itself in Python ?
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.
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. --Guido van Rossum (home page: http://www.python.org/~guido/)