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: Mon, 3 Aug 2015 16:00:16 +0000 (UTC)

Frediano Ziglio <freddy77 <at> gmail.com> writes:

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

Thank you. The OS's for options 1, 2, 3, and 4 would be, respectively:
1. OSX (10.10+) or Linux (not sure which, but a stable release from 2013
or later)
2, 3, and 4: Windows 7.

So just to be crystal clear, am I right in saying that it is your
understanding
(with the caveat that you're not giving me legal advice and I need to get my
own lawyer to do that) that if I never static link (and always dynamic link),
and I include the proper notice provisions related to FreeTDS's license, then
under options 1 or 2 (as well as 3), I am not obligated to disclose any of my
company's proprietary source code or object code (other than executable
binaries)?

Again-- sorry to beat this one so much but staying within the bounds of the
licensing while keeping our code closed-source is extremely important to us
and is the only way we would be able to use (and in doing so, potentially
contribute to) FreeTDS.





Archive powered by MHonArc 2.6.24.

Top of Page