Skip to Content.
Sympa Menu

freetds - Re: [freetds] License Question

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] License Question
  • Date: Sat, 28 May 2011 15:13:18 -0400

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




Archive powered by MHonArc 2.6.24.

Top of Page