New GPLv2 Irrevocability section & Github pull requests now "meh... ok"

[Bradley M. Kuhn]

Hey, everyone, I know the Copyleft Guide project has been somewhat inactive
the last few years, but I had occasion to make a useful update today to add
a new section to the canonical version.  I believe the change follows the
"One Rule" [0]. Therefore, the new section is live and published here:
  https://copyleft.org/guide/comprehensive-gpl-guidech8.html#x11-540007.4

Here's the primary patch that implemented it (the others around are just
formatting and drafting flow issues):
  https://k.copyleft.org/guide/changeset/d2b784546039c55dead39ce6e326c0a38b60e466

Thanks to Pam Chestek for contributing this!


Meanwhile, on a meta-project issue that I noticed while reviving the project
infrastructure in preparation for the above:


Today, I modified the description on Github at
https://github.com/copyleft-org/copyleft-guide to say this:

>  The Copyleft Guide is [text describing project] ..... Note that we
>  maintain a Kallithea instance for collaboration at:
>  https://k.copyleft.org/ . While Kallithea is preferred, we do accept pull
>  requests here, too. https://copyleft.org/guide

(It previously said Github repository was a "read-only mirror" and
contributors should "use Kallithea to contribute".)

I made this change because I recently discovered the Debian packages git-hub
and github-cli, one of which (not sure which one, I have both installed)
allows reviewing and merging of pull requests without any use of the
proprietary services on Github.

Therefore, I no longer have a strong objection if drive-thru contributors
want to use Github to send a pull request.  I'd be in denial if I didn't
admit that Kallithea does not operate enough like the other hosting
software's workflows, and therefore mandating it as the primary contribution
mechanism may well turn away contributors.  Getting contributors is *the*
hardest challenge [1] this project faces.  I *do* still care deeply about
the issue that Github's default interfaces require proprietary software for
interaction, *and* the data-lock-in issues that Github continues to only
partially address.  Nonetheless, given the advancement of the CLI tools, I
believe a careful project leader can allow input from those contributors who
want Github while: (a) assuring that those who don't use Github can remain
first-class contributors and (b) that no one need use proprietary software
to interact with the project to be a first-class contributor.

So, that's my plan! And, of course, this paragraph in CONTRIBUTING.md
remains the most important:

> Please, do not worry if your patches or new sections of text are not
> properly formatted as patches and/or are not formatted in LaTeX properly.
> Indeed, feel free to offer patches that break LaTeX formatting, or to just
> write up your suggestion in an email.  If the content is appropriate for
> the Guide, the editor-in-chief or someone else will format your
> contribution properly for LaTeX.

Discussion on the topic of allowing Github pull requests welcome, though, if
folks feel I made a mistake on this change.

Thanks all for reading this!


Footnotes:

[0] As a reminder since it's been a while since it was mentioned here, the
    "One Rule" (found in CONTRIBUTING.md) is about what rule should be
    followed when something is push something to master branch:

    > Treat 'master' branch as if by committing there, you have
    > single-handledly defined for the world what copyleft is.

    I think no one disagrees that GPLv2 is irrevocable, and the Guide
    already had some text in it to that effect -- this just gives more
    arguments, discussion, and detail, so the One Rule was followed.

[1] We're going to continue to face the problem of "hardly any contributors"
    for various reasons, including that many experts prefer to talk about
    copyleft (including the recent discussions about irrevocability) on
    confidential mailing lists (at least one of which explicitly forbids
    membership for those who lack "profound expertise" and also operates
    under aggressively-enforced secrecy rules).  And that's just the first
    reason on my mind why we face uphill battle on contributions.

    If anyone has suggestions on new approaches to getting contributors, I'd
    welcome it.  And, I do, BTW, apologize to those whose pull requests
    haven't been processed: https://k.copyleft.org/guide/pull-request

    .... but I know all of you who are pending personally and I'm pretty
    sure the failure of me, Ben, Donald or Engel to merge your requests is
    not the reason you've not contributed more. :) And Engel should be able
    to merge Engel's own requests anyway.... if your credentials are not
    working, Engel, do let me know!
-- 

Bradley M. Kuhn

Pls. support the charity where I work, Software Freedom Conservancy:
https://sfconservancy.org/supporter/