On 04/25/2013 12:57 PM, Justin Cormack wrote:
>
>
> On 25 Apr 2013 17:52, "Zvi Gilboa" <zg7s@eservices.virginia.edu 
> <mailto:zg7s@eservices.virginia.edu>> wrote:
> >
> > On 04/25/2013 08:51 AM, Rich Felker wrote:
> >>
> >> On Thu, Apr 25, 2013 at 07:44:39AM -0400, LM wrote:
> >>>
> >>> incompatible licenses.  The openssl library can't be used with a GNU
> >>> program unless there's a waiver for it because one of the clauses 
> in the
> >>> openssl license goes against the GNU license principles.  The gnutls
> >>
> >> Not _used_ but _distributed_. The GPL does not restrict use
> >> whatsoever (and takes the position that it legally can't do so) so
> >> it's fine to use OpenSSL with GPL programs as long as you don't
> >> distribute the resulting binary. This is of course a problem for
> >> package maintainers/distributions, and distributing both openssl and
> >> the GNU program and a script to link them together might even be seen
> >> as an infringing activity.
> >
> >
> > What about explicitly loading the library at run-time using 
> uselib(2) in a plug-in like fashion?  Is that also considered 
> problematic from a GNU perspective?
>
> There is some disagreement about this and it depends what you 
> distribute. See here 
> http://lwn.net/SubscriberLink/548216/731f7ad0abe52f40/
>
> Justin
>

Thank you for pointing to this excellent article.  I initially 
considered the plug-in-like case easier to assess -- specifically since 
the loaded library will never be listed as one of the loading object's 
dependencies -- yet with notions such as interdependency and 
"collectivity," one can never be on safe ground when loading a GPL'ed 
library from within a differently-licensed program, open-source or not.  
Ironically, much of the current thread is about the need to create 
alternatives to commonly-used GPL'ed libraries, which in itself reminds 
of past (and present) efforts to create open source alternatives to 
proprietary libraries and software products.

Zvi