Creating a Win32 Library for GPG?

[Sam Roberts]

From: Frank Tobin <ftobin at uiuc.edu>
> Ryan Erwin, at 11:44 -0700 on Fri, 21 Apr 2000, wrote:
> 
> > That is all very true, but it still doesn't make it the most desirable
> > way for most people to use GPG, especially if they would like to
> > include the capabilities of GPG in another application.
> 
> You should realize that on UNIX, at least, this is pretty much the
> standard way to implement another program's capabilities.  Programs such

So then why doesn't gnupg call gzip instead linking against zlib? ;-)

> as mutt which 'seem' to have integrated GnuPG do fork/exec calls.  Note
> that GnuPG has a rich set of communication handles to use, and a
> well-structured option-parsing mechanism, so you aren't missing out on
> much.

 
> > - Do the licensing terms of GPG allow it to be converted to a
> > LGPL library that could be used by oss and commercial apps?

Absolutely not, it explicitly disallows this.

Any C programmer using gpg though it's co-processing interface
will need to build functions to parse the output of gpg, set up
the pipes, build arg vectors, etc. Any intelligent programmer
would make this a library, and here one is:
 
http://www.nessie.de/mroth/pgg/

However, it itself is under the GPL, meaning you can't link your
non-GPL s/w against it.

gpg itself, of course, is built intelligently, meaning it has
a library like structure inside, with defined interfaces to
the various algorithms, makeing it extensible, and it can
run-time load objects. Unfortuneately, it's not built to be
used outside of the gpg executable. And even if it was, you
couldn't use it because that library would (likely) be GPLed!

However, the fact that gpg does have a co-processing interface
is actually good for you, it's the ONLY way for non-GPL s/w
to use GPL s/w, aside from the dynamic linking grey-area, see
below.

> As far as I know, the GPL does not allow this.  You should read the GPL
> yourself for clarification.  However, you simply call GnuPG through
> fork/exec calls, you can use this technique in non-GPL software.  Also
> note that the FSF, which holds the copyright for GnuPG, seeks to have more
> stuff under the GPL than the LGPL:
> 
> http://www.fsf.org/philosophy/why-not-lgpl.html

Also, http://www.fsf.org/gnu/gnu-history.html, particularly:

 "The ultimate goal is to provide free software to do all of the
  jobs computer users want to do--and thus make proprietary
  software obsolete."


The FSFs goal is the end of commercial s/w. Pragmatically, to gain
some acceptance in a world of mixed commercial and free s/w they
describe "levels" of integration allowed. GPL s/w can only be
statically linked to other GPL s/w. Whether GPL s/w can be
dynamically linked to non-GPL s/w is a matter of interpretation:
Linus says you can dynamically link non-GPL modules into the
GPLed Linux kernel, RMS has stated that he believes this to be
against the GPL, but copyright holders must enforce
their copyright, so its a grey area. However, GPL s/w can
be executed by non-GPL s/w. The mechanism is different, but as
gnupg and the unix pipe/shell programming mechanisms demonstrate,
the end result if the same: use of the capabilites of one piece
of s/w by another. If its built right you don't have to link to
use it.

The LGPL was a strategic move by the FSF to get the gcc compiler
accepted when there were no free operating systems. Without
libc being LGPLed, no one would use gcc. It's also more in-line
with commercial compilers which obviously allow linking against
and redistributing their libraries. The recent push by the FSF
to GPL more libraries instead of LGPLing them is an indication
of the strength and popularity of free s/w, allowing them to push
closer to there stated goals.

Personally, I suspect that were it practical the FSF would start
publishing s/w under a "GNU Private Licence", forbidding linking,
OR executing of a program by non-GPL code, in other words that
will extend the meaning of "integrate" past the concept of linking.

Whether their dream of a commercial s/w free world is really
desireable and really achievable is, of course, highly debatable,
and debated.

Sam