Re: Proposal: replace no-overwrite with Berkeley DB - Mailing list pgsql-hackers

Benjamin Adida <ben@mit.edu> writes:
> If this were a totally new product, I think it might be an acceptable
> license, a compromise between BSD's total freedom and the GPL's push to keep
> things open-source. However, given that there are existing users of Postgres
> who probably use the binary without distributing source, this license is
> significantly more restrictive than the previous one, and would force
> current users to review their practices.

IMHO it would not be acceptable to make Postgres distribution even a
little less free than it is now.  However, it could be that we can get
around that.  According to the FAQ on Sleepycat's website, they consider
that the open-source restriction applies to the software that directly
calls Berkeley DB --- which would be Postgres.  Code that sits atop
Postgres could still be proprietary without triggering licensing
requirements.  So their existing policy is already close to what we'd
need.

Also, I note (forget if this is on their website or if it was in last
night's private email) that Sleepycat have cut some sort of special
licensing deal with Gnome to persuade the Gnome folks that it's OK for
them to depend on Berkeley DB.  So I expect they'd be open to making
a similar deal with us.  I think a written, signed agreement between
Sleepycat and us, guaranteeing that Berkeley DB + Postgres could be
distributed as freely as Postgres is now, is possible and would solve
everyone's concerns on this issue.

I'm more concerned about the technical issues, the biggest of which
is how we can preserve MVCC semantics.  Mike made a good point that
users don't care about implementation technology --- but they do care
about results, and MVCC's lack of locking (readers don't block writers
nor vice versa) is an important result that I'm unwilling to give up.
I'm also dissatisfied with the idea of going through a "Recno" access
method to get at heap data; that sounds like a recipe for serious
performance degradation.  However, maybe we could address issues like
that by working with the Sleepycat guys to develop a true heap access
method within their framework.  The MVCC issue is more serious because
I'm not sure that could be added to their framework after-the-fact.

If we go into this at all, we'd certainly *not* want to take the
attitude that Berkeley DB is a closed box that we don't get to mess
with.  It's open source and we'd be contributing improvements to it,
probably some pretty major ones.  In effect we'd become partners with
the Sleepycat guys --- and so another big issue is how comfortable we
would be working together.  But it could be a win-win proposition if
we join forces to produce better software than either group could do
alone.

I'm not at all sold that this is a workable proposal --- but I think
it has enough potential to be worth some close examination.
        regards, tom lane