Обсуждение: Library General Public Licence
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
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 >
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
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
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
> 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.
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 Barts 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
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.
> 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."