Better proxy support available via libcurl?

[Marcus Brinkmann]

At Wed, 2 Aug 2006 15:08:08 -0400,
David Shaw wrote:
> 
> On Wed, Aug 02, 2006 at 07:32:10PM +0200, Werner Koch wrote:
> > On Wed,  2 Aug 2006 14:17, David Shaw said:
> 
> > > OpenSSL libcurl, and even then the restriction depends on whether
> > > OpenSSL is considered part of the OS or not.
> > 
> > OpenSSL is clearly not part of the OS (at least for almost all
> > GNU/Linux systems).
> 
> I don't know that this is true.  Different people hold different
> opinions about this.  Clearly Debian has made a statement that they do
> not consider OpenSSL part of the OS, but there are other cases that
> are not as clear cut.  My point is not to argue whether OpenSSL can be
> part of the OS or not.  My point is that I don't think we in the GPG
> world get a vote on this: it's not our OS and so not our decision to
> make.

I have two things to say about this.  The first thing is that it is
not up to the distro maintainers alone, but also to the copyright
holder of the software, in this case the FSF.  As we are talking about
legal matters, in a disputed case the final ruling that settles the
matter would come from a court (if no agreement can be reached).  But
a court will always consider actual practice and intent of involved
parties.  If the intent of the copyright holder is clearly to apply
this exception to proprietary systems only, and the intent of distro
builders is to circumvent the restrictions in the GPL, then I think it
is a likely outcome that the court will rule against applicability of
this exception.  So, the publicly documented opinion of the FSF does
matter.

Second, this exception you are citing is overused.  If some distros
are trying to apply it, they are abusing it.  The historical context
of this exception is running GNU tools on proprietary operating
systems, where you have to link the program against some of the
vendor's proprietary system libraries.  The distros can not use the
exception, because they are shipping openssl as well as gnupg, thus
"the component [openssl] itself accompanies the executable."  This
alone settles the matter.  It would be very difficult for a free
software distribution to separate openssl from gnupg in a way to
successfully argue that openssl accompanies the major parts of the
operating system, but gnupg does not.  As a minimum, such a
distribution would have to cease to distribute gnupg binaries linked
against openssl (ie, the BSD ports setup may actually work out fine in
this case).

There are a number of solutions to this problem, including adding an
exception for openssl, which you have mentioned in your other mail.
Another is to get openssl relicensed under a GPL-compatible free
software license[1].  Or distros can do the extra work to avoid linking
GPL software against GPL.  I do not have any strong opinions in either
of these directions, but of course it is not up to me anyway.

Thanks,
Marcus

[1] This has happened before with other projects licensed under
BSD-style + advertisement clause terms.