Re: Removing in-source contribution records contributer

G. Branden Robinson
2025-05-09T14:48:55Z

[-- Attachment #1: Type: text/plain, Size: 3645 bytes --]

[CCing groff list because I bring up some project management details]

Hi Dave & Alex,

At 2025-05-09T15:14:57+0100, Dave Martin wrote:
> Should the one-line replacement statement in each file refer back to
> the CREDITS file?
>
> Also, nothing seems to say that anyone listed in CREDITS actually
> contributed copyrightable material to the project (as opposed to, say,
> review effort, moral support or free pizza).
>
> Renaming the CREDITS file to AUTHORS and/or clarifying this in a brief
> top-level LICENSE / COPYING file might make the meaning clearer?

At 2025-05-09T16:39:05+0200, Alejandro Colomar wrote:
> I prefer not, because then someone can copy the files to a different
> repository, without needing to modify the notices (they might take the
> CREDITS file as CREDITS_Linux-man-pages).
>
> > Also, nothing seems to say that anyone listed in CREDITS actually
> > contributed copyrightable material to the project (as opposed to, say,
> > review effort, moral support or free pizza).
>
> I initially planned to include reviewers, etc. into CREDITS. While
> doing that, I realized that wasn't easy, because the file would be
> huge, and would need to be updated too frequently; plus git(1) does a
> better job of documenting that with the Reviewed-by, Cc, and other
> tags.
>
> > Renaming the CREDITS file to AUTHORS and/or clarifying this in a
> > brief top-level LICENSE / COPYING file might make the meaning
> > clearer?
>
> Yes, now that I discarded the idea of crediting *all* contributors, I
> agree this file should be renamed to AUTHORS. Regarding a file solely
> to clarify that the AUTHORS file holds the copyright holders of the
> project, I guess by calling it AUTHORS it would already be obvious.
> I'm hesitant to add another file for explaining that because the more
> uppercase files there are in the root of the repo, the harder it is to
> understand their relationship. However, I can add something in the
> README, where I already document what each file is.

Yes, this is consistent with GNU approach--as I understand it--of having
an "AUTHORS" file for copyright holders and a "THANKS" file for
acknowledgement of anyone who isn't a copyright holder.

Before anyone asks, groff doesn't use that approach, I think because it
is so old (starting 1989) and predates some GNU common practices.

On my get-around-to-it list is to determine who's actually signed
copyright assignment paperwork to the FSF for their groff contributions,
and who has not. Anyone who had made a significant enough contribution
that copyright assignment would be worth the trouble would be listed in
AUTHORS whether they'd executed the assignment paperwork or not.

Also, since the contrary is a common misconception, the FSF does not
_require_ copyright assignment.

'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 has authority to act to stop GPL violations
about the package (otherwise, legal actions are up to the author(s)). It
also allows us to grant additional permissions on a package, such as an
exception, if the need should arise. Additionally, holding the copyright
allows us to upgrade the license of a package even if it had been
initially released under "GPLv2 only" (instead of the "or later"
licensing option as recommended by the FSF). The rest of this section is
about the case when a package is FSF-copyrighted.'

https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html#Copyright-Papers

Regards,
Branden