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 must 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 used in this way.
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 (at least 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 proprietary 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 communication.
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 could gain 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 one-time financial compensation to change the 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.
We need both LGPL/BSD and GPL licenses.
Without the BSD covering the BSD sockets or TCP/IP, we would not have today our TCP/IP. Vendors always tried to push their proprietary protocols and by having the TCP/IP implemented by BSD (and other Unix-derived at that time - DARPA choosed BSD as its implementation was the fastest and cleaner). So we need to use BSD alike (LGPL ? No idea, I don't know it very well) to propagate stuff that doesn't have a commercial value per se (like protocols) and keep the GPL to protect what can have a commercial value like ERP software or alike.
My 0.2 euro
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.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!