Hello Branden, G. Branden Robinson wrote on Thu, Sep 18, 2025 at 02:31:16PM -0400:
> gbranden pushed a commit to branch master > in repository groff. > > commit df992c9993bbe5522fb20bd5cc4f2a08498215fc > Author: G. Branden Robinson <[email protected]> > AuthorDate: Sat Sep 13 07:57:53 2025 -0500 > > tmac/doc.tmac: Revise copyright notice. > > Add a copyright notice for myself. I've never executed copyright > assignment paperwork with the FSF, so my "legally significant"[1] > changes to this file in 2021-2024[2] can't be under the FSF's copyright. > > (I retain an FSF copyright notice corresponding to all changes not > authored by me [even where in a given year no such individual change > meets the aforementioned threshold of "legal significance"--maybe I > shouldn't in this case], because I don't know who _has_ filed copyright > assignment paperwork with the FSF; I know only that I haven't.) I assume "I don't know who _has_ filed copyright" is intended to mean "I don't know the complete list of all contributors to GNU roff who have filed Copyright assignment contracts" = "there are some contributors whose status is unknown to me". For me in particular, i'm pretty sure Branden knows that i did *not* sign a Copyright assignment contract with the FSF because i told him so at least in private mail IIRC. Given that my name appears in this commit message, let me also clarify the situation in public, just to minimize the risk of people getting confused in the future. In principle, i would have been willing to assign Copyright of my contributions to GNU roff to the FSF. What i objected to wasn't assigning Copyright itself (even though i do not like the idea in general, but when contibuting to a project that has such a policy, i can tolerate it); instead, what i refused were the additional contractual obligations, the additional duties and liabilities that the particular contract which the FSF asked me to sign would have put on me, and the FSF refused deleting these additional burdensome obligations from the contract. They were unwilling to accept a pure Copyright assignment contract. Consequently, i did not enter any contract whatsoever with the FSF. > An analysis predicated on "a net increase of at least 15 lines in one > commit" results in a ratcheting back of the dates in the notice. I'm sure you are aware that rule is only a very rough rule of thumb. I'm not a lawyer, but i'm sure many commits exist that add or change significantly more than fifteen lines but would not stand up in (some) courts as establishing Copyright (because their actual content is too trivial), and i'm sure many commits exist that change only a handful of lines, much less than 15, but are creative enough that they do establish Copyright. > I'm the only person to have contributed to this file since > Ingo Schwarze in 2019, First, let me clarify that i agree with Branden that i did make a few Copyright-worthy commits to GNU roff. Here is one example from the file in question: commit e53dff356d43f358133138d2f99eca7b0a7fda32 Author: Ingo Schwarze <[email protected]> Date: Sat Jan 13 03:50:59 2018 +0100 [mdoc]: rewrite the implementation of the .Lk macro * tmac/doc.tmac-u (Lk): Rewrite. [...] ChangeLog | 23 ++++++++++++++++ tmac/doc.tmac-u | 82 +++++++++++++++++++++++++++++++-------------------------- 2 files changed, 68 insertions(+), 37 deletions(-) My understanding with Werner Lemberg back then was, IIRC, that the FSF did *not* require Copyright assignment for contributions to the mdoc macros even back then because these macros, even after the extensive rewriting by Werner Lemberg and Ruslan Ermilov, were and are still under a BSD license and not under the GPL. My understanding with Werner also was that, as far as i contributed changes to GPL'ed files, for which the FSF did require Copyright assignment back then, those code changes of mine were "minor changes" in the sense that they did not establish Copyright. (As a side node, it appears that today, at least for some projects including groff, the FSF no longer requires Copyright assignment, not even for GPL'ed files. Judging from old private email exchanges and the subsequent timing of FSF policy changes, it feels likely that part of these policy changes were in part triggered by my complaints about the content of the FSF Copyright assignment contract - but of course it also seems likely that not all related FSF policy were caused by that, and it seems likely other contributing considerations existed that i'm unaware of.) Now that the FSF no longer requires Copyright assignment even for GPL'ed files in GNU roff, i think it is safe to admit that i never felt 100% convinced that the classification of all my GPL-code changes to groff would stand up as not establishing Copyright in each and every court, but everyone *was* happy with just assuming as much back in the day. > and by this metric, I made no single "legally significant" > change this calendar year. Again, i'm not a lawyer, but according to my understanding, what matters for Copyright is *cumulative* changes, not *individual* changes. For example, making thousand commits each adding one line (even when spread out all across a whole calendar year) establishes the same Copyright as making a single commit adding the same thousand lines at once. [...] > Drop ersatz '(C)' copyright symbol. Software developers have long > labored under the no-longer-correct misconception that omitting a > copyright symbol from one's notice was a fatal defect that effectively > placed the work in the public domain. That stopped being true as of 1 > March 1989.[3] Further, prior to guidance issued by the U.S. Copyright Sure, and under international law (specifically, the Berne Convention), Copyright notices are merely informative anyway, and their presence or absence does not change who holds Copyright. That U.S. law required Copyright notices for Copyright to be recognized in court was a bug in U.S. law only that has been fixed by the U.S. legislator decades ago. All this was never a thing outside the U.S. in the first place. The reasons for including Copyright notices in files are: 1. Clarity. They make it easy for readers to immediately see the main contributors, without searching around. 2. Credit where credit is due, as a matter of moral decency rather than legal requirement. 3. Many licences specifically prohibit the removal of Copyright notices. It is widespread practice to only include *selective* Copyright lines, i.e. most maintainers only list the most important contributors in formal Copyright lines and do not list persons who contributed minor, but still Copyright-worthy amounts of text or code. Rare exceptions do exist: for example, the Copyright lines in all files of the mandoc distribution are intended to be complete (despite my best effort, i'm not convinced they actually are, given how fuzzy the legal concept of Copyright-worthyness is - fortunately, that unavoidable uncertainty does not matter *at all* because the notices are only informational in the first place and do not change which rights do or do not exist). [...] > [2] Here is a qualifying commit from applicable calendar years in the > range, produced with the aid of `git --log --stat --follow`. > > commit 3f7c24349d420789f2a465ff39a337d25f21caa6 > Author: G. Branden Robinson <[email protected]> > Date: Tue Mar 19 14:51:00 2024 -0500 > > [mdoc]: Set literal displays in Courier family. > > tmac/doc.tmac | 31 +++++++++++++++++++++++++++---- This is funny. The main reason why i agree with you that this particular commit almost certainly establishes Copyright is that it added a *comment* starting with the word "TODO:" that spans seven lines. Yes, a comment can certainly establish Copyright when it is creative enough. The six lines of code additions contained in that commit, on the other hand, feel pretty trivial to me - i doubt they reach any threshold of originality. Well, maybe they do, who knows what courts might decide, but if they do, then only barely so. The remaining eighteen "+" lines are definitely totally trivial. [...] > tmac/doc.tmac | 19 ++++++++++++++++++- > > commit ee41d36200ffc989eac09e65db7537bf59dd1c62 > Author: G. Branden Robinson <[email protected]> > Date: Sun Jul 4 23:56:18 2021 +1000 > > Skip the stripper, part 3/3 (mdoc). [part 3c] > > tmac/doc.tmac | 291 ++++++++++++++++++++++++++++++++++++++++++++++++-- That commit, on the other hand, feels entirely trivial to me, entirely mechanical, and i have a hard time discerning any creativity or originality whatsoever. These two examples show that automating or formalizing Copyright assessment is next to impossible - but again, fortunately, that's not a practical problem because the Copyright lines are advisory in the first place, so making a best guess in good faith is all that is needed. Using your eyeballs and common sense is at least as good as setting up any kind of programmatic analysis - and also saves you a lot of work. Then again, doing some kind of mostly meaningless programmatic analysis does very little harm apart from wasting your time, so churn away with your automated toolchain to your heart's content! :-D All that said, i neither object to being listed as a Copyright holder in any files where you think i contributed enough, nor do i object to not being listed anywhere except in the commit logs. Your call, however you choose is almost certainly fine with me, or if i would regard some listing as a particularly egregious misrepresentation (which is quite unlikely to happen), i would simply speak up and tell you why i consider it inaccurate or misleading, again leaving the fix in the maintainer's discretion unless i feel so badly slandered that i would insist on fixing it - but i have a hard time imagining any real-world circumstances where that could possibly happen. Finally, let me clarify that i do *not* disagree with what vou did in this commit, and that i do *not* significantly disagree with anything said in this commit message, i merely wanted to add some clarification regarding my own contributions and some perspectives and opinions that are intended as supplements rather than as disagreements. Yours, Ingo
