FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2015-08-03 17:00 GMT+01:00 mew_alig <mewalig AT gmail.com>:
> 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)?
>

Yes, these are the common rules. Is not really LGPL == dynamic linking
actually you could use even static one but this require some technical
way as LGPL require customer to be able to change the LGPL part.
Putting into a dynamic library make much easier to do it. If you just
use code as is you can safely say to customer "Go on their website and
use version X".

Is always better to ask to lawyer. A license (closed or open) is a
contract between you and who provided it but is bound to laws which
depends on country and other factors.

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

Well.. this is why we (well, I should actually say they) decided to
use LGPL. We all want to have big interoperability with both closed
and open world! Helps others and us.

Regards,
   Frediano