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.robin...@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
