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

[Kragen Sitaker]

"David LeBlanc" <whisper at oz.net> writes:
> > 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?

That itself is probably the Python module that interfaces to whatever
version of Berkeley DB you have, not Berkeley DB itself (although it
could be statically linked in there), but Tim Peters has asserted that
a binary version of db 1.85 is included, regardless.

So I was wrong.  Certainly Berkeley DB is not included in the Python
source tarball.

> > "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.

It makes no sense because I got the sense of my first clause
backwards; thanks for the correction.  It should read as follows:

    It allows distribution in commercial for-sale apps with no further
    hassle unless they are *not* free software.

> > > 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.

My experience with Perl doesn't go back to the days before its public
release when it was spelled with an "a", so I'll take your word for it.

> 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.

This is self-contradictory.  The second statement is accurate; the
first statement is not.  They don't require that you negotiate a
payment scheme with them *unless your commercial for-fee distribution
is a distribution of proprietary software*.  For example, Red Hat
doesn't have to negotiate a license to Berkeley DB to include it in their
commercial for-free Linux distribution.

> 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.

Again, *only* if it was a *proprietary* for-fee commercial program.
The same issue would come up if they were distributing a proprietary
not-for-fee noncommercial program.

> More to the point, they would have to know that they would have to
> do that or risk copyright infringement.

Yes, they would have to understand the licensing terms of the software
they were redistributing.

> > 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!

You said:
> 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.

That was what I meant by "your irresponsible, alarmist accusation". It
isn't true, and it sounds scary and accusatory to me.  Only Python
apps that use Berkeley DB would be affected, and then only if they're
distributed in binary form, and then only if they're running on
operating systems that don't ship with Berkeley DB.

> > 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.

I think dumbdbm and gdbm are more comparable to Berkeley DB than Gadfly is;
either or both of them could be included in a standard Python distro
with no licensing problems, even for proprietary software.

> 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?

I don't know what they are because I use sane versions of Berkeley DB.
I seem to recall that hash-style db 1.85 files will fail after a lot
of inserts, and Sleepycat has patches on their page that fixes a
couple of core dumps and one case of lost updates in the BTree code,
but ISTR that there are other problems, too.

> Hell, you could even help maintain BSD DB 1.x!

I think it's more cost-effective to just ship 4.0 in binary
distributions of Python and require users to switch.  If someone finds
4.0 (or 2.x or 3.x) unacceptable because they want to incorporate
Berkeley DB functionality into proprietary software, I would be
willing to work on 1.x for them at my regular contract rate, but
increasing the profits of proprietary software companies who are too
cheap to buy a license from Sleepycat isn't really my idea of a fun
way to spend my spare time.  Given that, it would probably be more
cost-effective for such a company to just pay Sleepycat for a 4.0
license.