Re: How to contribute

[Michał Kruszewski]

By patches you mean `git diff` output?


Best regards,
Michał Kruszewski


Sent with Proton Mail secure email.

------- Original Message -------
On Saturday, June 3rd, 2023 at 4:47 PM, G. Branden Robinson 
<g.branden.robinson@gmail.com> wrote:


> 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