4 ms·

I'm shocked to hear that. What exactly is preventing it from be used as a real library?

• binarycrusader 8y ago
  Probably the license and/or lack of an appropriate licensing exception.
  • DSMan195276 8y ago
    Another posted indicate code issues, but I think you're right this is at least a big reason. GPG is GPL licensed, but GPGME is LGPL licensed. A library version of GPG would have to be GPL licensed as well, which would require any programs linking to it to also be GPL. With that, for GPGME to be LPGL there can't be an actual coupling of code between the two or else GPGME would have to be GPL licensed itself. (Though you could argue the distinction here a bit murky)
• vertex-four 8y ago
  I believe that it's primarily that GPG has been implemented in such a way that console concerns invade most of the program, but I've never actually looked to verify.
• newnewpdro 8y ago
  IIRC it's deliberately done this way for a number of information security reasons. If you look through the gnupg manual, there are references to things like "on old systems, this program must be setuid root so it may lock memory pages". Presumably it's desirable to require such a thing in an isolated process rather than the entire application utilizing gpg. Since quality CLI implementations must be provided and exist anyways, why not provide the programmatic interface (libgpgme) as a thin veneer over it, as if the commands are being run from the shell?