Hello,

I wrote a proprietary MS-Windows application (I can
just hear the groans... sorry) that I hope to sell. It
uses a backend database, and I like the option of
using PostgreSQL for that. I need to know clearly what
I need to do to distribute the psqlODBC driver with my
app.

My work is not a derivative work and the binary is not
linked to any psqlODBC library. It can, in fact,
connect to any ANSI-SQL compliant transactional
database using ODBC. I would, however, like to support
PostgreSQL over MS-SQL Server, and, to that end, would
like to bundle PostgreSQL and the psqlODBC dll with my
app. I will charge nothing for the driver or the
database.

I read the GNU Lesser General Public License and don't
see anything that prohibits this, but I'm a developer
and not a lawyer, so I'd like to ask for some advice.

Thanks,
Jim Brown


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Jim Brown wrote:
> Hello,
>
> I wrote a proprietary MS-Windows application (I can
> just hear the groans... sorry) that I hope to sell. It
> uses a backend database, and I like the option of
> using PostgreSQL for that. I need to know clearly what
> I need to do to distribute the psqlODBC driver with my
> app.

Nothing. Unless you change the driver. If you don't change
the driver you may include the psqlODBC driver in your closed
source application.

Sincerely,

Joshua D. Drake


>
> My work is not a derivative work and the binary is not
> linked to any psqlODBC library. It can, in fact,
> connect to any ANSI-SQL compliant transactional
> database using ODBC. I would, however, like to support
> PostgreSQL over MS-SQL Server, and, to that end, would
> like to bundle PostgreSQL and the psqlODBC dll with my
> app. I will charge nothing for the driver or the
> database.
>
> I read the GNU Lesser General Public License and don't
> see anything that prohibits this, but I'm a developer
> and not a lawyer, so I'd like to ask for some advice.
>
> Thanks,
> Jim Brown
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Jim Brown <jimbrown32rb@yahoo.com> writes:
> I wrote a proprietary MS-Windows application (I can
> just hear the groans... sorry) that I hope to sell. It
> uses a backend database, and I like the option of
> using PostgreSQL for that. I need to know clearly what
> I need to do to distribute the psqlODBC driver with my
> app.

I'm not a lawyer either, but my reading of the LGPL says that you
can distribute an LGPL library along with a proprietary application
that uses the library so long as you

(1) include the source code of the library (or offer to provide it
on request, but if you're sending out CDs you might as well just
put the source code on to begin with).

(2) provide the proprietary app in a form that can be re-linked with
a user-modified version of the library, ie, .o files or equivalent.

Basically what the LGPL is saying is that someone should be able to
change the source code of the library and still use it with your app.

(1) is certainly no skin off your nose except for a few more MB on
the distribution media. (2) might annoy you, especially if you have
illusions of being able to prevent reverse-engineering of your
executables. My impression of common practice is that no one actually
pays much attention to requirement (2), but it's there in black and white
in the LGPL text. If you want to keep yourself perfectly clean and
aboveboard you should honor it.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Tom Lane wrote:
> Jim Brown <jimbrown32rb@yahoo.com> writes:
>> I wrote a proprietary MS-Windows application (I can
>> just hear the groans... sorry) that I hope to sell. It
>> uses a backend database, and I like the option of
>> using PostgreSQL for that. I need to know clearly what
>> I need to do to distribute the psqlODBC driver with my
>> app.
>
> I'm not a lawyer either, but my reading of the LGPL says that you
> can distribute an LGPL library along with a proprietary application
> that uses the library so long as you
>
> (1) include the source code of the library (or offer to provide it
> on request, but if you're sending out CDs you might as well just
> put the source code on to begin with).
>
> (2) provide the proprietary app in a form that can be re-linked with
> a user-modified version of the library, ie, .o files or equivalent.
>
> Basically what the LGPL is saying is that someone should be able to
> change the source code of the library and still use it with your app.
>
> (1) is certainly no skin off your nose except for a few more MB on
> the distribution media. (2) might annoy you, especially if you have
> illusions of being able to prevent reverse-engineering of your
> executables. My impression of common practice is that no one actually
> pays much attention to requirement (2), but it's there in black and white
> in the LGPL text. If you want to keep yourself perfectly clean and
> aboveboard you should honor it.

Fortunately ODBC drivers are decoupled from the actual programs that use
them by a standard interface. If I am correct then this implies that (2)
is always met for psqlODBC.

Cheers,
Bart

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Bart Samwel <bart@samwel.tk> writes:
> Fortunately ODBC drivers are decoupled from the actual programs that use
> them by a standard interface. If I am correct then this implies that (2)
> is always met for psqlODBC.

Yeah. I think actually (2) is met for any ordinary shared library;
it's only if you want to static-link an LGPL library that it becomes
an issue. The LGPL was drafted before dynamic linking became the norm,
and so it doesn't really mention the point.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: 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

> Bart Samwel <bart@samwel.tk> writes:
>> Fortunately ODBC drivers are decoupled from the actual programs that use
>> them by a standard interface. If I am correct then this implies that (2)
>> is always met for psqlODBC.
>
> Yeah. I think actually (2) is met for any ordinary shared library;
> it's only if you want to static-link an LGPL library that it becomes
> an issue. The LGPL was drafted before dynamic linking became the norm,
> and so it doesn't really mention the point.

If I understand the supporting documents to the GPL, I think you are
mistaken. The GPL defines a derived work as within the same process space,
so, RMS by defining "derived work" within the context of GPL has also
extended what the GPL is intended to cover. Static or dynamic linking
doesn't make a difference, the code is intimately linked when the program
is run.

The only way to avoid touching GPL is a call gate or TCP/IP type
mechanism. That's why all libraries should be LGPL.



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

First, I want to thank all who replied to my question.
Next, I'd like to state that I recognize what a
fantastic opportunity it is to be able to use the hard
work of the Free Software community in my app. I will
dedicate a page on my company's web site to
acknowledge this community and to expand awareness of
it.

Responding to Mark's point, my app is a self-contained
executable that was coded to a standard interface, and
can be dynamically connected to any ANSI-SQL compliant
ODBC driver. It cannot be considered a derivative work
of any particular library in any sense. It can link to
any library that implements the interface. Mark, I
think that your argument would apply if I had somehow
coded to a particular library and my app would not
function without that particular library. I can see
how, in that case, dynamic linking would not be
materially different from static linking, and my work
would certainly be derivative. I believe that is the
point you took up with Bart’s reply. But that is not
the case here. A user could use any ANSI-SQL compliant
ODBC driver. Again, I coded to a standard interface.

But I do want to provide a copy of plsqlodbc.dll in my
installation program as a default driver, so I'm
interested in what is required to provide that copy. I
assert no rights to the driver, I do not charge any
fee for it, and I made no modifications to it (I never
even downloaded the source code).

Thank you all again for your insights and the time you
took to reply. It is greatly appreciated.

Best regards,
Jim Brown


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

---------------------------(end of broadcast)---------------------------
TIP 1: 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

Jim Brown <jimbrown32rb@yahoo.com> writes:

> Responding to Mark's point, my app is a self-contained
> executable that was coded to a standard interface, and
> can be dynamically connected to any ANSI-SQL compliant
> ODBC driver. It cannot be considered a derivative work
> of any particular library in any sense. It can link to
> any library that implements the interface. Mark, I
> think that your argument would apply if I had somehow
> coded to a particular library and my app would not
> function without that particular library.

Agreed. That could be different if one can demonstrate that your
application cannot work with any other DB than postgreSQL.


> But I do want to provide a copy of plsqlodbc.dll in my
> installation program as a default driver, so I'm
> interested in what is required to provide that copy.

For obvious practical reasons, almost all free software pieces do not
care about what sits next to them on the same CD, same network
directory, same USB key or whatever; it's a surprinsingly common
misconception. Since ages magazines have been selling CDs
bundling/mixing software pieces with all different kinds of licences
(free and not) without any legal issue. Serious people have more
important stuff to care than to check if you are shipping one
proprietary CD + one free software CD versus only one DVD bundling the
two.

The only thing that really matters is linking. Non-technical people
may be diverted to the irrelevant distribution bundling issue because
it is easier to understand and closer to what happens with material
goods.

That does not mean you can distribute any piece of free software in
any way you like; it just means that bundling with or without your
proprietary software is irrelevant.



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

> Jim Brown <jimbrown32rb@yahoo.com> writes:
>
>> Responding to Mark's point, my app is a self-contained
>> executable that was coded to a standard interface, and
>> can be dynamically connected to any ANSI-SQL compliant
>> ODBC driver. It cannot be considered a derivative work
>> of any particular library in any sense. It can link to
>> any library that implements the interface. Mark, I
>> think that your argument would apply if I had somehow
>> coded to a particular library and my app would not
>> function without that particular library.
>
> Agreed. That could be different if one can demonstrate that your
> application cannot work with any other DB than postgreSQL.

No, not really important. Regardless, the definition of "derived" product,
as used in the GPL is publically known and that standard would be used in
court.

>
>
>> But I do want to provide a copy of plsqlodbc.dll in my
>> installation program as a default driver, so I'm
>> interested in what is required to provide that copy.
>
> For obvious practical reasons, almost all free software pieces do not
> care about what sits next to them on the same CD, same network
> directory, same USB key or whatever; it's a surprinsingly common
> misconception.

In the GPL, "mere aggregation" is clearly set out as non-infringing.

> Since ages magazines have been selling CDs
> bundling/mixing software pieces with all different kinds of licences
> (free and not) without any legal issue. Serious people have more
> important stuff to care than to check if you are shipping one
> proprietary CD + one free software CD versus only one DVD bundling the
> two.
>
> The only thing that really matters is linking. Non-technical people
> may be diverted to the irrelevant distribution bundling issue because
> it is easier to understand and closer to what happens with material
> goods.

Linking or incorporation.

>
> That does not mean you can distribute any piece of free software in
> any way you like; it just means that bundling with or without your
> proprietary software is irrelevant.

usually, but check out
http://www.gnu.org/licenses/gpl-faq.html
"Can I apply the GPL when writing a plug-in for a non-free program?"

"If the program uses fork and exec to invoke plug-ins, then the plug-ins
are separate programs, so the license for the main program makes no
requirements for them. So you can use the GPL for a plug-in, and there are
no special requirements."

"If the program dynamically links plug-ins, and they make function calls
to each other and share data structures, we believe they form a single
program, which must be treated as an extension of both the main program
and the plug-ins. This means that combination of the GPL-covered plug-in
with the non-free main program would violate the GPL. However, you can
resolve that legal problem by adding an exception to your plug-in's
license, giving permission to link it with the non-free main program."


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org