Re: State of PostgreSQL's drivers in Python

On 2/8/10, Nicholas Bastin <[email protected]> wrote:
> On Mon, Feb 8, 2010 at 05:55, Federico Di Gregorio <fog-NGVKUo/i/[email protected]> wrote:
> > On 08/02/2010 00:46, Cezary Statkiewicz wrote:
> > >  And a summary:
> > >
> > >
> http://it.toolbox.com/blogs/database-soup/postgres-needs-a-new-python-
> > > driver-36815
> >
> > Most of what he says is wrong.
>
> It would be interesting if someone would take it point by point as to what
> they believe to be incorrect (he doesn't really make that many
> non-subjective claims, so it's interesting that you state that it's mostly
> wrong).  From the perspective of someone who has dealt with most of these
> drivers (although not the Python 3 driver, which may be great, but many of
> us aren't in a position to use Python 3) over the last few years, the points
> seem pretty much on target (if broad).  In my experience pyscopg2 is
> definitely the best, but the documentation is this mailing list and the
> source code - which is to say, non-existant.  The license is also less than
> desirable for many open source projects, let alone the ambiguity of the
> commercial option.

Well, Josh collected bunch of anecdotes and added spin to them,
good for getting clicks but bad for PR...

- Calling licence "bizarre-hacked-up" is over the top, GPL+exception
  is pretty common - Linux, GCC, Java.  And the OpenSSL situation
  even requires it.

- The "transaction-control" issue is some local anomaly of his that
  they are not ready yet to report as bug, because even the
  guilty component is unknown.  So putting it into overview of
  Python drivers is stupid.

- Blaming the DB-API for multitude of drivers is silly,
  all databases should be affected then.

  The real reason is probably in the direction of Postgres minimal
  presence in the web world.  So the drivers were written with some
  specific app in mind, instead of "standard component".

  Another reason is likely "Core Postgres ignores surrounding
  infrastructure", which makes hard coordinate effort and
  get "preferred/only" projects in some area, unless they are
  coordinated elsewhere.  Eg: replication.

> Of course, the license "problems" are a matter of perspective - this license
> may be very much what you intend and that is perfectly fine, but you have to
> realize that it is a constraint for adoption, especially given a situation
> where both Python and PostgreSQL have significantly more flexible license
> terms.

Well, some of the confusion is actually legitimate.

The problem is that when you try to find a driver for Postgres:

  http://wiki.python.org/moin/PostgreSQL
  http://wiki.postgresql.org/wiki/Python

The Psycopg does not hop out as the preferred driver, and only one
whose DB-API 2.0 interface has gotten any level of scrutiny.

The GPL will scare people away.  "What, I need to GPL my client apps?"
Even if the GPL does not work that way when importing Python modules,
users don't want to consult lawyers when picking db driver.

Same for GPL+exception - it may be effectively LGPL, but people
rightfully are scared of custom licenses.  And the Psycopg
"exception" text is quite long thus leaving the impression
of custom license.

And the final blow is the dead website.

So if we want to keep Psycopg as preferred driver for Postgres:

- Fix website.  Simplest would be to point to Postgres wiki page.

- Set the licence to LGPL.  That would simply clarify current license.

The BSD license would be even better ofcourse.  As both Postgres
and Python are BSD-style licensed, then there is not really a good
reason for Psycopg be differently licensed.

-- 
marko