Skip to Content.
Sympa Menu

freetds - Re: [freetds] License Question

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: mew_alig <mewalig AT gmail.com>
  • To: freetds AT lists.ibiblio.org
  • Subject: Re: [freetds] License Question
  • Date: Sat, 1 Aug 2015 17:25:32 +0000 (UTC)

James K. Lowden <jklowden <at> freetds.org> writes:

>
> 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
>


I know this thread is a few years old so please forgive me
if I'm beating a dead horse. I suppose these questions are
more about LGPL in general, but would appreciate any thoughts
given that the specific LGPL-covered software that we are
concerned about is FreeTDS.

I am involved in a closed-source commercial project which
includes some functionality to connect to and interact with a
SQL server database. Below are the distribution choices we are
considering. Are #1, #2 and/or #3 allowable under the FreeTDS
license terms, assuming that a) all required notices are provided,
b) no source or object code is made available to the client, other
than that of FreeTDS, and c) FreeTDS is incorporated into the end
solution either by one of our executables making a system call to
execute a FreeTDS executable (such as freebcp), or by calling a
function that is available via dynamically linking to the FreeTDS
library.

1. Provide client with a physical box that provides services over the
network. Client has no access to files of any sort inside the box.
The box ships with various object code including the FreeTDS
executable(s) and/or dynamically-linked libraries that are used by
some of our commercial, closed-source executables.

2. Provide client with means to install software on its own computers.
This is the same as #1 except that now, the client owns the physical
box that holds the files, and has access to those files (including
FreeTDS executables and/or DLLs that are bundled with installation).

3. Same as #2 except that we do not ship with any FreeTDS
executables or libraries. Instead, client must install FreeTDS
components on their own.

4. Same as #3 except that instead of client installing FreeTDS,
client installs the Microsoft SQL Server tools.

Thanks in advance for your help





Archive powered by MHonArc 2.6.24.

Top of Page