I've contacted the FSF about the licensing implications of including gpg with Python programs. This is primarily for Windows - Posix users are better off installing through their distro package manager or equivalent of the Homebrew/MacPorts type, if necessary.
Although the response I received was from a volunteer with the GPL compliance lab rather than a lawyer for the FSF, it was encouraging. It basically says that if a Python package wants to include some of GnuPG, then it can do so, without violating the GPL, provided that the Python package: 1. Includes information to the effect that the package includes (parts of) GnuPG, and that it is GPLv3 licensed. 2. Includes the text of the GPL v3. 3. Includes the source code corresponding to the bundled binaries (.bz2 ~4 MB). 4. Uses fork/exec/subprocess/pipes/files to communicate with the gpg executable. The relevant clauses of the GPL FAQ are at [1][2]. Such a distribution would appear to be classified by the GPL FAQ as an "aggregate". Note that GnuPG goes to some trouble to allow itself to be invoked, and to communicate, as per item 4 above. Subject to the above assurances being verified by PSF lawyers, it would seem that we don't need to worry about obstacles to the user experience relating to having to install GnuPG on Windows, where the gpg executable works without needing to be installed. Python packages using GnuPG don't need to include python-gnupg as a dependency; they can include the code to use subprocess directly, as distutils does. Regards, Vinay Sajip [1] https://www.gnu.org/licenses/gpl-faq.html#MereAggregation [2] https://www.gnu.org/licenses/gpl-faq.html#GPLCompatInstaller _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
