Changing GPGME's license

I often enountered very slow or no responses at all with advogato and thus after a while I used the post button a second time :-(

I come to this as the author of several small GnuPG-interacting programs and libraries (pgpenvelope, Perl GnuPG::Interface, keystory, etc). I have not used gpgme, but this is mainly because I started working with GnuPG before gpgme was around. I can say, however, that while most of my products are GPL'd, anything that could be considered 'linkable' I have placed under the LGPL, and would be reluctant to use gpgme for any of my *libraries* (though I might use it for a end-product).

In my opinion, the questionable benefits of using the GPL over the LGPL are outweighted by the more concrete, quickly-realizable benefits of widespread use of gpgme and, in turn, GnuPG.

You might generate income if the license was changed to LGPL. If proprietary vendors pick up gpgme then, and want changes/support, they would most naturally turn to your company. Since, as you state, you're not generating revenue from gpgme as it is, it would be hard to get *worse* than it already is.

It's only unique because nobody else has written one. It's not trivial to do so, but it's not a gigantic task. The spec (RFC 2440) is available for everyone.

I think what you're asking is "should I write this wearing my free software activist's hat, or my crypto activist's hat?" since those are not entirely the same. I've found myself with the same question at times and have written some free crypto code under licenses that allow proprietary use. However, that was mostly to get them accepted into distributions of specific other programs that used those licenses.

My recommendation for GPGME is stick with the GPL. There's not exactly a lot of developers out there waiting to write PGP-compatible proprietary programs, and the PGP file format really isn't all that important any more. If someone does write a program that interoperates with PGP, they then have to choose whether to make it free or proprietary; keeping GPGME GPL'd may help them decide to keep it free. If they want to make it proprietary they can always work out some license with the PGP Corporation to use the PGP code. And finally, if someone writes a proprietary program, that limits how many people will use it. Crypto activists score wins by how many people are using cryptography, and more people like to use programs that are free.

Maybe you're getting asked by some proprietary developer to release GPGME under the LGPL so they can use it. I got a similar request for a library that I announced a while back. I responded that I'd consider using the LGPL if the requester wanted to fund development of the library, and while they liked that answer, unsurprisingly no funds were forthcoming so I stuck with the GPL.

As I have already mentioned on the GPG-DEV mailing list, in response to Werner: I dont think that a C wrapper around gpg is all that unique. I know at least one commercial product who has rolled it's own gpg wrapper: it was faster to implement, used only a small subset of the functionality, and was not tainting the commercial product.

After all I believe, there could be much more Free programs, if GPGME was not GPL. After all, there is nearly no interesting code in terms of crypt in it. And while it could be a front-end to multiple crypto backends, I think there are none available, and the abstraction is not too clean, anyway.

On the mailing list, I was expressing my concern, that GPG and GPGME is not as sucesful, at it should be. Werner had big funding for the project, but the licensing of GPGME, the API flux and most likely the bloat (in terms of spawning a process and parsing ascii) is one of the reason, it is not wide spread. The same may be true for OpenPGP. I do not consider it GPGs fault, but sill the standard is too complicated. A lot of implementors stick with 2.6. Interoperability and lean design is a major point, here.

Lately I switched to S/Mime, because MUA support and usage increased greatly.

It might not we known to widely, but GPGME has been written with the goal to abstract the underlying crypto protocol from the application. It is still not clear whether S/MIME or OpenPGP will be the dominant protocol in some future. Currently OpenPGP is it, but the corporate folks might eventually achieve to change this. That is the reason why I always advise to use GPGME to better cope with future changes. It is also the reason for some design issues which look weird from a pure OpenPGP perspective.

For example, I have a Mutt version which can silently switch between S/MIME and OpenPGP and has a much better integration than the old fork/exec of the current Mutt. This version is actually in use by several folks for their daily work. It is just a matter of time to be able to integrate this version back into standard Mutt. It will take me only a very few days to bring S/MIME to Sylpheed because its PGP support has always been based on GPGME.

eckes: PGP 2.6 has a lot of problems as you know and integrating it into other software is much harder than plain gpg. It is also likely that PGP 2 support will be removed from OpenPGP. I don't want to reiterate the answers towards your other critism; for example see Marcus' response.

I mostly agree with phr's comments. However there is quite some Free Software under non-GPL compatible licenses (Mozilla) and GNOME framework libraries are (in contrast to KDE) under the LGPL, so that they can be used by proprietary stuff (strange thing for a GNU project, isn't it). I guess that Sun makes use of this and defintely Ximian requires it. They asked me several times for LGPLing GPGME.

Ian Jackson proposed to use a new license by taking features of the LGPL and the GPL. However, we already have too many different licenses with all these compatibility problems, so I don't like such an approach.

As I see it now, I won't change the license now unless some funding can be acquired (despite the fact that I also made Paul's experience a couple of times in the past).

Thanks for your comments.

it's unfortunate that Evolution even needed GPGME to be LGPL, but (due to Connector) Ximian did need it to be LGPL or they wouldn't be able to make Connector proprietary.

What is really sad is that Connector doesn't need GPGME at all, it's just that if the GPG support in Evolution was based on GPGME, we wouldn't be able to link Connector against Camel (which is needed, obviously). Ximain wouldn't be making money off of GPGME since it is probably unlikely that most Exchange users would really be using GPG anyway (Outlook doesn't do a very good job of supporting PGP/MIME - it only supports S/MIME).

that's what makes it sad as far as Evolution is concerned...

Fortunately, I was able to write a state-driven GPG c-wrapper in a few hours that is quite nice (I've had to tweak it here and there over the past year but otherwise it has been pretty bug free). Once I was turned toward the --status-fd and --command-fd gpg switches, this was extremely simple to do... This too is GPL, but since it is owned by Ximian, it doesn't affect Connector at all.

If GPGME was changed to use LGPL, I'm not sure I'd switch Evolution over to GPGME anyway (at least not right away) because my current code isn't that big and serves its purpose quite well. It would also add another dependency to Evolution and we already get enough complaints about Evo depending on so many shared libs (users don't believe in code sharing, I guess. it's bloat when you share code, but it's slim when you implement all that functionality monolithically into your app... user logic will always elude me).

anyways, I can't say it wouldn't be nice if GPGME was changed to LGPL but I certainly understand if Werner decides to keep it GPL and wish him all the luck no matter what he decides.

And what's the Ximian's business plan? Selling t-shirts? Getting money from ventures that clearly do not look forward free software? Selling free software for desktop to run with proprietary software on the servers (everybody knows that free software is the worst on servers, the best on desktops..

werner, mozilla is released under a GPL-compatible license (dual licensing GPL/MPL). "They asked me several times for LGPLing GPGME": they are apparently doing a great deal in making any free software in GNOME available as free beer for proprietary industry. Funny for a GNU project sure.

Mozilla is actually triple-licensed under the MPL, GNU GPL, and GNU LGPL.

It's people like you that give the free software community a bad name. Sheesh.

Is it so bad that Ximian makes 1 proprietary product in order to make money while working on hundreds of free software projects? Ximian does more for free softeare in a single day than you will accomplish in your entire lifetime... especially with your attitude.

Based on your seemingly blind hatred for anything Ximian, sounds like you are jealous that you don't work for a company like Ximian... your behaviour is pretty typical of someone who is jealous (and/or has a low self-esteem). I think Freud called it "Penis Envy".

At NITI, we're making a proprietary replacement for Exchange that runs on Linux. We are making a connector for Evolution, among other things, which will be free software.

This is a very tough call. FWIW, I would give a razor thin margin to LGPL just to make the code more ubiquitous.

I used the MIT license for a snippet of code that does base64 encoding and I have been gratified that it has found wider use than I would have expected. I think I should have LGPLed rather than the less restrictive MIT license, but I wonder what that would have done to the acceptance...

You will have to go with your gut on this one.