Hi Erik, Phong, & Ingo, [first, a digression on assembly language]
At 2026-10-27T02:42:59+0000, dvalin--- via discussion of the GNU roff typesetting system and related software wrote: > On 26.10.26 16:10, G. Branden Robinson wrote: > > At 2026-10-26T13:55:20-0500, G. Branden Robinson wrote: > > > Ease of understanding is not particularly correlated with creative > > > effort. Assembly language mnemonics are not readily understood by > > > most people in the world, but they tend to perform operations so > > > simple that they are not copyrightable. If that weren't true, > > > microprocessor architects could not clone another manufacturer's > > > CPU. > > > > <loud buzzer sounds> > > > > This is of course not true. Microprocessors decode instruction > > formats, not assembly language mnemonics. > > Having hand encoded microprocessor opcodes in the late 1970s, I see > them and their mnemonics as no more disparate than optical isomers, so > I fail to see any incoherence in the original wording. Conflation of > the two representations of the common semantics shortens the > paragraph, sparing the reader, I think. That may be so, but the fact remains that an instruction decoder does not process anything like a sequence of encoded characters that we'd represent as "LD" or "MOV" or "FENCE.RW". At the same time, there is supposed to be a one-to-one mapping[1] between an instruction and its representation in assembly language.[2] > Having written a couple of simple assemblers, one cross, one native, > I'd say that the latter, running in ROM, did indirectly allow the > microprocessor to execute mnemonics, by it's own actions, even if not > intrinsically, or by runtime interpretation. I.e. that was the > communication with it. That is certainly a seductive way to think about it, and an easy and nearly cost-free illusion, because it's hard for a CPU's toolchain to survive for very long if its assembler is not highly reliable and deterministic. Long ago, a mentor at the university computing center suggested to me, somewhat in jest, that the only _real_ programming was microprogramming. To practitioners of that discipline, hackers writing assembly language or optimizing compilers are doing something as frivolous as tweaking a Web site's look and feel with node.js. > > Microprocessor programmer's manuals invariably (in my experience) > > list mnemonics alongside instruction formats. > > > > Possibly the fact that assembly is useful primarily for > > human-to-human communication is why Intel thought they could plant a > > stake in the copyrightability of a set of mnemonics. > > Yes, maintainability improved, but so did productivity, through > assembler mediated instruction construction. > > And via a disassembler, machine to human communication is much > improved when poking about the code actually loaded onto a > microcontroller. Even when C source is listed, nothing but hex in > between would be a nightmare. Add compiler optimisation, and it's even > more uphill. I agree. Some of the first programming I ever did was poking hex bytes into memory. A point I find worth pondering is that the RISC-V instruction set doesn't implement a "full" set of integer comparison instructions: EQ, NEQ, LT, LEQ, GT, GEQ, and so on. It implements only the ones that are strictly required and the assembler flips the operands and switches an open interval to a closed one for the others. I've wondered how much harder that makes life for programmers reading disassembled RISC-V code. A significant amount of opcode space is available for "hints", but I don't know that any exist to clarify these instructions. > > > For a time in the 1970s, Intel Corporation claimed copyright in > > > assembly language mnemonics themselves, considered separately from > > > the machine language instructions they represented. That's why > > > the Intel 8080-compatible Z80 microprocessor by Zilog used > > > different mnemonics, such as "LD" and "ST" instead of "MOV". > > > However, Intel proved unable to sustain this position.[B] > > > > I looked into this, and while not dispositive (nor likely the sole > > factor), apparently Intel lost a lawsuit against NEC regarding its > > V20 (enhanced) clone of the 8086. > > > > Maybe other folks can throw some light on the issue. > > My biggest bugbear was when source and destination operand order > swapped between chips' assemblers. That caused me more coding errors > than new mnemonics, which only took an hour and a coffee or two before > starting coding on a new chip with a different instruction set and > register complement. > > Endianness variation can be hidden with an assembler macro or two in > most cases. And where I don't like a mnemonic, or need a new one, I > add one with a macro. An example of both for an (8-bit) ATmega: > > ; Data Pointer (or any word value) initialisation of a register pair. > ; Usage: ldiw Y,some_data ; ld r16,Y ; OR lpm > r16,Y if some_data is in flash. ; WARNING: No skip instruction can > bridge this shorthand for two instructions. > > .macro ldiw reg,addr ldi \reg,lo8(\addr) ldi (\reg + 1),hi8(\addr) > .endm > > (The Y register pair is R28,R29) > > Again, both productivity and maintainability improve with the > abstraction. (So, maybe, it's turtles all the way down.) Yes. Perhaps the central challenge of the programmer's art lies in defining good abstractions and describing them well. At 2026-10-27T13:45:50+0900, Nguyễn Gia Phong wrote: > Hi, > > On 2026-10-26 at 13:55-05:00, G. Branden Robinson wrote: > > At 2026-10-26T16:19:18+0100, Ingo Schwarze wrote: > > > One thing that seems very unlikely to matter in court is the FSF > > > "15 lines changed" rule. > > > > These points may be true, but I don't find them relevant. I don't > > know if there is only one reason for the FSF's "15 line rule", but > > if there is, I suspect it has to do with reducing administrative > > overhead, particularly in keeping the wheels of contribution greased > > for the relatively large number of people who submit one-line fixes. > > > > By insisting upon copyright assignment, the FSF created a > > high-friction, high-overhead process for itself, [...] So if you set > > a threshold below which copyright assignment is deemed unnecessary, > > you dramatically decrease the volume of copyright assignments you > > have to process. [...] > > > > If someone wants to undertake the draft of such a policy, I note > > first that they should (1) review my survey of copyright issues in > > groff's "HACKING" file and (2) be advised that I'm unlikely to want > > to adopt a new "threshold" practice before I've finished conforming > > the groff code base to my understanding of the existing one. > > While I share the same understanding about the intention behind > the 15-line rule, for the purpose of copyright assignment, > let's quote a couple lines below: > > > Keep in mind, however, that a series of minor changes > > by the same person can add up to a significant contribution. > > What counts is the total contribution of the person; > > it is irrelevant which parts of it were contributed when. I'm aware of that and have used it to guide some of my copyright notice revisions. Example: commit be12b970ef98c533e89942da36f46c2ae29e5ab1 Author: G. Branden Robinson <[email protected]> Date: Sat Dec 20 20:46:47 2025 -0600 contrib/sboxes/sboxes.am: Revise legalese. Update copyright and authorial notices. ... Did Ingo make any single commit to this file that contributed at least 15 lines of code, on net? No. Has Ingo inserted more than 15 lines, _not_ counting deletions? Yes; 14+1+1+2=17. Ingo's deleted 16+6+1+2=25 lines total. So, under one of the simplistic "cumulativity" analyses I've proffered in commit logs--and let's be candid and acknowledge that simplistic analyses are the first and often only ones engineering managers reach for--Ingo's "contributed nothing" to this file, a determination that I find unpersuasive, and moreover insulting to volunteer contributors. At least one fact is easy to decide: if Ingo has copyrightable changes in this file, we can date them all to 2022. Count the small blessings. I'm leaving out a notice for Ingo for the time being because I cannot justify it on the basis of the guidance in the GNU Maintainers' Guide. In my opinion, that document should offer more guidance on matters like this. But I'm disinclined to spend further cycles on trying to develop such guidance (and which I'd need a copyright attorney on tap to consult with anyway) without pecuniary incentive. Deciding (or punting on) this sort of issue is not a rewarding aspect of a GNU maintainer's job. None of the foregoing derogates Ingo's contribution to groff or to this file, specifically. I value portable make(1) files and I'm sure some of our users do, too. We just need to get pattern rules into BSD makes. ;) [1] "A change of just a few lines (less than 15 or so) is not legally significant for copyright." Conversely, >= 15 lines would be. https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html For the most part, I have refrained from "cumulativity analysis", for the simple reason that our copyright notices are already inaccurate enough without it, or, in other words, lots of them need updating to reflect contributions of 15 lines or more. It seems more important, and is easier and faster (while still not low-effort) to update the notices to record the facts of contributions that are clearly "legally significant" under the FSF's rubric by dint of a single commit. > On the matter of "Copyright Notices", the same manual also has > a section, which noted > > > You should maintain a proper copyright notice and a license notice > > in each nontrivial file in the package. (Any file more than > > ten lines long is nontrivial for this purpose.) [...] A GNU GPLv3 license boilerplate all by itself runs to about 12 lines. I presume that the foregoing recommendation means to exclude content that isn't already author/copyright/license/warranty disclaimer boilerplate. "Ten lines long" is a problem I'll return to momentarily. > > But if contributors are not all assigning their copyrights > > to a single copyright holder, it can easily happen that one file > > has several copyright holders. Each contributor of nontrivial text > > is a copyright holder. This is fine. > > In that case, you should always include a copyright notice in the > > name of main copyright holder of the file. You can also include > > copyright notices for other copyright holders as well, and this is a > > good idea for those who have contributed a large amount and for > > those who specifically ask for notices in their names. I think the foregoing advice suggests that contributors are best arranged into two tiers, with a "main copyright holder" (presumably the Free Software Foundation, Inc.) above and a second tier below comprising all contributors who have petitioned for recognition of their contribution of a "large amount" of work, where "large amount" is nowhere defined and thus presumably left to maintainer discretion. I reject that advice. It's much too subjective and practically encourages neglect of notices for non-FSF copyright holders. > > (Sometimes the license on code that you copy in may require > > preserving certain copyright notices.) But you don’t have to > > include a notice for everyone who contributed to the file (which > > would be rather inconvenient). Oh, boo hoo. "Rather inconvenient". Who wrote this? This sounds like a post hoc rationalization of utter indifference to contributions that didn't accompany assignment of copyright. Get the F outta here. I propose a more egalitarian approach, and am trying to practice it in groff: 1. There's one metric for "legal significance". 15 lines, excluding the aforementioned boilerplate. Line length doesn't matter. Blank lines count. 2. The same significance analysis applies to _all_ copyright holders. 3. The 15 line rule applies to all "chunks". A contribution meriting a copyright notice in a standalone file because it was 10-14 lines long (less boilerplate) doesn't become "legally insignificant" because it was copied or moved to the interior of another file. Why on earth would that be the case? I think this set of copyright guidelines was not carefully thought through and I challenge its author to publicly defend the flagrant inconsistencies of his decisions. 4. We don't have to get the copyright notices perfect on the first try and keep them perfect at every point thereafter. As several of us have pointed out in this discussion, the facts of copyright inhere in a work regardless of whether we recognize them with accurate notices or not. It is indeed tedious to undertake "significance analysis", especially if notices have been left neglected for a long time, or worse, have been subjected to mindless, robotic "bumping", egged on by scripts in gnulib, that erases evidence of file stasis. But maintainers should conduct themselves with integrity, which means not privileging some copyright holders over others because it would be "rather inconvenient" to recognize some contributors. Know who else found it "rather inconvenient" to recognize contributors other than himself? Eric Raymond. https://invisible-island.net/ncurses/ncurses-license.html > In other words, the test files might be spared from a copyright > notice, and the principles noted in the HACKING file aligns with GNU's > recommendations. They _might_ be, sure, but I find it useful for short files below the threshold of "legal significance" in groff to contain a "provenance notice" if the file's syntax permits. This notice is deliberately very similar to the copyright notice, so that it is less work for maintainers if a file crosses the significance threshold one or the other. That remains true even if I am succeeded (or deposed) as maintainer and someone decides to apply different standards, perhaps claiming greater fidelity to the GNU Coding Standards on copyright that I assess as deficient. In other words, I'm trying to make the work of future maintainers easier even if they disagree with my practices. > Do note that the threshold is slighly different, though, Right. I perceive no justification for a different threshold, and while I don't have a case citation handy, I'd venture that any proffered justification would have a tough row to hoe. By the same implicit reasoning backing the disparate 10/15 line thresholds for new/existing file, a publisher preparing an anthology of short poetry or fiction could claim that certain works collected within are "too short" to be "significant", and therefore their authors are not entitled to any royalties arising from sales of the collection. _I_ think attorneys for the affected copyright holders would come down on such an argument with both feet, and that U.S. federal judges would not hesitate to join in the stomping. But a person should retain the services of an experienced copyright lawyer if they want an opinion that's worth anything. > and the copyright notice is different from the register of copyright, > per "Recording Contributors": I don't see why it should be. > > Only the contributions that are legally significant for copyright > > purposes (...) need to be listed. [...] > > > > Please keep these records in a file named AUTHORS in the source > > directory for the program itself. groff's "AUTHORS" and "THANKS" files are sadly empty; I think this is because the groff project is so old that it wasn't yet common practice (or maybe just GNU policy) to maintain these files until well after groff became mature. I have ideas for re-populating these files. 1. Once I've finished my "legally significant" copyright audit of groff, which will be marked by the disappearance of the "(C)" trigraph from our copyright notices, it should be straightforward to sed all the notices extant in the tree and extract a unique set of names. I also have a list of contributors to groff who executed copyright assignment paperwork with the FSF. Each such person would merit a scan of the source history for "significant" contributions--I know already that a small number of people executed the assignment but did either not contribute a "significant" amount of code, or any at all. Between those two lists, it should be possible to produce an accurate "AUTHORS" file that names only humans who have made "legally significant" contributions. 2. "THANKS" could be easily populated by extracting the "Acknowledgments" from recent groff release announcements and "sort -u"-ing the resulting list. A scrupulous and historically-minded person might trawl our ChangeLog files for pre-1.23.0 releases for additional names we might add. 3. Contributors who didn't meet the criteria for "AUTHORS" and who didn't already appear in "THANKS" would be added to the latter file. At 2026-10-27T08:39:03+0100, Ingo Schwarze wrote: > G. Branden Robinson wrote on Mon, Oct 26, 2026 at 01:55:17PM -0500: > > At 2026-10-26T16:19:18+0100, Ingo Schwarze wrote: > >> Looking at this particular file, my assessment is: Writing this > >> file created Copyright, because the content is clearly non-trivial > >> and amounts to a creative work. It does not matter whether the > >> creative work is particularly difficult, there only needs to be a > >> creative work at all. > > > In U.S. copyright, there needs to be more than a de minimis amount > > of creativity, as I understand it, but there is no rule permitting > > measurement of creativity.[A] > > Yes. And as far as i understand (IANAL), that's not specific to U.S. > law, but holds in International Law as well. That's my (lay) understanding too. > > My use of widely recognized placeholder text like "FOO", "BAR", > > "BAZ", and "QUX" was in fact a calculated _avoidance_ of creativity. > > Well, the creativity in this file is not in individual words - as you > say, any random words would do - but in the complex, syntax-rich > expressions like > output=$(printf '%s\n' "$input" | "$groff" -z 2>&1) > groff="${abs_top_builddir:-.}/test-groff" > and in the multi-line assignment of the input variable. > > For that reason, i am quite convinced the amount of creativity > is sufficient to overcome the quite low "de minimis" bar. > And even if there is merely some doubt that maybe it could, > better name the Copyright holder if there is a chance that > someone might reasonably regard the work as Copyright-worthy. I am _not_ thus convinced, but I don't feel passionately about the issue. If I'm wrong, then I "deserve" a copyright notice but am not "awarding" myself one. I don't regard that as a great sacrifice; there are plenty of other files in groff upon which I have now made an impact that is "significant" not only by the 15-line metric but by others. > > However, I failed to write an annotation explaining this in the test > > scripts, and moreover named the scripts poorly. > > If you add comments explaining what the file is testing and/or how > it is testing that, the case that the file gives rise to Copyright > becomes even stronger, because such a comment would consist of > non-trivial text. (Of course, that's no reason to write or to not > write such text.) Agreed. By the time I get (or someone else gets?) around to enhancing this script such that it checks not just that use of the `hpf` and `hpfa` requests don't send the parser into an inappropriate state, but the correct operation of those requests as well, I predict that the two scripts will grow sufficiently that they merit a copyright notice by the 15-line significance metric anyway. > > _If_ I possess a copyright in the file, then it is undisturbed by > > the lack of a notice, I agree. That's been the law since 1989. > > Unless i'm mistaken, in International Law, that has been true > since 1886 - the U.S. was a bit late to come into compliance. ;-) So it seems! I don't know the history behind this. > >> If you own some right, saying "I do not own that right" (as you do > >> in the commit message) > > > But I did _not_ say that. I said that the scripts (minus > > boilerplate) aren't "legally significant" according to FSF policy, > > and moreover I put that term in scare quotes. > > Here is where you said that: > > [ from the commit message ] > > The "meat" of these tests is fewer than 15 lines, so it's not > > "legally significant".[1] > > [1] See groff's "HACKING" file, section "Updating Copyright > > Notices". > > The only meaning of "not legacally significant" i can think of > is "so minimal that Copyright does not actually arise". Nope. > What else could it possibly mean? "Not legally significant" is a GNU Coding Standards metric that a maintainer can use to decide whether undertaking a copyright analysis is necessary or expected to be worthwhile. That metric does not decide copyrightability itself; it cannot. Lowly software engineers are not qualified to determine the latter. That's for the people in black robes or white shoes. > Besides, those are not "scare quotes", those are normal quotes marking > a citation. You even specify the text you are quoting from: > the HACKING file. The operator could be overloaded here. ;-) > The HACKING file is not very clear what "legally significant" > is supposed to mean in the context of that file, but it quotes > https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html > which also does not provide a rigorous definition of the term, > but which does provide sufficient context making it almost certain > that it is intended to mean "sufficient amount of text and creativity > that the respective author owns Copyright". Not quite correct; see above. > Also, note this sentence in that page: > > If a person contributes more than around 15 lines of code and/or > text that is legally significant for copyright purposes, we need > copyright papers for that contribution, as described above. > A change of just a few lines (less than 15 or so) is not legally > significant for copyright. > > The first sentence explicitly says that a change can be legally > significant even if it is shorter than 15 lines. Yes! > The second sentence makes it clear by using the words "or so" that 15 > lines is not a precise cutoff, not even by FSF guidance. Also correct. But I'm interpreting it precisely in part because I'm _not using it to decide whether copyright inheres in a contribution/ diff/patch_. I'm using it to make the work of making a first iteration of correction/update of groff's copyright notices a tractable task. Executive override is always possible, and I have used it on several occasions to disqualify changes in excess of 15 lines (net) from qualifying for a copyright notice. Here's a typical example. commit d1df9748854bcf4cbe71cb28cc3a74ff137e0d5e Author: G. Branden Robinson <[email protected]> Date: Fri Oct 9 00:07:59 2026 -0500 soelim(1): Revise copyright notice. ... (Bernd Warken's commit c1886fcaa3, 2014-09-18, is a sadly complex case. It added 31 lines net, which would be "legally significant". Its summarized purpose is to "improve the license information", but the committed change does not restrict itself to that task. It also adds comment banners and empty requests and makes other cosmetic changes, like changing the locations of input line breaks without altering the text around them. I think the balance of the analysis is solidly against significance, but a good commit discipline relieves maintainers of having to undertake such.) > [...] > > I don't know if there is only one reason for the FSF's "15 line > > rule", but if there is, I suspect it has to do with reducing > > administrative overhead, particularly in keeping the wheels of > > contribution greased for the relatively large number of people who > > submit one-line fixes. > > According to my understanding, the point is that the FSF wants to > own *all* of the Copyright on GNU projects, such that the FSF can > sue over GPL violations without needing the consent of any contributor > or author. I recall reading that as a stated rationale, and it may still be present somewhere on the fsf.org or gnu.org websites. And in the late 1980s or even through 1990s, it might even have made sense. But now, multiple "umbrella" organizations exist and some, unlike the Linux Foundation, are unafraid to litigate. > Consequently, if an author contributes text that gives rise to > Copyright in that author (which is the same as that contribution being > legally significant), the author has to assign Copyright. On the > other hand, if the contribution is de minimis, which is typically the > case for those one-line fixes you mention and for a few more, that's > not needed because there is no right to sign over in the first place. Yes, that's consistent with the FSF's reasoning, for projects that continue to require copyright assignment. groff does not, and has not since before I showed up. > That doesn't seem all that hard to understand to me. Assuming > that "gives rise to Copyright" and "legally significant" refer to two > different concepts for two different purposes would make no sense > to me, in particular not in the context of > https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html > . I disagree with you for the reasons stated above. We can do all the analysis and documentation we want, and a court could throw it all out. So we're well advised not to chase the long tail of minor contributions. [...] > > However, no one has, as yet, proposed [an alternative threshold of > > "legal significance"], let alone one sufficiently rigorous to > > satisfy my needs as a copyright notice janitor. > > Well, i have - use your judgement whether something is trivial, > and in case of doubt, list the main author of the file in > a Copyright line. As simple as that. I don't think you have proposed an alternative _threshold_. Your interpretation of what that threshold _decides_ differs from mine. And I happen to agree that an "executive override" of the threshold analysis is always available, and that a maintainer should exercise it where warranted, in both positive and negative senses. In the negative sense (denying significance), I have the Bernd Warken example above. In the positive sense, if I threw, say, 13 lines of my own carefully composed, dense prose into a test artifact, I might be sad if someone asserted that I had no copyright in it. > Less importantly (but that's a different matter) even when you are > sure the file is below the Copyright threshold, still list the > author, saying something like "The author regards this file as > trivial in the Copyright sense" or "put into the public domain" > or something similar, just to make authorshipand intent clear. I don't think that's necessary in most cases. That's what we have the threshold for. If a contribution falls below the threshold but "executive override" determines that it's too likely to be copyrightable anyway, then, yes, the thing to do is put the contributor on the spot and identify the terms of their contribution. We did something similar with rfc1345.tmac, which Dorai Sitaram contributed. Arguably, it wasn't necessary because the macro file is pretty much just a big 1-to-1 map generated by some tables in an RFC to Unicode code points. But the line count was so large that, in the event a copyright _did_ attach, we wanted a GPL-compatible license on it. And Dorai readily supplied us with one. This process was not onerous or time-consuming. > I agree with almost everything in the "Updating copyright notices" > section in that file, with very few exceptions of limited importance. > > The main exception is that the FSF "15 lines changed" rule feels > slightly overstated to me in that file. The FSF is not saying "put > a Copyright notices for changes of 15 lines and more, and no Copyright > notice otherwise". It instructs to put a Copyright notice and > assign Copyright if the change is big and creative enough to establich > new Copyright, and not do so otherwise. I read the FSF 15 lines > rule more like "if it's more than about 15 non-trivial lines, it > probably establishes new Copyright, but occasionally, that may also > happen with fewer lines." > > So this is a bit too strong: > > Organizations like the FSF establish thresholds like "15 lines > changed" to ease their own administrative procedures, but no such > criterion is binding upon a court deciding a question of copyright > law. > > That sounds like a strict rule, which it isn't. But at least it > clearly says this doesn't change the legal situation, so it's at > most minimally misleading. I don't understand your objection, but I think it may arise from your misconception of what I think the 15-line threshold decides. To reiterate: The 15-line threshold governs the default level of analysis we (I) will undertake to infer the copyrightability of a contribution. It does not decide whether the contribution _is_ copyrightable. We're not qualified to do that. All we can do is make claims, which attorneys and judges may someday consider with an eye that might be influenced by the level of diligence we appear to practice. > This is also too strong: > > The GNU Maintainers' Guide's threshold for a "legally significant" > change is 15 lines. > > But the very next sentence corrects it: > > "A change of just a few lines (less than 15 or so) is not legally > significant for copyright." > https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html > > So, again, at most minimally confusing. Eh? Do we need to construct the reals here? Maybe the problem is that you find my use of the term "threshold" ambiguous. I use it in the sense of a closed interval: if you are "at" or "on top of" the threshold, then you have tripped the condition that it governs. (This is the sense in which I used the term in groff_mm(7), which has many registers that behave this way.) I can walk "up to" the threshold of my house's (closed) front door, from the inside. If I then open the door and stand atop the threshold, then I am "outside". (This assessment is consistent with my childhood experiences of older relatives yelling at me to close the door because I am "letting the outside in".) > This paragraph feels irrelevan to groff: > > Where a change produces a net increase of 15 lines or more but > _still_ seems robotic or unoriginal, consider (1) applying the > annotation "Copyright-paperwork-exempt: yes" to the Git commit log > message, and (2) recording, in the corresponding commit log message, > the robotic procedure that produced the change. I've used "Copyright-paperwork-exempt: yes" before in a commit message, but admittedly not in its literal sense since the groff project doesn't require execution of copyright assignment paperwork. Possibly I should just drop item (1). Item (2) seems anything but irrelevant. If we can produce a change with a robotic procedure, that weighs against the copyrightability of the change, no matter how "large" it is. > This is too narrow: > > When adding a new file to groff, include a copyright notice only if > it is "legally significant" per the 15-line threshold. > > It should be: "... only if it includes 15 lines of code or text > or is otherwise legally significant" or something like that. Phong might argue that I should use the GNU Coding Standards' 10 line threshold in this case. > I regard the "Copyright protection is..." paragraph as not very > relevant, somewhat U.S.-centric, and potentially in parts somewhat > misleading in other jurisdictions, but that's not a big deal. In my experience, software engineers, especially ones of considerable ability, have a shockingly poor understanding of copyright. I say this because I know that my own is insufficient for me to practice law in that area, but in past workplaces I have seen "10x" hackers routinely make proclamations about copyright law that are howlingly wrong. I know because I saw their claims get corrected by corporate counsel. My favorite story is this: ---snip--- "Errogant: When you're completely wrong, but you're also totally certain about it." One of the best cases of this I've encountered was with a $FIRM Distinguished Engineer or Fellow on a conference call. Dude was so sure he understood copyright law and copyleft licensing, and got it just painfully wrong. ($FIRM had somewhat famously recently settled "the $SUBSIDIARY_FIRM lawsuit" with the Free Software Foundation.) I wasn't the only one on the call who knew that this Rock Star Programmer was wrong. When gently corrected (not by me, as I recollect), he simply retrenched. A silent consensus formed that he would simply not be invited to any further conference calls on the subject. And he wasn't. A decade-plus later it occurs to me that maybe dude DID know what was correct and deliberately adopted an incorrect position inflexibly on purpose. So that he wouldn't be haled into more damn conference calls he didn't care about. Dude REALLY WAS smart! ---end snip--- > > It exposes me to charges of hypocrisy and self-serving > > administration if I stuff copyright notices for myself into files > > that fall below the 15 line threshold while stripping them from > > other files falling below the threshold but which bear copyright > > notices by other parties. > > I have never encountered the opinion that putting a Copyright notice > on a file one has actually authored might be considered legally or > morally objectionable, not even if it later turns out that the file > does not actually reach the minimum threshold of length and creativity > required to give rise to Copyright. Consider yourself fortunate. Though in my case it wasn't so much a matter of someone _arguing_ that my work didn't merit copyright protection. He (Daniel Stone) simply removed my notices. XFree86 was old and busted and X.Org was the new hotness: such a revolutionary development--with which he was closely associated of course, as a major exponent of Forward Progress--that nothing I had done merited notice. > Given that court opinions about Copyright typically involve judgement > calls about vague legal concept like "de minimis" and "creativity", > regarding such notices as objectionable would be impracticable because > it is unavoidable that authors will sometimes feel differently than > courts. As long as no deceptive intent is involved, i don't see > anything to object to, and naming the author is almost always useful > for clarity, no matter whether there is Copyright or not. I agree, but I think you underestimate the pettiness with which hackers will conduct themselves. Especially when they're chasing that "10x" label for themselves. > I didn't mean you should put your own Copyright notices on small but > non-trivial files and remove other's Copyright notices from small but > non-trivial files. I meant when a reasonable person *might* think the > file could maybe reach the Copyright threshold, then don't remove the > notice, no matter whether it's your own or someone else's. I have a hard enough time deciding what my _own_ reasonable opinion should be to game out a whole bunch of alternative reasonable opinions when I'm not engaged in a colloquy like this one, but shoveling administrative coal instead. For that, if the issue is one that can be corrected with little effort later, I employ a different approach. Document the premises. Turn the crank. Move on. > > I believe the groff project deserves a maintainer who conducts him- > > or herself with an evidently high level of integrity. > > I did not intend to call that in question, and i don't think anyone > else voiced any concern about your integrity either. No. No one here did. But I've had to defend myself before. > [...] > >> A Copyright line eats no bread. > > > It does here, when it opens me to spurious claims of self-dealing. > > I don't see how stating your authorship in a file you actually wrote > could expose you to any accusation of self-dealing. Not even if some > people think it might perhaps be under the Copyright threshold. That's good! May you never have to witness such a spectacle. > > That said, I haven't done a comprehensive "sweep" of the code base > > to strip my own copyright notice out of other short test scripts. I > > fix problems like this as I happen across them. > > Sure, that's a sound practice. > > I'm not addressing your assembler comparison because you did not try > to assert Copyright on the macro name ".pi" that (IIRC) you recently > invented (nor do i think a macro name _could_ give rise to Copyright). > This is about complete text files, not about individual assembler > instruction names or request names. For the benefit of readers, you're referring to this commit. commit 071f266af84a5b193d0111e3b8be3d5e24038be9 Author: G. Branden Robinson <[email protected]> Date: Wed Oct 21 23:10:21 2026 -0500 [troff]: Implement new `.pi` register. ...for orthogonality and to make the output filtration pipeline readily inspectable. * src/roff/troff/input.cpp (pipe_command_reg): New file-local class handles dynamically computed data. (The class `readonly_text_reg` is not appropriate because it has _static_ contents that are computed once only, at formatter startup. The global `pipe_command` is populated, and can be updated, by the input stream--until output commences.) (pipe_command_reg::get_string): Member function returns `pipe_command` (a C string). * doc/groff.texi.in (Host System Service Access): * man/groff.7.man.in (Read-only registers): * man/groff_diff.7.man (New register): Document it. NEWS: Add item. > If you feel more comfortable rigidly sticking to some 15 lines rule > (even though i don't think that's what the FSF means, and even though > i think that rigidity makes your job harder rather than simpler, while > also being less useful than just making common-sense judgement calls), > i'll let the matter rest, i merely intended to note that this feels > slightly suboptimal to me. Understood. I might eventually find my way to a new process that feels easier to administer. Regards, Branden [1] Or something close to it. Often, there are many equivalent ways to encode "no operation". But many subtleties exist here. If the processor uses a flags register, does loading a register with itself (e.g., "MOV AX, AX") update those flags or not? [2] Another big hole one can blow in my "one-to-one mapping" claim is that many assemblers implement evaluators for integer arithmetic, and that of course means that there are many equivalent representations of quantities like address offsets and immediate values, because you can "always" add "+0" to an integer expression.
signature.asc
Description: PGP signature
