Creating a Win32 Library for GPG?

[Sam Roberts]

I have to apologize, this isn't actually the discussion
I wanted to provoke on gpg-devel, sorry. I was just pointing
out, because it was apropros to the original poster who
wanted to use gpg under windows from his program, that what
constitutes a piece of s/w being integrated with GPL-type
code, and thus subject to the GPL, is a continuum. This
continuum flows from mixing the source code in, compiling
as a library and linking, shared libraries, dynamic
libraries, CORBA/COM in-process, corba/com out-of-process,
remote procedure call, pipe-based co-processing, tcp
based, etc...

The FSF wants an end to "proprietary" s/w (I used the term
"commercial", a follow-up contested that this "proprietary"
!= "commercial", and...), which guides their decision making
on how they structure their licences, and why they recommend
not using the LGPL anymore. It's a strategic thing, and
it's relevant to gpg-devel only in as much as gnupg is GPLed,
and people want to integrate it's capabilities into their
(non-GPL) apps.

Anyhow, sorry for the wasted bandwidth.

--

As far as libraries go, however, gpg's pipe interface is
definitely general purpose, the gpg executable should
definitely have it, it's great for shell programming,
has a number of other benefits, but in no way is it
the only "unix way". Many useful
unix programs (like zip, gzip and bzip2) are built
as a library, which the executable then uses. It is
handy in that it allows closer to trivial use by C
programmers. With pipes, sloshing the data around may be
easy, but you also need to build a parser for gpg output.

Also note that the pipe interface is either not complete,
or painful enough that mutt, at least, grabbed pieces
of the gpg code so that it can directly access some gpg
data structures without using the pipe interface. This code
was *copied*, not linked as it would have been had gpg been
a library. There are some pluses to the pipe interface
and some negatives, and right now there's no choice.

My interest in this is I'm writing a (LGPL) library in C++
to construct, parse, and manipulate RFC822 and MIME messsages,
including (hopefully) multipart/encrypted|signed. I
want to use gnupg, it being the best and most complete tool
around, but I had to port it to my platform-of-choice first.

I'm going to have to build a library that drives it
first, though, a step I wish I could avoid. Maybe I'll just 
try and use Privacy Guard Glue for the first shot, even
though it's GPLed, and distribute some parts as a seperate
library. Yuck.

Cheers!
Sam

--
Sam Roberts, sam at cogent dot ca, www.cogent.ca


----- Original Message ----- 
From: Russ Allbery <rra@stanford.edu>
To: <gnupg-devel@gnupg.org>
Sent: Tuesday, April 25, 2000 8:29 PM
Subject: Re: Creating a Win32 Library for GPG?


> Sam Roberts <sam@cogent.ca> writes:
> 
> > There are a few thousand programmers *paid* for developing GPL s/w as a
> > primary source of income. Lets call it 10,000 (which I don't
> > believe). There are 2 million programmers working in the US, or so I
> > read in a recent DDJ journal.
> 
> This is largely a false dichotomy.  The vast majority of programmers are
> working on internal-only applications for large businesses or contractors
> whose licensing status is in most cases completely irrelevant because the
> application will be used only at one site and will never be sold.
> 
> In the broader view of programming, *all* packaged software products made
> available outside of the organization in which they're developed are
> minority exceptions.
> 
> Part of the argument frequently made by supporters of free software is
> that all that software that's used internally would benefit from broader
> sharing of free software (to cut down on reinvention of the wheel) and is
> not at all harmed by being released as free software since no one will
> ever try to make money off of it being proprietary anyway.  This ties into
> the whole "pay programmers for programming, not for having programmed"
> argument over business models, which is commonly discussed on
> gnu.misc.discuss and is a bit outside the scope of this mailing list.
> 
> -- 
> Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>
> 
>