FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

On Fri, 27 May 2011 18:16:52 -0400
christos AT zoulas.com (Christos Zoulas) wrote:

> I think that you are on dangerous ground
> by statically linking, because the functionality your gem is
> presenting to the rest of the world, is the functionality provided by
> freetds and nothing more, so you would end up being considered a
> derivative work.

I disagree.  I think it's worth discussing, because anyone contributing
to FreeTDS wants to understand what the LGPL means.  

Whether or not a work is "derived" is independent of how it's linked.

The method of linking changes the technical requirements on the
distributor because the same *effect* -- substituting a different
version of the LGPL library -- requires different procedures.  (Static
linking obviously requires relinking, ergo object code.)  

The LGPL doesn't discuss language-binding adpators, doesn't distinguish
among the kinds of "applications" that might link to a library.  I
don't see how, from a nontechnical point of view, one can distinguish
between providing a new interface for another programming language and
providing a new interface to standard input.  

http://www.schemamania.org/dbstreams/

dbstreams is analogous.  I put it in the public domain because I would
rather see it used than involve the SFLC.  But I would maintain that a
C ++ program linked to dbstreams and using FreeTDS is untouched by the
LGPL.  

I don't see any difference between a Ruby library and a C++ library
other than the language it supports.  ISTM a library supporting
another language is an "application" of the library, not a "derivation"
of it.  

Regards, 

--jkl