Re: Official ODBC announcement - Mailing list pgsql-odbc
From | Shachar Shemesh |
---|---|
Subject | Re: Official ODBC announcement |
Date | |
Msg-id | 42739AC9.8010603@shemesh.biz Whole thread Raw |
In response to | Official ODBC announcement ("Joshua D. Drake" <jd@commandprompt.com>) |
List | pgsql-odbc |
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/
pgsql-odbc by date: