Re: Official ODBC announcement

Joshua D. Drake wrote:

> Hello,
>
> I just wanted to jump in here and follow up on our very quiet (pretty
> much non existent) announcement about us rewriting ODBC. Below you
> will find the (very high level) overview of our initial plans:
>
> Written from scratch using C against libpq.
>
> Written from scratch to be cross platform with primary targets of:
> Win32
> Linux
> MacOSX
>
> Written with UNICODE/Multibyte support.
>
> Written to support only 8.0 and above.
>
> Support SSL Connections
>
> Support Compressed connections (Mammoth only at this time)
>
> Support Large Objects
>
> Support Bytea
>
> The driver will be released as GPL with commercial licenses available
> from Command Prompt, Inc.
>
> Version 1.0 Milestones:
>
> A driver suitable to be considered Alpha
> The Alpha driver should have 75% of the feature set of the current
> driver that can be downloaded from odbc.postgresql.org.
>
> A driver suitable to be considered Beta
> The Beta driver should include 100% of the feature set of the
> current driver that can be downloaded from odbc.postgresql.org.
> Alpha support for all ODBC 3.0 API compliant functions should be
> included.
>
> A driver suitable to be considered Beta 2
> The Beta 2 driver should include 100% of the feature set of the
> current driver plus all reported bugs fixed. It should include
> Beta support for all ODBC 3.0 API compliant functions.
>
> A driver suitable to be considered to be RC1
> The RC1 driver should include 100% of the feature set of the
> current driver plus all reported bugs fixed. It should include
> RC level support for all ODBC 3.0 API compliant functions.
>
> A driver suitable to be considered 1.0.
>
> The 2.0 driver should be ODBC 3.5+ Compliant. The timeline for 2.0
> has not been set.
>
> Some features I would like to see mapped to from ODBC to libpq
> would be server side prepare and cursors.
>
> Linux
> Win32
> Solaris - nossl
> Solaris - SSL
>
> One outstanding question is should we use libpq? We may want
> to implement the new protocol directly instead. What are the benefits
> we can get from either?
>
> Sincerely,
>
> Joshua D. Drake
>
As the matter exploded, allow me to share my opinions + experience:
Opinions:
This is a trick. It may work for some, but it's still a trick. The idea
behind free software is freedom to everyone, with no centralized
control. Tricks such as the one you are trying to pull off here is a way
to SEEM like you are creating a free software, while you are really
trying to get free support and advertising from the community.

If that's not bad enough, there is no way in hell anyone can convince me
that Acess becomes a derivative work of your ODBC driver merely because
it "links" with it. For one thing, Access is an established application
while your driver doesn't even exist yet. Under section 5 of the GPL, as
well as under copyright law that way I understand it (and I'm not a
lawyer), you have no way to enforce the GPL anyways.

The problem, as far as I'm concerned, with the scheme you offer is that
you have all the control, in direct contradiction to free software
spirit. You cannot legally link to anything but GPL software (not LGPL,
not BSD, nothing). If you want, in some time in the future, to raise the
amount of money you charge, there is no way for me to stop you. In
short, any contributions I make, if any, will be under the LGPL license.
You can put them into the GPL project, you can come to your senses and
relicense as LGPL, but not distribute them as part of your commercial
project.

Experience:
My company, Lingnu Open Source Consulting, wrote the OLE DB provider for
PostgreSQL. It's under the LGPL license, and is available from pgfoundry
at http://www.pgfoundry.org/projects/oledb. It is fairly functional (not
up to the same level of maturity of psqlodbc, but it is actively
maintained.... ).

My experience with alternative business models is this. They don't work.
At the moment, not one party using PgOleDb has shown any interest in
paying for the functionality they deem missing. We even haven't received
a single code contribution from the community. In fact, at the money
Lingnu can implement Joshua's business plan. We are the sole copyright
holder, for the sad reason that we are the sole authors. To date, no one
else has done anything to promote PgOleDb in the form of code
contribution. Some people promised to, but no one has delivered. This,
despite the fact the fact that PgOleDb is quickly becoming the second
most popular download on pgfoundry, after PostgreSQL Windows Installer
itself.

Don't get me wrong. I'm not sorry Lingnu open sourced the driver. We
have got feedback that makes this a very worth while thing. The original
work was partially sponsored by a client, but that client is the sole
income we have had to date from PgOleDb. What I'm trying to say here is
that people are not very quick to pay for getting their problems solved,
even when a commercial interest is involved. I've even set up a survey
on pgfoundry, to find out more.

I'm thinking of setting up a bug bounty system, but other then that, I
don't think hoping that support call just pour in is a realistic thing
with ODBC. If it doesn't work with PgOleDb, which is:
1. The only implementation available to PG users.
2. Need more work.
3. Seems the recommended technology for new applications.

Just something for everybody to chew on.

Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/