RE: [HACKERS] ODBC & LGPL license...

> > > ObCaveat:  I'm not a lawyer.  I don't look like a lawyer, I don't smell like a
> > > lawyer, and I don't lie like a lawyer.
> > >
> > >
> > My understanding is pretty much the same. Originally there was only GPL. This
> > really says that anything you link with GPL code must be distributed under
> > GPL - effectively your source becomes part of the original GPL'd product.
> >
> > Clearly this is ridiculous when you are linking against, say, the GNU
> > C-library, so Stallman introduced LGPL which effectively says that any
> > modifications or additions you make to the library fall under the LGPL,
> > but anything which calls the LGPL'd library can have whatever copyright
> > you want. Thus it is possible to produce commercial products which use
> > the GNU C-library, etc., etc.
>
>     Okay, then going back to the original...the PostODBC drivers that
> I'd like to include as part of the src/interfaces directory falls under
> LGPL...if we did include it, then we wouldn't/shouldn't be contaminating
> the source tree in any way?
>
>
>
I'm sure that's OK. Just been reading the LGPL again. Here are some salient
paragraphs with comments:



!!! From the Preamble:
The reason we have a separate public license for some libraries is that they blur the distinction we
usually make between modifying or adding to a program and simply using it. Linking a program
with a library, without changing the library, is in some sense simply using the library, and is
analogous to running a utility program or application program. However, in a textual and legal
sense, the linked executable is a combined work, a derivative of the original library, and the
ordinary General Public License treats it as such.

Because of this blurred distinction, using the ordinary General Public License for libraries did not
effectively promote software sharing, because most developers did not use the libraries. We
concluded that weaker conditions might promote sharing better.

However, unrestricted linking of non-free programs would deprive the users of those programs of
all benefit from the free status of the libraries themselves. This Library General Public License is
intended to permit developers of non-free programs to use free libraries, while preserving your
freedom as a user of such programs to change the free libraries that are incorporated in them. (We
have not seen how to achieve this as regards changes in header files, but we have achieved it as
regards changes in the actual functions of the Library.) The hope is that this will lead to faster
development of free libraries.




For "non-free programs" one should really read "programs not distributed
under the GPL".

Here is the critical part from Section 2 of the LGPL:




!!! From Section 2:
These requirements apply to the modified work as a whole. If identifiable sections of that work are
not derived from the Library, and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those sections when you distribute
them as separate works. But when you distribute the same sections as part of a whole which is a
work based on the Library, the distribution of the whole must be on the terms of this License,
whose permissions for other licensees extend to the entire whole, and thus to each and every part
regardless of who wrote it.

Thus, it is not the intent of this section to claim rights or contest your rights to work written
entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or
collective works based on the Library.

In addition, mere aggregation of another work not based on the Library with the Library (or with a
work based on the Library) on a volume of a storage or distribution medium does not bring the
other work under the scope of this License.





It really relies upon the distinction between what is "the library" and what is a
"separate work" (i.e. PostgreSQL) which happens to make use of the library.

But what really applies to us is Section 5:




!!! From Section 5:
5. A program that contains no derivative of any portion of the Library, but is designed to work
with the Library by being compiled or linked with it, is called a "work that uses the Library". Such
a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of
this License.





i.e. the PostgreSQL source remains under our copyright.
But then:




!!! From Section 5:
However, linking a "work that uses the Library" with the Library creates an executable that is a
derivative of the Library (because it contains portions of the Library), rather than a "work that uses
the library". The executable is therefore covered by this License. Section 6 states terms for
distribution of such executables.





We don't normally distribute executables, so that's not a problem.
In any case, this is simply a legal definition since, as Section 6
states:




!!! From Section 6:
6. As an exception to the Sections above, you may also compile or link a "work that uses the
Library" with the Library to produce a work containing portions of the Library, and distribute that
work under terms of your choice, provided that the terms permit modification of the work for the
customer's own use and reverse engineering for debugging such modifications.




We allow all that, so it's not a problem (though this would appear to
restrict commercial products which are certainly available!). I guess,
however, that these are linked to use shared libraries.

However, this section then appears to contradict itself as it then says:




!!! From Section 6:
...Also, you must do one of these things:
  a) Accompany the work with the complete corresponding machine-readable source code for
     the Library including whatever changes were used in the work (which must be distributed
     under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with
     the complete machine-readable "work that uses the Library", as object code and/or source
     code, so that the user can modify the Library and then relink to produce a modified
     executable containing the modified Library. (It is understood that the user who changes the
     contents of definitions files in the Library will not necessarily be able to recompile the
     application to use the modified definitions.)





Here, you only need to supply the object code such that you can
modify *the library* not the "work that uses the Library" whereas
the first part of Section 6 implies that you must be able to
modify the "work that uses the Library". Commercial offerings
clearly rely on this being the clause they follow. By linking
with an LGPL'd library dynamically, they also don't need to
supply object code as you are fulfilling the requirement that
you can link with a modified version of the library.



In summary (remembering that I am not a lawyer), it appears that
the LGPL certainly does not "pollute" our code, but to use an LGPL
library we need to satisfy certain conditions concerning distribution.
Since the licence which we give is even more free than LGPL and
we do satisfy all these requirements, it really is not a problem.

The only restriction I can see if for third parties who wish to
use PostgreSQL for some commercial product which they then wish
to sell. They must satisfy the requirements of the LGPL when they
sell that product if they link PostgreSQL with the LGPL'd library.
Thus having a compile time option to include (or not) the LGPL'd
ODBC stuff would seem like a sensible option.


If the ODBC stuff is simply a stand-alone library (which uses the
PostgreSQL libraries) rather than being linked into PostgreSQL
itself, then there really is no problem whatsoever, as this would
then be a simple aggregation of work. From Section 2:

In addition, mere aggregation of another work not based on the Library with the Library (or with a
work based on the Library) on a volume of a storage or distribution medium does not bring the
other work under the scope of this License.



Andrew

----------------------------------------------------------------------------
Dr. Andrew C.R. Martin                             University College London
EMAIL: (Work) martin@biochem.ucl.ac.uk    (Home) andrew@stagleys.demon.co.uk
URL:   http://www.biochem.ucl.ac.uk/~martin
Tel:   (Work) +44(0)171 419 3890                    (Home) +44(0)1372 275775