Where is Berkeley DB on your system? Can you live without DB 1.85?

David LeBlanc whisper at oz.net
Mon Jun 10 04:34:54 EDT 2002


> -----Original Message-----
> From: python-list-admin at python.org
> [mailto:python-list-admin at python.org]On Behalf Of Kragen Sitaker
> Sent: Monday, June 10, 2002 0:38
> To: python-list at python.org
> Subject: Re: Where is Berkeley DB on your system? Can you live without
> DB 1.85?
>
>
> "David LeBlanc" <whisper at oz.net> writes:
> > AFAIK, this is true for any version of Sleepycat > 1.85, and
> has been true
> > for years. Including a later version of Sleepycat BSDDB imposes a
> > constraint, not on Python itself, which is free, but on someone
> who would
> > like to distribute Python along with their
> _commercial_for_sale_ app (think
> > Py2Exe for example).
>
> I don't think anybody has proposed including a modern version of BSD
> DB in Python, only dropping support for an old version, which is also
> not included in Python.

Hmmm... I have Python 2.2.1 binary installed from Sourceforge - what is that
bsddb.pyd file dated 4/9/2002 in the dlls directory?

> "commercial for-sale" is misleading.  The current license of BSD DB
> allows distribution in commercial for-sale apps with no further hassle
> unless said commercial for-sale apps are, approximately, free
> software, and it forbids inclusion in noncommercial not-for-sale apps
> unless said not-for-sale apps are, approximately, free software.

This makes no sense, so I'll just pass on it. I think you got your facts
backwards.

> > If you want to change Python's market dynamics and require
> _all_ Python apps
> > to be free and open source, then you can include any version of
> Sleepycat
> > BSDDB you like. I doubt it will have a positive impact on
> Python's future
> > prospects. It didn't work for Perl in it's early years and
> that's why the
> > Artistic License was change to allow "for fee" distributions
> that included
> > Perl.
>
> I thought the AL allowed this from the beginning.  Certainly
> Sleepycat's license doesn't forbid it.

IIRC, in the early days of Pearl, the "AL" had the same tainting as GPL.
Again, IIRC, some of the Pearl inner circle where the ones who agitated for
the change so they could make some money from all the time they where
pouring into Pearl. Today, the AL is more like the GLL.

Sleepycat's license doesn't prohibit commercial for-fee distribution, it
simply requires that you negotiate a payment scheme with them for the use of
versions after 1.85. They don't charge for redistribution with free open
source apps like Python. However, as I said in my last post (along with
exerpts from Sleepycat's FAQ on the subject), if a Python developer was to
include a Python distribution that included a version of bsddb after 1.85 in
a for-fee commercial program, then they would have to negotiate a payment
scheme with Sleepycat. More to the point, they would have to know that they
would have to do that or risk copyright infringement. (BTW, I was, at one
time, in such discussions with Sleepycat, but the project got dropped. I
found their fees to be extremely reasonable and they where quite flexible -
nice people to work with.)

> In any case, your irresponsible, alarmist accusation is a red herring,
> as you will no doubt agree once you understand the situation properly.
> Dropping support for db 1.85 will not require all Python apps to be
> free software or open source; it won't even require all distributions
> of Python to be free software or open source.  It will only require
> distributions of Python with bsddb support to either link to an
> external BSD DB library (like the one included with glibc) or be free
> software.

I don't think I'm the one not understanding the situation properly, nor
could anything I posted be reasonably construed as irresponsible, alarmest
or an accusation! I never said anthing pro or con wrt to dropping bsddb 1.85
from the distribution. I didn't even make any accusations! I was only
referring to versions of bssdb after 1.85 having commercial licensing
provisions.

> If your application doesn't use BSD DB, it won't be affected by this,
> even if you ship binary distributions of it, made with e.g. McMillan
> Installer.  If your application uses BSD DB and you are shipping db
> 1.85, you are screwing your users, probably without knowing it (unless
> you know enough about db 1.85's bugs to work around them.).  This
> change will allow you to continue to screw your users in the same way,
> but you will be required to know that was what you were doing.

No customers are getting screwed :->

> At present, there are irresponsible vendors shipping proprietary
> distributions of Python including BSD DB 1.85.  This course of action
> subjects the entire Python community to pressure to drop or deprecate
> support for BSD DB, because BSD DB 1.85 is badly broken.  Those of us
> who use sane versions of BSD DB are hurt by this, because BSD DB is by
> far the most featureful, performant, and reliable of the other
> dbm-style databases Python supports.

Something remarkably like bsddb is getting shipped in python.org python
binaries from sourceforge as far as I can tell (Windows binaries).

> I assume these vendors are being irresponsible because they don't know
> they are imperiling their users' data by using this buggy old
> software.  This change will let them know that the problem exists, and
> they can either stop shipping proprietary distributions, stop
> supporting BSD DB, or start maintaining BSD DB 1.x.

<gasp> could Guido be so heartless as to imperil people's data by allowing
the inclusion bsddb in the standard Python distro?!?

> If it's not clear, I'm in favor of this change.  It helps everyone
> everywhere.

Whatever gets done, it would be nice to have some useful db shipped in the
standard Python distro. I have heard a rumor that gadfly is such a
candidate - and also that gadfly has bugs of it's own.

BTW, since you're so keen on the failings of the BSDDB that seems to ship
with standard Python, perhaps you'd like to contribute information on how to
use it and what it's pitfalls are and ways to avoid them to the pythondoc?
Hell, you could even help maintain BSD DB 1.x!

Dave LeBlanc
Seattle, WA USA






More information about the Python-list mailing list