ODBC component licenses

[Jonathan M Davis]

On Thursday, November 10, 2011 13:49 Steven Schveighoffer wrote:
> On Thu, 10 Nov 2011 16:06:56 -0500, Andrei Alexandrescu
> 
> <SeeWebsiteForEmail at erdani.org> wrote:
> > On 11/10/11 1:50 PM, Dejan Lekic wrote:
> >> On 10/11/11 05:55, Steve Teale 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?
> >>> 
> >>> Steve
> >> 
> >> I would strongly advice any DB driver go into a separate library instead
> >> of Phobos. Too many unneeded modules are in Phobos already and more
> >> modules that do not belong in Phobos are about to be accepted...
> > 
> > I thought the main concern was that there's too little stuff in Phobos,
> > and that growth is good. Seems like whatever we do we won't please
> > everyone.
> 
> Well, one concern I would have is making *phobos* dependent on these
> libraries, which may not be needed (or installed).
> 
> Note that in recent times, dmd failed to compile any programs Ubuntu
> because of new linking rules. The solution was to add -lrt to the dmd
> source code that generates the link line.
> 
> Is that the same solution for FreeTDS? What if FreeTDS isn't installed
> (it typically is not)? What if you don't use the database system, why
> should you have to link against FreeTDS if it's not being used?
> 
> I'd much rather have the database subsystem *framework* be a part of
> phobos, and the actual implementations be defined as 3rd party libs. Just
> from a practical point of view.

Yeah. Adding functionality to Phobos which is pure D is generally a good thing 
(though stuff which really isn't generally useful obviously shouldn't be in 
there). But adding stuff that requires additional dependencies is far more 
iffy. If the module is really self-contained and you can get away with using 
Phobos without linking in the library that it needs as long as you don't use 
it, then it's not necessarily a big deal. But if it's going to require that 
everyone using Phobos link it in and it's not standard on all systems, then it 
needs a really solid reason for being in Phobos. And if we get in a situation 
where we need to add extra linking commands to dmd itself (as we had to with 
librt) for each such library, then that becomes undesirable very quickly IMHO.

And given the licensing issues that we're seeing with the DB stuff, that lends 
even more credence to the idea of just having them all as separate modules 
with just the framework being in Phobos. It would be nice to have them in 
Phobos, but if we're going to have licensing problems and/or dependency 
problems because it, then they shouldn't be in Phobos proper.

- Jonathan M Davis