Gpgme license

[Werner Koch]

On 11 Jun 2002 02:15:27 -0400, Jeffrey Stedfast said:

> First, I assume that Gpgme is GPL?

Sure.

> Would you be willing to change the license to LGPL? I'd be very

No, definitely not.  We did this for Libgcrypt but GPGME is a
different thing and the general rule applies:

    Please note that in many cases it is better for a library to be
    licensed under the GPL, so that it provides an advantage for free
    software projects.  The Lesser GPL is so named because it does
    less to protect the freedom of the users of the code that it
    covers.  See http://www.gnu.org/philosophy/why-not-lgpl.html for
    more explanation.

> Unfortunately, our Exchange Connector product is not GPL (though
> Evolution itself is) and so I don't think we'd be able to use Gpgme

Huh?  You link you proprietary Exchange Connector with the GPLed Evo?

> Another question I had about Gpgme (unrelated to licensing) is that it
> seems Gpgme is planning to have some sort of S/MIME capabilities, is
> this true? If so, definetely another plus :-)

Sure, it is already working.  The backend is called gpgsm and for now
available in the newpg package available at
ftp.gnupg.org/gcrypt/alpha/aegypten/.  Eventually this will get merged
into the gnupg package (as a separate binary and after gpg has been
changed to make full use of the gpg-agent).

> How is this S/MIME code going to work? Is it just going to
> encrypt/decrypt/etc a block of data and leave MIME parsing up to the
> client application? Or is Gpgme going to do some MIME parsing?

gpgsm is similar to gpg, so it does not care about MIMEing.  GPGME
also does not know about MIME.  I think it is in general better to
utilize the existing MIME framework of a MUA (which required us to
hackup the non-existing MIME framework of Kmail ;-).

> I'd actually prefer that it didn't (this should be the job of the
> client), but I'll take what I can get :-)

You should be happy.  One thing is not yet implemented: gpgme
currently copies the data or has to work on a file, but everything for
using a FD as input or output is already in the API we only have to
implement it.  There is a way to overcome this by using gpgme I/O
objects (GpgmeData) based on callbacks (actually this is what we are
going to use internally for FD based data objects anyway.

BTW, GPGME will be thread-safe can can make use of GLIB's I/O system.
Marcus is currently finishing this feature.


Salam-Shalom,

   Werner