Skip to Content.
Sympa Menu

freetds - Re: [freetds] License Question

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddy77 AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] License Question
  • Date: Sat, 1 Aug 2015 18:57:32 +0100

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




Archive powered by MHonArc 2.6.24.

Top of Page