Thread: 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@candle.pha.pa.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@candle.pha.pa.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@candle.pha.pa.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@candle.pha.pa.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@hub.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@hub.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@postgresql.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@candle.pha.pa.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@candle.pha.pa.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@candle.pha.pa.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@candle.pha.pa.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@candle.pha.pa.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.
Mark, ISTR you putting your hand up not long ago, proposing to do some work on the current driver. Have you managed to get to that, or if not, is there any prospect of it? As a general comment on this to-my-eyes-excessively-overwrought discussion: my perception is that the existing driver works pretty will for 99% of users, albeit with workarounds necessary for some kinds of functionality. The main problem is the lack of a maintainer. And yes, the code could benefit from rewriting in some places. But I wonder whether the problem is as bad as the discussion suggests. --- markw@mohawksoft.com wrote: > > 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. > > > ---------------------------(end of > broadcast)--------------------------- > TIP 8: explain analyze is your friend > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
> 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
> -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Jeff Eckermann > Sent: 28 April 2005 15:08 > To: markw@mohawksoft.com; Joshua D. Drake > Cc: pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Official ODBC announcement > > As a general comment on this > to-my-eyes-excessively-overwrought discussion: my > perception is that the existing driver works pretty > will for 99% of users, albeit with workarounds > necessary for some kinds of functionality. The main > problem is the lack of a maintainer. A new maintainer is being umm, broken in at the moment :-) Regards, Dave
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@noao.edu The gods that smiled on your birth are now laughing out loud.
* Joshua D. Drake (jd@commandprompt.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
Attachment
> > 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@noao.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@commandprompt.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
Attachment
> -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Stephen Frost > Sent: 28 April 2005 16:26 > To: Joshua D. Drake > Cc: pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Official ODBC announcement > > 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. I am not a lawyer, but... Essentially you're correct IMO - ODBC apps do not link against the driver itself, thus there is no closed/open source GPL issue. That only comes into play if you use a GPL *driver manager* (both iODBC and unixODBC are LGPL anyway, so that should be a non-issue as well). On a Windows system the worst that would happen is that you would distribute your application and get the users to download the driver themselves, just to be safe. Regards, Dave
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@noao.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@commandprompt.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