ODBC component licenses

Steven Schveighoffer schveiguy at yahoo.com
Fri Nov 11 05:01:21 PST 2011

On Thu, 10 Nov 2011 23:25:38 -0500, Steve Teale  
<steve.teale at britseyeview.com> wrote:

> On Thu, 10 Nov 2011 13:54:04 -0500, Steven Schveighoffer wrote:
>> On Thu, 10 Nov 2011 13:36:38 -0500, Jonathan M Davis
>> <jmdavisProg at gmx.com> wrote:
>>> On Thursday, November 10, 2011 10:29 Steven Schveighoffer wrote:
>>>> On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis
>>>> <jmdavisProg at gmx.com>
>>>> wrote:
>>>> > On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:
>>>> >> On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale
>>>> >>
>>>> >> <steve.teale at britseyeview.com> wrote:
>>>> >> > The libraries for unixODBC and for FreeTDS (communication with
>>>> >> > SQL Server) are LGPL.
>>>> >> >
>>>> >> > Would a D ODBC driver that used these be compatible with Phobos?
>>>> >>
>>>> >> glibc, which dmd (and all Linux binaries) rely on is LGPL. So if
>>>> >> you
>>>> are
>>>> >> saying what I think you are saying, yes. As long as the LGPL code
>>>> >> is kept
>>>> >> in a *separate* shared object, it is perfectly legal to link with
>>>> >> it without infecting phobos' license.
>>>> >
>>>> > Though the fact that it needs to be in a separate shared object does
>>>> > make it
>>>> > problematic to stick in Phobos, since Phobos is just one shared
>>>> object.
>>>> > So, if
>>>> > he's looking to put it _in_ Phobos, then I don't think that we can
>>>> > do that
>>>> > with the current setup.
>>>> My understanding is that the FreeTDS is its *own* shared object
>>>> (installed
>>>> separately). We cannot include LGPL code in phobos.lib.
>>> I'm afraid that I've never even heard of TDS, so I'm not quite sure how
>>> that
>>> relates. We theoretically _could_ provide LGPL code in a separate
>>> library, but
>>> we don't do anything like that now.
>> I wasn't sure so I looked it up:
>> http://www.freetds.org/faq.html#where.is.libtds.so
>> Apparently, you can still have LGPL code that is statically linked?  I'm
>> not sure now how that works, my understanding was always that LGPL works
>> because of shared objects.
>> -Steve
> I've just done my first thing in the morning thing again with Pan and
> deleted one of your postings in the thread.

opera :)

You can always use webnews to look for posts that you accidentally deleted:


Or use the archive (from digitalmars.com website), but this seems to lag  
the actual posts by some period of time.

> So lots of things can't be included in Phobos because it is one big
> static library, right?

I don't know.  When I said I'm not sure, it wasn't a euphemism for  
thinking it wouldn't work, I literally am not sure.  Maybe it can be done,  
but the licensing issues have to be worked out, even if it doesn't taint  
the rest of phobos.

Clearly if someone is to ship a program which uses libfreetds.a, they  
would need to provide source code for the library.  Is this something we  
want to require users of phobos + SQL server to do?  I don't know.

I'm just very surprised they use static libs (and it looks from that post  
like a recent change).

> If you don't include some Phobos module in your app, the linker still
> wants to pull in the unsatisfied externals for that module even though
> they will not be used?

There are some technical issues.  For example, if phobos depends on a  
library, then that library has to come *after* phobos.  In a recent update  
to ubuntu, the link order became very important, and it broke all dmd  
versions that had std.datetime, because it requires the librt.so library.   
Therefore the link line had to be -lphobos -lrt in that order.  However,  
dmd *always* tacks on -lphobos at the end of the link line, regardless of  
what is in configuration or command line.  However, certain libraries  
phobos depends on are added after -lphobos, such as -lm and -lpthread.   
Walter fixed the problem for 2.056 by tacking on -lrt as well.  This  
solution could *not* be used for freetds because it's not a default  
install in any modern OS (seeing as how it's a static lib, it would only  
be installed if you were interested in developing with it).

Even though the linker will probably ignore the lib if you don't use any  
symbols from it, I don't think it will work if it can't *find* the lib.

However, if phobos' database API is an extendable *framework*, then one  
could define 3rd party libs that add non-compatible licensed code to be  
used when needed.  It's far from an ideal situation, but licensing is a  
real issue that must be worked around.

I'll add that I am not a lawyer and I'm not 100% positive of the path we  
need to take.

> If that's not the case, then having D able to easily generate DLLs and
> shared libraries would seem to be priority number one.

I have felt this for a long time.  As long as dmd cannot easily generate  
native DLLs, it will be a toy language.

> Clearly we don't have any philosophical objection to using external
> libraries from Phobos - std.socket points out that you have to link with
> the Windows sockets library. Or is that one of the old libraries that
> Microsoft lets Walter use?

First, that is an OS-provided library that is not GPL'd or LGPL'd.  You  
are free to use it in whatever code you wish, and it is *always* installed  
on every windows OS (starting with windows 98 I think?)

Second, you may be confused by the linking process on Windows.  WS2_32.lib  
is *not* a static library, it's a linker file.  In windows, you need this  
linker file in order to link against a DLL.


More information about the Digitalmars-d mailing list