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
