Re: How to contribute

[G. Branden Robinson]

Hi Michał,

(Please let me know if you're prefer _not_ to be CCed.)

Let me offer you some perspectives from someone who _does_ contribute to
groff, to contrast with quick responses from someone who's sworn not to.

At 2023-06-03T10:25:16+0000, Michał Kruszewski via wrote:
> Is there any tutorial on how to contribute to the groff?

The source distribution contains some files along these lines (or it
does as of recent 1.23.0 release candidates).  I'd start with "HACKING".

https://git.savannah.gnu.org/cgit/groff.git/tree/HACKING

> The https://www.gnu.org/software/groff/ website is rather modest in
> this term.

I think that web page tries to stick to bare essentials.

> Where do I need to register?  How to prepare pull requests?

To answer these out of order, and answer questions you didn't ask:

1.  You don't prepare pull requests to groff.  If you have commit access
    to our Git repo on Savannah, you can just commit (possibly on a
    branch if a change is dramatic, risky, or when, like now, the master
    branch is frozen for non-documentation changes).

2.  You can create an account on Savannah.  This enables you to file
    non-anonymous tickets/bug reports.  As part of a Savannah ticket,
    you can propose patches.  You can also simply email patches to this
    mailing list.

    https://savannah.gnu.org/account/register.php

3.  The issue of copyright assignment arises only once you decide _what_
    it is you want to contribute.  There is much nuance here that Ralph
    Corderoy does not cover, and he appears to extrapolate his
    impression of one experience (his) to all GNU contributors ever,
    which I know not to be the case.

Let me offer a few points to offset Ralph's categorical discouragement.
Ralph has a talent for that (or a lovingly cultivated skill at it).

A.  First of all I'll just quote §6.1, "Copyright Papers", of the GNU
    Maintainers Guide[1].

    "GNU packages need not be FSF-copyrighted; this is up to the
    author(s), generally at the time the package is dubbed GNU. When
    copyright is assigned to the FSF, the FSF can act to stop GPL
    violations about the package. Otherwise, legal actions are up to the
    author(s). The rest of this section is about the case when a package
    is FSF-copyrighted."

B.  Even FSF-copyrighted projects sometimes decide to go their own way
    after time, and cease requiring copyright assignment from
    contributors or maintainers.  This has happened with gcc, glibc, and
    ncurses, at least.[2][3][4]

C.  The FSF doesn't claim that copyright applies to every jot and
    tittle.  Even assuming for the sake of argument that their view of
    copyrightable expression is broader than most, they set a threshold
    below which they do not even encourage GNU maintainers to attempt to
    acquire copyright assignment.  For contributors who are most
    concerned with fixing bugs, where the required change is usually
    small once a root-cause analysis (as opposed to a work-around) has
    been completed, this is enough.

    "A change of just a few lines (less than 15 or so) is not legally
    significant for copyright. A regular series of repeated changes,
    such as renaming a symbol, is not legally significant even if the
    symbol has to be renamed in many places. Keep in mind, however, that
    a series of minor changes by the same person can add up to a
    significant contribution."[5]

D.  Parts of groff (GNU roff) already don't have, and don't require,
    copyright assignment.  This is explained (carefully, I hope), in our
    LICENSES file.

    https://git.savannah.gnu.org/cgit/groff.git/tree/LICENSES

    "Files in the contrib/ subdirectory of the source distribution are
    not strictly part of groff.  That is, they are distributed with it
    and are Free Software
    <https://www.gnu.org/philosophy/free-sw.en.html>, but they are not
    considered essential parts of the distribution.  Further, they may
    bear licenses other than the GPL or the FSF does not administer
    their copyrights.  To determine their copyright status and
    licensing, see the "COPYRIGHT" file in the appropriate subdirectory
    of contrib/.

    Some files are part of groff but bear licenses in addition to the
    GPL, or have been placed into the public domain.  This is because
    they originated elsewhere; often, the groff project has modified
    them, sometimes extensively.  These multi-licensed groff components
    are as follows.  Their file names are not always identical to those
    in their original distributions, but we have kept them similar."

So I would say that, before you decide to gate your own contributions on
the question of copyright assignment, you consider what it is you'd like
to contribute to groff: bug fixes, editorial changes to documentation, a
new macro package, or a major rewrite of some essential component of the
formatter.

It is possible that you will want to start small.  Over time, you may
find that to suit your needs and/or ambition.  Or perhaps as your
familiarity with the code base grows, your proffered contributions will
have greater impact.  At that point, it may be time to consider
undertaking a negotiation with the FSF over the terms of assignment.

I would say that part of Ralph's implication, that the FSF has done
little to disabuse people of the notion that it has an utterly
inflexible, take-it-or-leave-it policy with respect to copyright
assignment, matches perceptions I had when I started participating in
Free Software development in the 1990s.  On the other hand, many years
ago when I stopped merely listening to what everybody said about the
FSF, and started digging into the copyright details of various GNU
packages, I found more flexibility there than I had been led to
expect--even around the year 2000, when the floor was still slick with
blood spilled over the EGCS fork, the EGLIBC fork, and the Lucid Emacs
fork.  The former two were adopted by the FSF as the official GNU
projects with a change in governance, and the latter eventually withered
to nothingness, perhaps revealing Jamie Zawinski's capacities for steady
leadership and talent retention as being roughly on par with RMS's.

Anyway, I'll stop here before further indulging soapy stories of past
flame wars.  Please let me know if I can be of further assistance.

Regards,
Branden

[1] https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html
[2] https://lwn.net/Articles/857791/
[3] https://sourceware.org/pipermail/libc-alpha/2021-July/129577.html
[4] https://invisible-island.net/ncurses/ncurses.faq.html#who_owns_it
[5] https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html

signature.asc
Description: PGP signature