Official ODBC announcement

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

--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org

Joshua D. Drake wrote:
> 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.

Well, GPL is certainly a minus for a lot of PostgreSQL folks. The
current ODBC driver is LGPL and that seems OK, though not ideal. Seems
we will have to live with two drivers, one GPL and one LGPL.

When you say "commercial licenses", I assume you just mean commercial
support, not non-GPL versions, because if you do that, you can't take
contributions from anyone (unless you want them to sign ownership over
to CP) and you might as well yank it off pgfoundry.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

> Well, GPL is certainly a minus for a lot of PostgreSQL folks. The
> current ODBC driver is LGPL and that seems OK, though not ideal. Seems
> we will have to live with two drivers, one GPL and one LGPL.

We are taking a very similar road as TrollTech with QT on this
particular project. We want to deliver the highest quality driver
possible which means we need to insure a revenue stream from those who
would need to use ODBC in a closed sourced environment.

The driver is still Open Source and still free to those who will be
using or creating software that is GPL compatible.

> When you say "commercial licenses", I assume you just mean commercial
> support, not non-GPL versions, because if you do that,

I do mean non-GPL versions and commercial support. However there isn't
any real commercial support with ODBC. If you correctly code the driver
it will work without the need for support except in the very rare
circumstances.

> you can't take
> contributions from anyone (unless you want them to sign ownership over

This is something that we are still trying to figure out.

> to CP) and you might as well yank it off pgfoundry.

Are you forgetting community mailing lists? Community documentation?
Community discussion of API? Bug reporting? Community support? All the
things that make pgfoundry and the PostgreSQL community great?

Sincerely,

Joshua D. Drake
Command Prompt, Inc.

--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org

Joshua D. Drake wrote:
>
> > Well, GPL is certainly a minus for a lot of PostgreSQL folks. The
> > current ODBC driver is LGPL and that seems OK, though not ideal. Seems
> > we will have to live with two drivers, one GPL and one LGPL.
>
> We are taking a very similar road as TrollTech with QT on this
> particular project. We want to deliver the highest quality driver
> possible which means we need to insure a revenue stream from those who
> would need to use ODBC in a closed sourced environment.
>
> The driver is still Open Source and still free to those who will be
> using or creating software that is GPL compatible.

I hear MySQL calling you. Please pick up the phone. :-)

> > When you say "commercial licenses", I assume you just mean commercial
> > support, not non-GPL versions, because if you do that,
>
> I do mean non-GPL versions and commercial support. However there isn't
> any real commercial support with ODBC. If you correctly code the driver
> it will work without the need for support except in the very rare
> circumstances.
>
> > you can't take
> > contributions from anyone (unless you want them to sign ownership over
>
> This is something that we are still trying to figure out.

Nothing to figure out. You have to get signed contracts giving you
rights to the code changes.

> > to CP) and you might as well yank it off pgfoundry.
>
> Are you forgetting community mailing lists? Community documentation?
> Community discussion of API? Bug reporting? Community support? All the
> things that make pgfoundry and the PostgreSQL community great?

Pgfoundry is for community development of software. Yours is not that
so doesn't belong there. The things that make the PostgreSQL community
great are not part of your project, it seems.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

>>The driver is still Open Source and still free to those who will be
>>using or creating software that is GPL compatible.
>
>
> I hear MySQL calling you. Please pick up the phone. :-)

There is a huge difference between the way TrollTech does it and the
way MySQL does it and you know it.

>>Are you forgetting community mailing lists? Community documentation?
>>Community discussion of API? Bug reporting? Community support? All the
>>things that make pgfoundry and the PostgreSQL community great?
>
>
> Pgfoundry is for community development of software. Yours is not that
> so doesn't belong there. The things that make the PostgreSQL community
> great are not part of your project, it seems.

Opinions vary.

Sincerely,

Joshua D. Drake
Command Prompt, Inc.

>

--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org

Joshua D. Drake wrote:
> >>The driver is still Open Source and still free to those who will be
> >>using or creating software that is GPL compatible.
> >
> >
> > I hear MySQL calling you. Please pick up the phone. :-)
>
> There is a huge difference between the way TrollTech does it and the
> way MySQL does it and you know it.

I don't know it. What is the difference?

> >>Are you forgetting community mailing lists? Community documentation?
> >>Community discussion of API? Bug reporting? Community support? All the
> >>things that make pgfoundry and the PostgreSQL community great?
> >
> >
> > Pgfoundry is for community development of software. Yours is not that
> > so doesn't belong there. The things that make the PostgreSQL community
> > great are not part of your project, it seems.
>
> Opinions vary.

Well, when you remove "community development" from the equation, there
isn't much left.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Joshua D. Drake wrote:
> >>Are you forgetting community mailing lists? Community documentation?
> >>Community discussion of API? Bug reporting? Community support? All the
> >>things that make pgfoundry and the PostgreSQL community great?
> >
> >
> > Pgfoundry is for community development of software. Yours is not that
> > so doesn't belong there. The things that make the PostgreSQL community
> > great are not part of your project, it seems.
>
> Opinions vary.

I will propose a vote that any project that doesn't take contributions
from the community (without rights assignments) be removed from our
servers.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

> I will propose a vote that any project that doesn't take contributions
> from the community (without rights assignments) be removed from our
> servers.

You are obviously welcome to do so.

Sincerely,

Joshua D. Drake
Command Prompt, Inc.

>

--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org

>>
>>>contributions from anyone (unless you want them to sign ownership over
>>
>>This is something that we are still trying to figure out.
>
>
> Nothing to figure out. You have to get signed contracts giving you
> rights to the code changes.

Possibly but that does not require the assignment of the ownership to
the code in anyway. Nor would we request that someone sign over
ownership of contributed work.

Which really isn't that different than what people do everyday
with PostgreSQL. When I submit something to core I am granting
rights to core to use the submitted code, not only that I am giving the
ability for others to close source the work.

Sincerely,

Joshua D. Drake
Command Prompt, Inc.

--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org

On Thu, 28 Apr 2005, Bruce Momjian wrote:

>> Are you forgetting community mailing lists? Community documentation?
>> Community discussion of API? Bug reporting? Community support? All the
>> things that make pgfoundry and the PostgreSQL community great?
>
> Pgfoundry is for community development of software. Yours is not that
> so doesn't belong there. The things that make the PostgreSQL community
> great are not part of your project, it seems.

Huh? I didn't hear Joshua once mention that they would not be accepting
contributions from the community ... nor that it was a closed source
project ... pgFoundry has no restrictions against GPL'd software, so why
exactly doesn't it belong there?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On Wed, Apr 27, 2005 at 09:06:51PM -0700, Joshua D. Drake wrote:
>
> >Well, GPL is certainly a minus for a lot of PostgreSQL folks. The
> >current ODBC driver is LGPL and that seems OK, though not ideal. Seems
> >we will have to live with two drivers, one GPL and one LGPL.
>
> We are taking a very similar road as TrollTech with QT on this
> particular project. We want to deliver the highest quality driver
> possible which means we need to insure a revenue stream from those who
> would need to use ODBC in a closed sourced environment.
>
> The driver is still Open Source and still free to those who will be
> using or creating software that is GPL compatible.

From what I understand of how the GPL applies; closed source software
will still be able to use a GPL ODBC driver without any issues at all.
It is only if they make something that (a) is a modified ODBC
driver based on yours or (b) can ONLY work with this GPL driver
(so, if it can potentially use other drivers, which most ODBC
clients can... there is no issue).

I can definitely understand the benefit of commercial support.

Why would the ability to distribute the ODBC driver without having to
distribute source be something that a company is willing to pay money for?
What do you see as the business (or community) advantage of this?
Do you expect that the amount of commercial interest in licensing the
ODBC driver itself will compensate for the lack of contributions and
potential issues in community support that it will cause?

Lastly, why would the program support 8.x+ only? If you are using libpq
I would image that supporting 7.x+ would be trivial (and necessary).

Overall though, the idea is great and PostgreSQL really does need a
robust and well supported ODBC driver.

I look forward to your response,
Max

On Thu, 28 Apr 2005, Bruce Momjian wrote:

> I will propose a vote that any project that doesn't take contributions
> from the community (without rights assignments) be removed from our
> servers.

At what point did Joshua state that they won't be taking contributions
from the community? *puzzled look*

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

>>The driver is still Open Source and still free to those who will be
>>using or creating software that is GPL compatible.
>
>
>>From what I understand of how the GPL applies; closed source software
> will still be able to use a GPL ODBC driver without any issues at all.

IANAL but my understanding is that you would not be able to create
a piece of software that links (shared or otherwise) to the ODBC driver
unless the license you were using for that software was GPL compatible.

This is one of the reasons that libc and GTK are LGPL on Linux.

> I can definitely understand the benefit of commercial support.
>
> Why would the ability to distribute the ODBC driver without having to
> distribute source be something that a company is willing to pay money for?

We have customers that don't want to have to make their software GPL
compatible. They are willing to pay reasonable fees to not only help us
develop a driver for the overall good of the project but also to have
certain commercial rights that would not be there if they used the GPL
version.

> What do you see as the business (or community) advantage of this?

The business advantage is a $ equation that allows someone like
Command Prompt to provide continual support for the driver. The ODBC
driver (at least for us) doesn't have any secondary revenue streams.
Unlike something like plPHP where we can get residual
coding dollars from being the definitive experts in plPHP.

The ODBC driver is just that, a driver. If it works it doesn't need
support except for continued development and bugfixing.

The community is going to receive a top notch driver, with commercial
support behind it that allows the community as a whole to continue to grow.

The reality is, PostgreSQL on Windows is severely hampered without an
ODBC driver. In time this will not be the case because things will move
to .Net but that move, in majority is still some time off.

> Do you expect that the amount of commercial interest in licensing the
> ODBC driver itself will compensate for the lack of contributions and
> potential issues in community support that it will cause?

I see very little problem that the community will have when they
actually analyze the situation. Command Prompt would never request
that a community member give up ownership of their code. We also would
not suggest that a community member not be able to reuse their
code in anyway that they see fit.

Our thought process at this point is that a community member would
license the code back to us so it could be included not only in the GPL
version but our closed source version as well.

> Lastly, why would the program support 8.x+ only? If you are using libpq
> I would image that supporting 7.x+ would be trivial (and necessary).

Well I don't see it as necessary but it may be trivial. Our thought
process is that the majority of the people who are going to need this
driver are going to be running Windows and thus 8.x.

Also by the time we release 1.0 and especially 2.0 8.1 will be out. That
puts us smack dab into 7.4 getting old. We had to pick a version,
we picked 8 :).

However if there is enough community interest we can definately
reconsider that decision.

> Overall though, the idea is great and PostgreSQL really does need a
> robust and well supported ODBC driver.

That was our thoughts as well.

Sincerely,

Joshua D. Drake
Command Prompt, Inc.

>
> I look forward to your response,
> Max
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org

Joshua D. Drake wrote:
> >>
> >>>contributions from anyone (unless you want them to sign ownership over
> >>
> >>This is something that we are still trying to figure out.
> >
> >
> > Nothing to figure out. You have to get signed contracts giving you
> > rights to the code changes.
>
> Possibly but that does not require the assignment of the ownership to
> the code in anyway. Nor would we request that someone sign over
> ownership of contributed work.
>
> Which really isn't that different than what people do everyday
> with PostgreSQL. When I submit something to core I am granting
> rights to core to use the submitted code, not only that I am giving the
> ability for others to close source the work.

The difference is that the user is using a GPL version that they can not
relicense as non-GPL, while they are contributing back to a company that
can relicense it as non-GPL (think MySQL). The fundamental issue is
that the user does not have the same licensing rights as the company.
In fact the company _owns_ rights to the code not given to users, so
contributions have to be owned by the company too.

You have get approval from the users to release their changes under a
different license than the user who is using the software.

In the PostgreSQL case, the users and the community have the same rights
to the code --- they are equals, which is not the case in your proposal.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

> The fundamental issue is
> that the user does not have the same licensing rights as the company.
> In fact the company _owns_ rights to the code not given to users, so
> contributions have to be owned by the company too.

No they don't. The developer can give a sub license that grants broad
reusability rights. It happens all the time in the closed source world.

For example:

Developer hereby irrevocably grants customer a transferable,
non-exclusive, worldwide, fully-paid up, perpetual, irrevocable,
sublicensable, royalty-free, license to use, exploit, copy,
reproduce, distribute, export, publicly display, publicly perform,
sublicense, modify, improve, enhance and make derivative works of the
Intellectual Property with the right to sublicense, provided, however,
that nothing herein shall be construed to grant customer any other
rights in and to the Intellectual Property or to waive any rights of
Developer in and to the Intellectual Property.

The above does not require that the person contributing give up their
rights to the code, it does however allow the company doing the primary
development to relicense the code as they see fit.

> You have get approval from the users to release their changes under a
> different license than the user who is using the software.

Which can then be sublicensed.

>
> In the PostgreSQL case, the users and the community have the same rights
> to the code --- they are equals, which is not the case in your proposal.

This point has some validity although I think the whole equals think is
a little inflammatory. It is not our intent to harm or make less any
community contribution.

Sincerely,

Joshua D. Drake
Command Prompt, Inc.

--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org

Joshua D. Drake wrote:
> > The fundamental issue is
> > that the user does not have the same licensing rights as the company.
> > In fact the company _owns_ rights to the code not given to users, so
> > contributions have to be owned by the company too.
>
> No they don't. The developer can give a sub license that grants broad
> reusability rights. It happens all the time in the closed source world.

Right, they have to give you a license for rights they don't have. I
didn't mean they gave up their own rights.

> The above does not require that the person contributing give up their
> rights to the code, it does however allow the company doing the primary
> development to relicense the code as they see fit.
>
> > You have get approval from the users to release their changes under a
> > different license than the user who is using the software.
>
> Which can then be sublicensed.

Right.

> >
> > In the PostgreSQL case, the users and the community have the same rights
> > to the code --- they are equals, which is not the case in your proposal.
>
>
> This point has some validity although I think the whole equals think is
> a little inflammatory. It is not our intent to harm or make less any
> community contribution.

Well, who wants to give someone rights to their work when they have not
received such rights to the rest of the code? Few do. Ask MySQL. Ask
Sun about Solaris. Ask MS about shared source. :-)

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

> Well, who wants to give someone rights to their work when they have not
> received such rights to the rest of the code? Few do. Ask MySQL. Ask
> Sun about Solaris. Ask MS about shared source. :-)

MySQL has completely different issues regardless of their licensing model.

TrollTech accepts external patches and does receive them regularly.

Sun and Solaris isn't OSS (at least not yet)
MS and shared source isn't (not even comparable really)

Sincerely,

Joshua D. Drake
Command Prompt, Inc.

--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org

Joshua D. Drake wrote:
>
> > Well, who wants to give someone rights to their work when they have not
> > received such rights to the rest of the code? Few do. Ask MySQL. Ask
> > Sun about Solaris. Ask MS about shared source. :-)
>
> MySQL has completely different issues regardless of their licensing model.
>
> TrollTech accepts external patches and does receive them regularly.

OK, how does TrollTech do it? Do they have a separate license for
submisions? You said sublicense.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

>>MySQL has completely different issues regardless of their licensing model.
>>
>>TrollTech accepts external patches and does receive them regularly.
>
>
> OK, how does TrollTech do it? Do they have a separate license for
> submisions? You said sublicense.

Well TrollTech does it like FSF. They require the copyright be folded
into the project.

I don't want to do that. I would rather just have the perpetual license
and allow the developer to do what they wish.

Sincerely,

Joshua D. Drake

--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org

Joshua D. Drake wrote:
> >>MySQL has completely different issues regardless of their licensing model.
> >>
> >>TrollTech accepts external patches and does receive them regularly.
> >
> >
> > OK, how does TrollTech do it? Do they have a separate license for
> > submisions? You said sublicense.
>
> Well TrollTech does it like FSF. They require the copyright be folded
> into the project.
>
> I don't want to do that. I would rather just have the perpetual license
> and allow the developer to do what they wish.

How do you do that when the submitting license doesn't match the user
license?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

>>
>>I don't want to do that. I would rather just have the perpetual license
>>and allow the developer to do what they wish.
>
>
> How do you do that when the submitting license doesn't match the user
> license?

You have to require that the license that the contribution is being
delivered under is relicenseable, sublicenseable, perpetual and irrevocable.

In that way it is very much like the the current PostgreSQL contributions.

Note that the developer could always dual license the patches.

Sincerely,

Joshua D. Drake

>

--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org

Joshua D. Drake wrote:
> >>
> >>I don't want to do that. I would rather just have the perpetual license
> >>and allow the developer to do what they wish.
> >
> >
> > How do you do that when the submitting license doesn't match the user
> > license?
>
> You have to require that the license that the contribution is being
> delivered under is relicenseable, sublicenseable, perpetual and irrevocable.
>
> In that way it is very much like the the current PostgreSQL contributions.

Yes, and of course it is very different, because that license isn't the
same as the one he has with the existing software.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

>>>How do you do that when the submitting license doesn't match the user
>>>license?
>>
>>You have to require that the license that the contribution is being
>>delivered under is relicenseable, sublicenseable, perpetual and irrevocable.
>>
>>In that way it is very much like the the current PostgreSQL contributions.
>
>
> Yes, and of course it is very different, because that license isn't the
> same as the one he has with the existing software.

Agreed.

Sincerely,

Joshua D. Drake

>

--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org

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.

Sounds good, except for the GPL licence. Recently I had to patch a
7.3.200 driver because all subsequent versions wouldn't be accepted by
an ancient Delphi BDE. I wouldn't have been able to do so with a GPL
licensed driver afaics, so I'll still hoping the best for the current
psqlodbc.

Regards,
Andreas

> The driver will be released as GPL with commercial licenses available
> from Command Prompt, Inc.
>
Don't get me wrong, I am a huge proponent of the GPL, for applications.
I'm all about free -- as in freedom.

Sorry, but an interface library released as GPL is the very embodiment
people's worst fear about open source being risky.

There are, IMHO, basically three types of self contained code packages:
Applications, libraries, and interfaces.

Applications which stand alone should be GPL one can use them freely. The
code is protected.

Libraries which are linked (either dynamically or statically) should be
GPL because using them requires explicit acceptance of the licensing terms
by the developer.

Interfaces, like yours, typically follow 3rd party standards and can be
used in an application without prior knowledge of the developer. As such,
an end user can put themselves in GPL violation without even knowing under
the current definitions of "derivitive work" as put forth by RMS.

That's not freedom, that's a legal minefield. If you are serious about
"free, as in freedom" software, then you should licence it as LGPL.

If I could send a message to the ODBC developers, I would say don't do
this. It is nothing more than using, what I think is, a very bad behavior
of a specific application of the GPL to limit freedom and exploit your
work and generate revenue that you will never see.

If you want to write something that everyone can use, ignore this offer
and continue on with an LGPL version.

> Sounds good, except for the GPL licence. Recently I had to patch a
> 7.3.200 driver because all subsequent versions wouldn't be accepted by
> an ancient Delphi BDE. I wouldn't have been able to do so with a GPL
> licensed driver afaics, so I'll still hoping the best for the current
> psqlodbc.

Why would you had not been able to do that with a GPL driver?

Sincerely,

Joshua D. Drake

--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org

Joshua D. Drake wrote:
>
> ...
> Why would you had not been able to do that with a GPL driver?

I missed the start of this - is ODBC switching to a GPL license?

As much as I personally like the philosophy of GPL, I'd have to
say that 'libraries' (and I view ODBC as a library) might be
better served with LGPL or some other open-source license.
In fact, our own use of PostgreSQL might be jeopardized through
such a switch (fortunately, our use of ODBC is constrained, so
we may be able to just nuke our use of ODBC).

Why? Because we have specialized, complex hardware (telescopes
and instruments) purchased with software from vendors using
non-GPL compatible licenses. We, as a non-profit organization,
cannot afford the extra $$$ it would take to convince those
vendors to provide us the same software under a GPL and there
is *no other* source of such software that we can afford,
either (the "other source" is to write it ourselves or hire
someone to do so). The GPL does not permit us to link this vendor
code in with code that also links in GPL-based libraries.

Please think very carefully about using GPL with code that
has to be linked into other software.

--
Steve Wampler -- swampler(at)noao(dot)edu
The gods that smiled on your birth are now laughing out loud.

* Joshua D. Drake (jd(at)commandprompt(dot)com) wrote:
> The driver will be released as GPL with commercial licenses available
> from Command Prompt, Inc.

I'm a little unsure about how the GPL would play out in this regard..
For example, given that there are alternative ODBC libraries out there
it doesn't strike me that the GPL could be enforced against things
written to use ODBC which happen to end up using this GPL ODBC driver,
since the linking actually ends up happening on the user's machine.

A specific example is- would it be permissible to use Microsoft Access
with the GPL ODBC driver without a commercial license from CP? Is
Access different in some way from some home-grown application I write to
use ODBC? Or is it only if you redistribute the combination of a
closed-source application (such as Access) with the GPL ODBC driver?
Would this mean that a Debian distributor, for example, would not be
permitted to distribute this GPL ODBC driver and non-free applications
from the Debian mirrors which use ODBC, which were even written before
this driver existed?

Just trying to understand if I'll be able to use this GPL driver or not,
and what Debian will think of it (I'm a Debian Developer and certainly
have some interest in this being part of Debian, if possible). :/

Thanks,

Stephen

>
> Why? Because we have specialized, complex hardware (telescopes
> and instruments) purchased with software from vendors using
> non-GPL compatible licenses. We, as a non-profit organization,
> cannot afford the extra $$$

You can't afford 25.00? Or even 200.00? Or even a 50% discount
do non-profits?

it would take to convince those
> vendors to provide us the same software under a GPL and there
> is *no other* source of such software that we can afford,
> either (the "other source" is to write it ourselves or hire
> someone to do so). The GPL does not permit us to link this vendor
> code in with code that also links in GPL-based libraries.

And actually if you don't distribute your code you can but I don't know
what you do.

Sincerely,

Joshua D. Drake

--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org

>
> A specific example is- would it be permissible to use Microsoft Access
> with the GPL ODBC driver without a commercial license from CP?

Yes.

> Is
> Access different in some way from some home-grown application I write to
> use ODBC?

Nope.

Or is it only if you redistribute the combination of a
> closed-source application (such as Access) with the GPL ODBC driver?

Nope.

Where you (or your customer) would have to give dollars would be if you
were using Access as the platform for your application and that
application was closed source.

More specifically if that application was closed source and your
distributed it that way.

Sincerely,

Joshua D. Drake

--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org

Joshua D. Drake wrote:
>>
>> Why? Because we have specialized, complex hardware (telescopes
>> and instruments) purchased with software from vendors using
>> non-GPL compatible licenses. We, as a non-profit organization,
>> cannot afford the extra $$$
>
>
> You can't afford 25.00? Or even 200.00? Or even a 50% discount
> do non-profits?

We're talking on the order of $500,000(USD) dollars - these are not
inexpensive systems (a telescope mount assembly is millions of
dollars) and (whether it's politic or not) the vendors have no desire to
put their source out. We cannot pass such project cost increases on to
our customers (we have none). Of course, if we can get a non-GPL license
for ODBC for the smaller sums you've mentioned, that would help. (The last
GPL package we tried to negotiate a non-GPL license source for [still
open-source, just not GPL] came with a >$25,000(USD) price tag. We've since
switched to an equivalent product available under a BSD license - not as nice
a product, but likely 'good enough'.)

> And actually if you don't distribute your code you can but I don't know
> what you do.

That's what we originally thought, but you cannot distribute a mix
of GPL and non-GPL to outside development teams either! (Subcontractors
or partner institutions). We dropped the aforementioned GPL package
for this very reason.

I realize we're a fringe case. But I do hope people will consider
that such fringe cases do exist.

--
Steve Wampler -- swampler(at)noao(dot)edu
The gods that smiled on your birth are now laughing out loud.

Steve Wampler wrote:
> Joshua D. Drake wrote:
>
>>>Why? Because we have specialized, complex hardware (telescopes
>>>and instruments) purchased with software from vendors using
>>>non-GPL compatible licenses. We, as a non-profit organization,
>>>cannot afford the extra $$$
>>
>>
>>You can't afford 25.00? Or even 200.00? Or even a 50% discount
>>do non-profits?
>
>
> We're talking on the order of $500,000(USD) dollars -

No were not. My point was if Command Prompt charged you 25.00 or even
200.00 or based on the above number even 1000.00 dollars.

these are not
> inexpensive systems (a telescope mount assembly is millions of
> dollars) and (whether it's politic or not) the vendors have no desire to
> put their source out. We cannot pass such project cost increases on to
> our customers (we have none). Of course, if we can get a non-GPL license
> for ODBC for the smaller sums you've mentioned, that would help. (The last
> GPL package we tried to negotiate a non-GPL license source for [still
> open-source, just not GPL] came with a >$25,000(USD) price tag.

Good lord. We zero intention of doing that. We are talking about
a ODBC driver. Now if it were Replicator... That would probably be a
different story.

Sincerely,

Joshua D. Drake

> I realize we're a fringe case. But I do hope people will consider
> that such fringe cases do exist.
>

--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org

* Joshua D. Drake (jd(at)commandprompt(dot)com) wrote:
> >A specific example is- would it be permissible to use Microsoft Access
> >with the GPL ODBC driver without a commercial license from CP?
>
> Yes.

That's good- and covers most of my use cases.

> > Is
> >Access different in some way from some home-grown application I write to
> >use ODBC?
>
> Nope.

Ok.. I guess I was meaning to say with that question was that the
'home-grown' application was closed source, perhaps that misunderstood,
which followed to the next question where that home-grown application
would then be distributed...

> > Or is it only if you redistribute the combination of a
> >closed-source application (such as Access) with the GPL ODBC driver?
>
> Nope.

Ok...

> Where you (or your customer) would have to give dollars would be if you
> were using Access as the platform for your application and that
> application was closed source.
>
> More specifically if that application was closed source and your
> distributed it that way.

Now I'm confused and worried. Perhaps I'm misunderstanding you, but the
situation you describe sounds like:

MyApp -> Access -> ODBC -> GPL ODBC driver

Where I'm guessing 'MyApp' is, perhaps, something in Visual Basic
Access? Yet an application which looked like:

MyApp -> ODBC -> GPL ODBC driver

would be ok (following from the question above about home-grown apps
being different from Access) even if that application was closed source
and distributed (from question 3 above..)?

I'm still curious about how this may play out in Debian, I'm asking some
folks about it. My expectation is that they're going to feel that as
long as an application is written against ODBC that it doesn't directly
depend and isn't a derived work of the GPL ODBC driver, though that
doesn't sound like your intent here (which may concern various folks
enough to not be willing to include it in Debian)...

I guess you might be able to show that a given closed-source
application depends on the GPL ODBC driver if it uses
PostgreSQL-specific SQL/features and doesn't work for some reason with
the current LGPL ODBC driver. Still seems like a bit of a stretch.

Thanks,

Stephen

Stephen Frost wrote:
>...
> I guess you might be able to show that a given closed-source
> application depends on the GPL ODBC driver if it uses
> PostgreSQL-specific SQL/features and doesn't work for some reason with
> the current LGPL ODBC driver. Still seems like a bit of a stretch.

(IANAL, but apparently I just played one on TV.)

If your application links in GPL-code then you can *only* distribute
it under the GPL, at least according to the last GPL package provider
I've occasion to talk with at length).

This means that your closed source application is in violation of
the GPL once you distribute it. There are ways around this
that *may* get closed under GPL3 (and are generally too ugly anyway).

What I don't grok (sorry, sci-fi freak) is how dual-licensed
packages work. That is, if package A has both a GPL and non-GPL
license, but links (internally) GPL'd package B, how *can* package
A be distributed under the non-GPL license?

-Steve
--
Steve Wampler -- swampler(at)noao(dot)edu
The gods that smiled on your birth are now laughing out loud.

Steve Wampler wrote:
> Stephen Frost wrote:
>
>>...
>>I guess you might be able to show that a given closed-source
>>application depends on the GPL ODBC driver if it uses
>>PostgreSQL-specific SQL/features and doesn't work for some reason with
>>the current LGPL ODBC driver. Still seems like a bit of a stretch.
>
>
> (IANAL, but apparently I just played one on TV.)
>
> If your application links in GPL-code then you can *only* distribute
> it under the GPL, at least according to the last GPL package provider
> I've occasion to talk with at length).
>
> This means that your closed source application is in violation of
> the GPL once you distribute it. There are ways around this
> that *may* get closed under GPL3 (and are generally too ugly anyway).
>
> What I don't grok (sorry, sci-fi freak) is how dual-licensed
> packages work. That is, if package A has both a GPL and non-GPL
> license, but links (internally) GPL'd package B, how *can* package
> A be distributed under the non-GPL license?
>
> -Steve

The original license grantor can do whatever he wants with it. This
actually came up on that bastion of intelligence, slashdot (heh) recently.

Take a look at DSML:

http://www.dsmltools.org/licensing.html

They actually use a GPL/MPL hybrid license. The advantage is that you
can take changes committed and integrate them into your closed-source
product or you can make your own closed source changes that don't get
contributed back.

Another tack used with game engines is to LGPL the code of the game
engine and then close the license on the artwork and datafiles
themselves. See Crystalspace3d for an example of that.

http://www.crystalspace3d.org/tikiwiki/tiki-view_articles.php

But in the end it boils down to the fact that the original creator sets
the terms. You agree to those terms when you download the code.
--
John E. Vincent

On Thu, 2005-04-28 at 01:09, Joshua D. Drake wrote:
> We have customers that don't want to have to make their software GPL
> compatible. They are willing to pay reasonable fees to not only help us
> develop a driver for the overall good of the project but also to have
> certain commercial rights that would not be there if they used the GPL
> version.

Would they be willing to pay you a reasonable amount for an ODBC driver
that was bsd licensed? I can't imagine why they wouldn't since this
would allow them all the commercial rights they need.

> > What do you see as the business (or community) advantage of this?
>
> The business advantage is a $ equation that allows someone like
> Command Prompt to provide continual support for the driver. The ODBC
> driver (at least for us) doesn't have any secondary revenue streams.
> Unlike something like plPHP where we can get residual
> coding dollars from being the definitive experts in plPHP.
>
> The ODBC driver is just that, a driver. If it works it doesn't need
> support except for continued development and bugfixing

And that is your residual income. Every new version of PostgreSQL is
going to require *some* hacking around the code, and there are bound to
be some people who would rather pay you (the experts who wrote the code)
to do this rather than do it on their own.
.
> The community is going to receive a top notch driver, with commercial
> support behind it that allows the community as a whole to continue to grow.
>

But you don't have to do these via a dual license scheme. A single
license scheme where you decide to only fix bugs that you are paid to
fix has the potential to work. You don't have to spend time on
maintaining it if you can't make money on it, other people can feel
comfortable contributing to the code base, and you can still sell
enhanced commercial versions if you want.

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

It would be very good, if you could make your living with the ODBC driver.
Just taking charge of fixing bugs is not enough. If you can sell
enhanced versions, you can make bigger improvements and
don't need to worry about money so much. Then the ODBC driver could
stay up to date with newer ODBC standards.

Commercial PostgreSQL users/customers need a good ODBC driver.
They need an ODBC driver with all the features they need.
Some need good performance too.
They need also compliance for new ODBC and SQL standards.
And some new features...

It is very good for commercial PostgreSQL users,
if there are some people, who maintain the ODBC driver commercially.

It gives for the project trust for continuity.

Personally I would like to have a good ODBC driver at home too.
My personal need has been only to experiment with the driver.

I have experimented ODBC performance features.

I am also interested in transaction savepoint support.
I would like to at least have a one-line patch for savepoints,
because it would make savepoints work without open cursors
inside transactions ...

Unfortenately i have no access into books about ODBC standards.
I do know, how they should be implemented to be compatible
with PostgreSQL, but I don't know what kinds of ODBC functions
should be inserted, or what kind of ODBC function mechanism,
like options and what are the standard ODBC error messages would be needed.

If I have time (I have really small amount of time), I might make an
implementation.

Another fix for the current ODBC driver would be to implement proper
charset support for the Linux side: It seems, that the charset changing
support
has been implemented only for Windows.

I have some thoughts about performance enchancements, but I might not
have time to implement them.

Conclusion:

I hope that you make a living with the ODBC driver commercially.
That way the PostgreSQL ODBC driver would evolve to be good enought even
for more demanding ODBC users. If I would make a living with the ODBC
driver, I could implement some of the ideas, but that is not
what I do for living. So I can't implement many of them.

I hope that you can get something like high enough yearly support payments
from very many commercial users to get a steady income.

I have written a bit code for the savepoint support with cursors. Maybe
it will come usable during the summer. I don't try to make it extremely
fast,
it will be unoptimized. I just try to make it featurefull with a very
good structure.
So my benefit will be to strengthen my learning of object oriented C
coding :) .

The object orientation will cause a bit less speed, but the core
savepoint code is
easy to transfer from one ODBC driver into another one.

My personal point is: do good coding, with good enough speed. If you need
more speed, use another algorithm, or try to avoid the processing
alltogether.
This way the object oriented coding is good enough for speed. Another
benefit
about good object oriented coding is, that it is easier to insert a new
working algorithm
without breaking the existing algorithms.

For example, it would be rather easy to abstract out the Windows charset
conversion
functions. After that, it would be easy to insert iconv() support for
the Linux side.
I prefer iconv(), because it is a reentrant function. ANSI C charset
conversion functions
don't seem to be reentrant :( .

Regards,
Marko Ristola

Robert Treat wrote:

>On Thu, 2005-04-28 at 01:09, Joshua D. Drake wrote:
>
>
>>We have customers that don't want to have to make their software GPL
>>compatible. They are willing to pay reasonable fees to not only help us
>>develop a driver for the overall good of the project but also to have
>>certain commercial rights that would not be there if they used the GPL
>>version.
>>
>>
>
>Would they be willing to pay you a reasonable amount for an ODBC driver
>that was bsd licensed? I can't imagine why they wouldn't since this
>would allow them all the commercial rights they need.
>
>
>
>>>What do you see as the business (or community) advantage of this?
>>>
>>>
>>The business advantage is a $ equation that allows someone like
>>Command Prompt to provide continual support for the driver. The ODBC
>>driver (at least for us) doesn't have any secondary revenue streams.
>>Unlike something like plPHP where we can get residual
>>coding dollars from being the definitive experts in plPHP.
>>
>>The ODBC driver is just that, a driver. If it works it doesn't need
>>support except for continued development and bugfixing
>>
>>
>
>And that is your residual income. Every new version of PostgreSQL is
>going to require *some* hacking around the code, and there are bound to
>be some people who would rather pay you (the experts who wrote the code)
>to do this rather than do it on their own.
>.
>
>
>>The community is going to receive a top notch driver, with commercial
>>support behind it that allows the community as a whole to continue to grow.
>>
>>
>>
>
>But you don't have to do these via a dual license scheme. A single
>license scheme where you decide to only fix bugs that you are paid to
>fix has the potential to work. You don't have to spend time on
>maintaining it if you can't make money on it, other people can feel
>comfortable contributing to the code base, and you can still sell
>enhanced commercial versions if you want.
>
>
>Robert Treat
>
>

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/

Greetings Joshua,

* Joshua D. Drake (jd(at)commandprompt(dot)com) wrote:
> 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.

I was wondering (as I imagine a number of others probably are), how's
this coming? My recollection is that there was some hope that
something would be available around the August timeframe (please
correct me if I'm wrong). Did you end up deciding to use libpq
(which, personally, I feel would be the best approach)? Is it to Beta
stages yet?

Many thanks for your work on this.. It'd be really great to have a
solid and maintained ODBC driver though personally I hope you decide
to release it under BSD someday, not because I'm a big fan of BSD or
don't like GPL but because the PostgreSQL 'core' could also get the
benefits of the new driver.

Thanks again,

Stephen