Skip to Content.
Sympa Menu

freetds - Re: Time for a new version?

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Steve Langasek <vorlon AT netexpress.net>
  • To: TDS Development Group <freetds AT franklin.metalab.unc.edu>
  • Subject: Re: Time for a new version?
  • Date: Thu, 28 Mar 2002 10:14:42 -0600

On Wed, Mar 27, 2002 at 08:20:11PM -0500, Brian Bruns wrote:

>> Someone should still look at the best way to EINTR when select() is
>> being used -- right now I've added no handling for this. It's easy
>> enough for me to throw in a '&& errno != EINTR' if people agree that
>> won't cause any other problems; I just don't want that to become a "good
>> enough" solution that never gets revisited.

> I wonder if EINTR handling may explain occasional lost connections on some
> busy apache servers that we've heard about.

>>> BTW, I've added a '--with-ssl' option to configure which will compile in
>>> NT authentication support.

>> A note on this (hmm, this topic seems to be coming up everywhere these
>> days) -- because the OpenSSL license is not GPL-compatible (or more to
>> the point, LGPL-compatible), it's not legal for third parties to ship
>> freetds binaries linked against OpenSSL unless all copyright holders in
>> the FreeTDS code agree to adding a license exception allowing this. For
>> Debian, I would definitely rather ship NT auth-enabled binaries; and to
>> that end, I hereby grant permission to licensees under the LGPL to link
>> any code I've contributed to FreeTDS against the OpenSSL library for the
>> purpose of creating redistributable binaries. In case we don't get the
>> same consent from all other contributors, I'll probably start looking at
>> what would need to be changed to use the GNU TLS library instead.

> IANAL! OpenSSL is not GPL compatible, but what about LGPL? Most of the
> clauses seem to deal with redistribution of openssl, and would affect
> staticly linked versions of freetds I suppose. I also don't believe we
> fall under "derived works" either, so that knocks out clause 4. That
> seems to leave clause 3.

After re-reading the LGPL, I see that the definition of 'source code'
used there is not actually as broad as I thought it was, and we may be
ok without an explicit exemption; I apologize if this was a false alarm.
Still, there is at least one case where an exemption is needed, and
that's in order to allow third-parties to take advantage of clause 3 of
the LGPL ("you may opt to apply the terms of the GPL.."). In that case,
clause 3 of the OpenSSL does conflict. It would be nice (though not, I
think, necessary for anything people are doing today) to be able to
incorporate FreeTDS into GPL works without having to worry about this
license conflict.

Steve Langasek
postmodern programmer

Attachment: pgpf8Z4BjUWZV.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page