Thank you for clarifying a bit about who is behind FreePG! Andrew Gallagher <andr...@andrewg.com> writes:
> Simon Joseffson <si...@joseffson.org <mailto:si...@joseffson.org>> wrote: > >> It seems there is push from the anti-GnuPG people to promote a fork >> called FreePG instead of real GnuPG, will you package that? >> >> https://gitlab.com/freepg/gnupg > > FreePG is not an anti-GnuPG project, if anything it’s trying to keep > GnuPG on Linux alive as long as possible, so as not to force users > into a disruptive sudden migration to other tools. It is also very > deliberately not a fork, but rather a set of discrete patches that are > already being applied by multiple downstreams, some dating back years. So the FreePG set of patches results in a GnuPG fork by all meanings except, apparently, by name. If you take a piece of freely licensed software and make modifications that goes beyond simple build fixes, I would call that a fork. https://en.wikipedia.org/wiki/Fork_(software_development) If the justification for those modifications are disagreement with upstream about how GnuPG should behave with regard to the wire protocol, it becomes even more clear to me that we are talking about a fork. We've seen this before, like LibreSSL or OpenSSL, or EGCS vs GCC or Iceweasel vs Firefox. Each example is somewhat different, but they are useful for comparison. It is fine to disagree with a project, and chose to use or work on something else. I don't think it is a good idea to use the powers that comes by being a package maintainer or distribution to force changes of how some piece of software is supposed to work by patching it without changing its name. Doing so mis-represent the upstream project, and confuses users. What is GnuPG? Upstreams GnuPG or Debian's GnuPG or Fedora's GnuPG or Hooty's GnuPG? This situation is bad both for Debian and GnuPG, and to the wider PGP eco-system. If there is commitment to provide long-term support for FreePG, how about uploading that as a separate package in Debian? And also please upload verbatim upstream GnuPG separately. This allows user choice. Right now there are claims that we shouldn't use GnuPG 2.4.x because it is EOL before trixie EOL and the two alternatives that are proposed instead is to continue use GnuPG 2.2.x or the FreePG fork that also lack long-term commitment EOL date for support. /Simon
signature.asc
Description: PGP signature
