On Sat, 2002-11-23 at 15:14, Steve Langasek wrote: > On Sat, Nov 23, 2002 at 03:34:02PM -0500, Sam Hartman wrote: > > > I'm not sure this is true for the Postgres libraries, because the > > postgres libraries can function fine without ssl support and no ssl > > code is linked into your application. > > > Basically the library linking argument is a functionality argument and > > I think part of the construction may fail in this case. > > I would argue that the only situation where this line of reasoning holds > true is where re-linking the underlying library so that it doesn't > depend on openssl is not objectionable. If it /is/ objectionable, then > clearly there is some value derived from being able to distribute the > application together with the "tainted" version of the library, even if > only in the form of administrative convenience; and I believe it is > therefore the goal of the GPL to prevent distribution of such > combinations in all cases. > > IOW, if it's really such a minor issue, it should be no trouble to > distribute the postgres libs without ssl support and make sure > freeradius doesn't link against an ssl-enabled version at runtime. If > someone balks at doing this, then clearly it wasn't so minor to begin > with, and can't be ignored wrt the GPL. > Just a thought ... how difficult would it be to port the postgres ssl support to link to OpenSSL? Although I am not familiar with the details of the two APIs I would suspect that they are pretty similar and it would alleviate the licensing problem. Best regards, ninewands -- There is no problem that cannot be resolved by the appropriate application of high explosives. Public key available at: http://gnv.us.ks.cryptnet.net/, Key ID: A015B18D, or finger ninewands@ninewands.dyndns.org --
Attachment:
signature.asc
Description: This is a digitally signed message part