Changing GPGME's license
stephane at sente.ch
Sun Jul 20 22:27:02 CEST 2003
I'm not sure I got it right: do you mean that GPGME could be
It would be available to all with GPL, as of now, and for people
wanting to use it in non-GPL'ed software you would license it to them
as LGPL, providing that they pay some royalties?
On Friday, Jul 18, 2003, at 15:44 Europe/Zurich, Werner Koch wrote:
> I recently had some discussion with Marcus and others, whether it
> might make sense to change the license of GPGME from the GPL to the
> LGPL. Here are some thoughts:
> I general I believe that the GPL is the best tool to protect the
> freedom of our software. This is not limited to programs but also
> counts for libraries because they often provide large parts of the
> logic. Therefore the GNU project tries to keep libraries under the
> GPL and does only use the LGPL in certain situations.
> The drawbacks of the LGPL (from a Free Software POV), is that it makes
> it easy for proprietary software to build on existing and well working
> Free Software code without granting the user the full freedom back.
> The LGPL basically requires that the LGPLed code most be made
> available under the LGPL but does not demand anything from the
> proprietary software; except the ability to be linkable against
> modified GPLed components. Thus it is easy to include worthy features
> in the proprietary code without changing LGPLed code. As an author of
> Free Software I am usually not too keen to see my code proprietorized.
> However, as stated by the FSF it sometimes makes sense to put code
> under LGPL. One valid reason would be code with many implementations
> (e.g. SSL), where a GPLed implementation is no incentive to be used by
> proprietary code. It is often hard to weight out the advantages and
> disadvantages of LGPLing code.
> With respect to GPGME, I early decided that it is quite a unique
> interface to crypto backends (for applications requiring a C
> interface) with no real counterparts neither in the free nor in the
> non-free world. The PGP SDK clearly resembles the functionality of
> GPGME up to a certain level, but it is expensive and not widely used
> in mass market software. I have always refused requests to change the
> license for the benefit of proprietary MUAs or even Free Software like
> Evolution. So most of the few MUAs with OpenPGP support went the
> not-that-elegant way of exec/forking gpg - something GPGME currently
> also does but with a clean high level interface on top.
> I'd still hold up my reasoning if GPGME would be just one library to
> do foo stuff. But GnuPG (and thus GPGME) is more than just some Free
> Software tool for processing data. Based on PGP, GnuPG is also
> important for ensuring the right to communicate privately over
> computers without the fear of being spied on. Especially these days
> it is again more and more important to have means to secure ones own
> It is realistic to believe that we can't abolish proprietary software
> entirely in the next years. Thus we have to live with proprietary
> systems, especially MUAs, for the time being. I can image that GPGME,
> distributed under the LGPL, would be an incentive to some vendors to
> add OpenPGP functionality to their products. From a crypto rights
> POV, this seems to be a sound decision. Another important advantage,
> we should not forget about, is that an LGPLed GPGME helps Free
> Software which is not compatible to the GPL.
> OTOH, my company has put quite some money on the development of GPGME
> and is employing Marcus for maintaining it. We don't make any
> revenues from GPGME development and it is questionable whether a new
> license will change this at all. At least proprietary products gain a
> lot of benefits from such a change and in-house applications would
> also save a substantial amount of money when not using PGP's
> SDK. Therefore I think it is fair to ask for a financial compensation
> for a license change.
> Werner Koch <wk at gnupg.org>
> The GnuPG Experts http://g10code.com
> Free Software Foundation Europe http://fsfeurope.org
More information about the Gnupg-devel