FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

Il 01/Ago/2015 18:48, "mew_alig" <mewalig AT gmail.com> ha scritto:
>
> 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
>

I don't see many problems. Unless you static link FreeTDS (which is
possible but in this case you need customer to change the lgpl code of your
executable... that is provide a blob for the rest of code and source for
freetds) I don't see the problem. You can use the tsql output as you like,
just you need to provide sources if client request them. I think a link at
the version you used if you don't change sources.

You didn't specify which OS and platform is using your system.

Frediano