Hi Ingo, At 2025-09-23T14:41:04+0200, Ingo Schwarze wrote: > 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".
Exactly. > 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. Yes, but that wasn't a source I could cite that anyone else could verify. > 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. Thank you for doing this; I now have something I can point to. :) I'm happy to update copyright notices reflecting this fact on an opportunistic basis. At present my approach is not systematic, in part because (1) I'm still working out how to attack the problem of stale and/or overgeneral copyright notices in the groff code base and (2) the approach I've been taking exposes some limitations or infelicities of the guidance in the GNU Maintainers' Guide--you've put your finger directly on a few that leave me incompletely satisfied both with the status quo ante and my improvisational efforts to address it. > 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. I don't think you're alone. I refer the reader, as I often have, to https://invisible-island.net/ncurses/ncurses-license.html ...which I think illuminates a lot of problems characteristic of FLOSS project management that I think the community in general does a poor job of coping with. The most popular approach by far is to pretend, to oneself and to often to others as well, that these sorts of challenges don't need to be faced. Some authority figure will come down from on high and handle everything as a parent would, benevolently or otherwise, and the hackers can remain in idyllic(?) childhood. > > 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. Very much so. > 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 completely agree. But that's the rule the GNU Maintainers' Guide establishes. I don't have an alternative that is as easy to apply. > > 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. I...do not think I buy that logic strictly, but I fully empathize with seizing it as a rationale to avoid conflict with FSF leadership. Possibly Werner was aware of an FSF policy not present in the GNU Maintainers' Manual to not pursue copyright assignment on contributions, irrespective of size, that wouldn't be distributed under copyleft anyway. > 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.) I find your inferences entirely plausible. Given the EGCS and EGLIBC episodes, I would not be surprised if the relaxation of the assignment policy in 2013[A] arose due to accumulating frustrations both among contributors and the burdensomeness of administration and enforcement of that policy to FSF business office personnel, as it were. It would have been better for such a shift in approach to have been frankly announced, with rationales for both the old and new policies articulated, along with candid acknowledgment of how the FLOSS community was evolving. There were vastly more copyleft advocates in 2013 than in 1983. People engaged in a reformist struggle for a long time sometimes have trouble difficulty recognizing their own victories when they aren't total. But that milk spilled 14 years ago. > 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. Yes. I find those decisions understandable. But I've been in the maintainer role for a year now, completely free of imposed decrees or even any perceptible efforts at "management", so, indulging my own reformist inclinations, I feel more confident about throwing light on some of the more head-scratching problems of groff project management, and gently inviting a consultative process with its contributors to address them. Thank you for accepting that invitation. > > 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. I don't quite agree with your phrasing here, but I think we get to the same place. > 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. I completely agree with this. In the past few days, I happen to have been reviewing the Chicago Manual of Style's (18th Edition) material on copyright, which appears well researched and sensible. (I've worked professionally in FLOSS copyright compliance.) On the one hand, we could save ourselves administrative effort by simply not having dates in copyright notices at all; thanks largely to The Walt Disney Company, almost no human being who witnesses a work being born into copyright will live to see that copyright expire. Further, a firm like The Walt Disney Company, being well heeled, infringes copyright to its own pecuniary benefit,[B] presumably in pursuit of expediency, "economic rationality", or "shareholder value".[I] These fig leaves all amount to the same rationale: "because I can". On the other hand, if a maintainer or other developer is nagged occasionally by the fact of an old-looking copyright notice to review contributions to the file for possible updates, that's not necessarily a bad thing. On the third hand, the truly robotic update of copyright notices encouraged by gnulib to "bump" copyright notices in _all_ files at the beginning of the calendar year, in advance of _any change at all_, I find disagreeable, largely because it defeats the aforementioned prompt for human attention and consideration. > [...] > > 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. Agreed. I noticed from participation in a large number of copyright debates and arguments in the decade of the 2000s on the debian-legal mailing list that a lot of software hackers, within and outside the U.S. alike, labored under the misconception that a copyright notice was anything other than _documentary_; instead, they seemed to feel that it constituted some kind of _assertion_ of legal privileges that would vanish along with the text if effaced. (I guess the U.K. still has something similar--or pretends to vis-รก-vis French laws about "droit d'auteur"--because in books published there I often see on the copyright page the statement "The moral rights of the author have been asserted".[G] These hackers were at least a decade out of date. They also tended to be the type of personality that is born correct and goes to its grave having never been motivated to change its mind. > 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. Legal fictions constructed to operationalize the extraction of economic rents often have curious features. > 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. In the U.S., effacement of a valid and accurate copyright notice can be a criminal act.[H] So can putting an inaccurate one on in the first place.[ibid.] Fortunately, the law requires "fraudulent intent", so I don't perceive much risk in making efforts to make groff's copyright notices less inaccurate with the imperfect information available to me. > 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. Yeah, and I'm not sure that practice is entirely defensible. One could read the ncurses licensing story as an example of its abuse in service of one party's malignant narcissism and efforts at plagiarism. > 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). I applaud your efforts to treat all contributors equitably, and find relatable your frustration with the nonexistence of a bright-line, objective standard for testing contributed material for measures of originality and quantity sufficient to establish copyright. > > [...] > > [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. I was aware of that when including it, and the next. > [...] > > 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. Sure. I decided that mechanically applying the GNU Maintainers' Guide's metric for "legal significance" was a worthy experiment. That's why I quoted it and cited it in the commit message. If a robotic application of that definition seems to lead to silly or absurd results, then I suggest a problem with the definition. What's the solution? The GNU Maintainers' Guide could do two things. It could come up with a better rule--and given the difficulties created by underlying law and legislatures' and courts' reluctance, as far as I know globally, to create metrics for "volume" and "originality" precise enough for computer programmers to automate them--such might be challenging to construct and/or apply. Or it could formalize what appears to have been the GNU Project's actual practice, which is trust in human judgment and delegation of decisions to the maintainers of individual projects. I perceive the GNU Project as having historically struggled _formally_ with delegation and its leadership has seldom articulated a presumption of confidence in delegates. On the bright side, _operationally_, my perception is that it's built up a reliable record of entrusting project maintenance to reliable stewards. Can you indulge me an ecological analogy? * Some projects are like alpine mountain peaks; they're impressive to look at and a major challenge to climb. The air is thin, the temperatures cold, and woody plants don't grow, just mosses. * Others are like jungles; everything is entangled with everything else, dynamism is the rule, trees compete madly for sunlight, turnover on the floor is high, and it's easy to get lost. * Others are like cultivated farmland. Everyone is a corn stalk, there is great uniformity, the caretakers are aggressive about weeding, and apply toxic pesticides routinely. The individual plants are wholly dependent on management for survival. * Finally, some are like cactus forests. There's lots of sunlight, but little rain. The environment is unfathomably hostile to cultivars reliant on tending, but hardy plants can endure for decades. The unforgiving landscape nevertheless has an alluring beauty to many. Once in a great while and without warning, a bolt of lightning streaks out of the sky and burns one cactus to a crisp. > 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 You've accurately diagnosed the experimental nature of this exercise. I wondered to myself, "is it _possible_ to operationalize the GNU Maintainers' Guide's definition of 'legal significance'?" I would feel better placed to propose reform of the GNU Project's copyright attribution practices if I first earnestly attempted to apply the existing ones. > 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. Right. I certainly don't want to "cheat" anyone out of anything. Applying the "legal significance" rule robotically, as at least one case shows, meant making a copyright claim for myself over a narrower range of years than had been present. I don't think I'm quite done with this experiment, but I'm forming some preliminary findings in my head. > 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. I appreciate it, and I encourage further exploration and discussion. Regards, Branden [A] https://lists.gnu.org/archive/html/gnustandards-commit/2013-10/msg00000.html [B] https://wdwnt.com/2025/09/judge-overturns-previous-ruling-disney-found-guilty-again-of-copyright-infringement/ This case could still go the U.S. Supreme Court. If Disney appeals, I expect a disposition via the emergency docket.[C] Whether the outcome is in Disney's favor, I predict depends on whether Enemy of the State Jimmy Kimmel's show is suspended again by that time.[D] If Disney does the right(-wing) thing and yanks him off the air again, I predict a per-curiam GVR (grant, vacate, remand)[E], without dissent, because on copyright issues, "liberal" justices are worse than useless.[F] [C] https://afj.org/article/i-know-what-you-did-last-summer-tales-from-the-supreme-courts-shadow-docket/ https://www.scotusblog.com/2025/09/is-the-emergency-docket-really-for-emergencies/ https://www.ncsl.org/state-legislatures-news/details/shadow-docket-looms-large-at-the-supreme-court-this-term https://www.democracydocket.com/analysis/federal-judges-supreme-court-trump-emergency-orders/ [D] https://www.bbc.com/news/articles/c203n52x1y9o [E] https://scholarlycommons.law.case.edu/cgi/viewcontent.cgi?article=1270&context=caselrev [F] https://en.wikipedia.org/wiki/Eldred_v._Ashcroft [G] without a "full stop", because, I suppose, every prestigious U.K. publisher imagines its best life lie in printing red tops [H] https://www.copyright.gov/title17/92chap5.html [I] https://corpgov.law.harvard.edu/2012/06/26/the-shareholder-value-myth/
signature.asc
Description: PGP signature
