Nathaniel McCallum wrote:
> Does this also mean that you need to statically link to *both* libcurl
> and libproxy? Because you could still do a static link to libcurl and
> a dynamic link to libproxy.

Our app has a policy of linking statically with third-party libraries
(not system libs, just mostly open source libs like libcurl, zlib, pcre,
etc.). Thus we couldn't, or at least wouldn't, link dynamically to
libproxy - if it's linked at all it has to be static. Of course it could
be configured out (--without-libproxy) but if that resulted in losing
the basic proxy support which is currently built into libcurl it would
be, again, bad.

It sounds like the design is that libproxy itself is just a thin
framework and most of the value added is in the plugins. If so, the best
model might be for the framework to have the least restrictive license
possible and let the plugins decide their own terms.

Anyway, this is something of a sidetrack from the main issues. Just a
data point.

MB
Received on 2007-12-22