Re: License Question
Frediano Ziglio <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <CAHt6W4d9yXoLMpOZ40ret8Q1pEAZ_a1Cpxexh3QtpKAtWYFjQw@mail.gmail.com> |
Il 01/Ago/2015 18:48, "mew_alig" <[email protected]> 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