Gpgme license

[Jeffrey Stedfast]

On Tue, 2002-06-11 at 03:32, Werner Koch wrote:
> 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.

disappointing, but I understand

> 
> > 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).

ah, okay.

> 
> > 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 ;-).

Yes, I very much agree - which is why I asked :-)

unfortunately OpenSSL tries to do their own MIME parsing which was a
real problem (for the S/MIME stuff).

> 
> > 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.

Yes, I saw these - very similar to our CamelStream's. Unfortunately, I
did not see a way to create a GpgmeData object that could be written to
(other than a file or memory I suppose)?

I saw a gpgme_data_create_with_read_callback() or some such, but didn't
see one for creating with a write_callback which is what I think I'd
need.

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

Thread-safeness is always good :-)

Thank you,

Jeff

-- 
Jeffrey Stedfast <fejj at ximian.com>
Ximian, Inc.