Hi Ingo, At 2026-10-26T16:19:18+0100, Ingo Schwarze wrote: > i regard the following as a bad idea - not as a major problem, though.
For the benefit of others, here's some background. The commit in question is <https://cgit.git.savannah.gnu.org/cgit/groff.git/commit/?id=35d9f39e0bc686118e52ed5cf1a75ee588cddceb>. I originated the files earlier this year. Here is what they contain, less comments on provenance ("this file is part of groff"), licensing ("this is under the GPL"), and a Vim modeline. ---snip--- groff="${abs_top_builddir:-.}/test-groff" input='. .hpf .tm FOO .hpf hyphen.en .tm BAR .' output=$(printf '%s\n' "$input" | "$groff" -z 2>&1) echo "$output" echo "$output" | grep -Fqx 'BAR' ---other file snip--- groff="${abs_top_builddir:-.}/test-groff" input='. .hpfa .tm BAZ .hpf hyphen.en .tm QUX .' output=$(printf '%s\n' "$input" | "$groff" -z 2>&1) echo "$output" echo "$output" | grep -Fqx 'QUX' ---end snip--- > 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. I 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] My use of widely recognized placeholder text like "FOO", "BAR", "BAZ", and "QUX" was in fact a calculated _avoidance_ of creativity. > I would even argue that the text of the file is quite complicated, > so much so that staring at it for some time, i did not immediately > understand what exactly it is even testing. 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. 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 suspect the test cases are hard to understand because they're not testing the operation of the requests per se, but the absence of a parser bug such that the parser got into a surprising (and incorrect) state after reading the file name arguments to these requests. However, I failed to write an annotation explaining this in the test scripts, and moreover named the scripts poorly. These are failures of software engineering, not copyright practice. :) > So i have no doubt you own Copyright on this file. > > In that case, what does removing the Copyright line accomplish? > It does not change the legal situation. Whether Copyright exists > does not depend on the Copyright notice but on the properties > of the Works and on who created it. I agree. > So even after deleting the notice, you still own the Copyright. _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. > Consequently, all the removal accomplishes is making it harder for > people to figure out who owns the (obviously existing) Copyright. I don't think its existence is obvious. > If it ever goes to court, it might even cause legal confusion, as in > what did the Copyright holder mean by deleting the notice? Consistent application of the "15 lines' legal significance" principle articulated by the GNU Coding Standards, as noted in the commit message. Moreover, in the unlikely event groff's code is ever litigated in court, it would take poor lawyering on both sides to fail to produce this publicly posted email in discovery. > 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. The scare quotes could suggest that the phrase is not a recognized term of legal art, or that I practice compliance with a policy that I don't necessarily agree with, or would like to see made significantly less vague. Let's review the actual commit message. ---snip--- [groff]: Drop copyright notices from small tests. * src/roff/groff/tests/hpf-request-works.sh: * src/roff/groff/tests/hpfa-request-works.sh: Do it. 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". ---end snip--- Please point out to me where in the foregoing I disclaimed copyright. > does not make that right go away, so you still own that right. Does > deleting the notice mean that you still want to grant the same rights > as before under the GPL, or does it mean that you wanted to change > something, and if so, what? I certainly would be annoyed having to > argue such questions in court, or having my lawyer waste time on that. The project is copyrighted _as a whole_, as the FSF has (as I understand the law) correctly maintained over the years, and its license is the GNU GPLv3. The project's top-level "LICENSE" file, and the output of "groff --version", articulate this point. Werner Lemberg clarified this issue with Colin Watson in 2004, long before I began contributing to groff. https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/LICENSES?h=1.24.2 https://salsa.debian.org/debian/groff/-/blob/master/debian/copyright?ref_type=heads > One thing that seems very unlikely to matter in court is the FSF "15 > lines changed" rule. I have a hard time imagining any court ruling > "the FSF says less than 15 lines, this is 12 lines, so there is no > Copyright" - neither under _Feist_ nor in some other jurisdiction > outside the U.S.. > > On top of that, _Feist_ says: > > The constitutional requirement necessitates independent creation > plus a modicum of creativity. > > It seems very obvious to me that creating this file involved > both "independent creation" and a "modicum of creativity". 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, because copyright assignments, in the U.S. at any rate, are generally thought to be valid only if executed in written form, possibly sealed by a notary public. But some kind of power law seem to apply to the magnitude of programming contributions when measured in lines of code. 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. That in turn reduces both the amount of FSF back-office labor that needs to be performed by volunteers or paid staff, and the amount of grumbling from the contributors themselves. The groff project, like several other FSF projects including less(1), nano(1), ncurses, GCC, and glibc, does not require copyright assignment. (Some of these projects formerly did require it.) Again, this is a policy reached by past maintainers, already in place when I started contributing. I cannot say with precision when the requirement was retracted in groff. "Before 2018" is as much as I know. Arguably, groff's lack of an assignment requirement makes its overhead lower than the mothership FSF's, and we are better advised to adopt a different threshold of "legal significance". However, no one has, as yet, proposed one, let alone one sufficiently rigorous to satisfy my needs as a copyright notice janitor. 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. As a rule, you can tell if I've reviewed a file in the tree with application of that understanding by checking to see if a "(C)" trigraph appears in the copyright notice. If it does, I have _not_ yet reviewed the file. A tension exists between "simple and dumb" tests that are easily crafted with brief shell scripts--essentially things that a machine judges easily--and the "originality" and "creativity" requirements of copyright law, which machines judge poorly, the claims of vendors of student- cheating-detecting software notwithstanding. > So even under the (non-international) authority you yourself cite, > saying that there is no Copyright is quite obviously wrong. I didn't say there was no copyright. I challenge you to point to any words asserting such on my part. > Now, even if somebody were in doubt whether a particular file > establishes Copyright, keeping the notice costs nothing, guards > against the risk that a court might come to a different conclusion, > and removes any potential doubt whether a license was granted. 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 believe the groff project deserves a maintainer who conducts him- or herself with an evidently high level of integrity. > Even if you are quite sure there is no Copyright You are drawing many conclusions from a false premise. You said earlier in your email that removal of a copyright notice does not constitute abandonment or disclaimer of copyright, and yet then proceed to reason as if it does. > in a particular file because it did not even require a "modicum of > creativity" even though it was an "independent creation", putting in a > line like > > # This file was written in 2026 by G. Branden Robinson > # and put into the public domain. But I _haven't_ put the file contents into the public domain. Had I intended to do so, I would have said so. > is better than putting in nothing because it makes the intent clear in > case someone ever has doubts - even in jurisdictions where putting > something into the public domain is not possible, the clarification of > intent may still help. _If_ that were my intention, I'd agree. The Creative Commons CC0 text is also useful for that purpose.[C] > This is certainly not a big deal, since nobody is likely to sue over > such things (except maybe crooks looking for creative ways to make > money from phoney litigation). Then again, i see clear benefit in > keeping Copyright notices in cases of doubt (more legal clarity and > less risk of legal confusion) and no benefit whatsoever in trying to > follow the "simplified" FSF rule to the letter. I see benefit in administering the policy articulated by the GNU Coding Standards (supplemented by groff's "HACKING" file) in as objective a manner as I can manage, such that my choices are easily reconstructed independently by others. > A Copyright line eats no bread. It does here, when it opens me to spurious claims of self-dealing. 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. If some hypothetical future person should happen to encounter a file where my copyright notice should be dropped under the criteria referenced above, and they bring it to my attention or that of this list, their framing of the defect on a continuum from "innocent oversight" to "wicked, hypocritical maintainer" supplies me with invaluable data regarding the character of my interlocutor. Regards, Branden [A] Attorneys do not reason as scientists and engineers do. Somewhere in Heaven there is a man--or a divine figure--with a long white beard who has written the ideal Law, which all human efforts fail to replicate. While I think a lot of people enter law school with dreams of Mosaic/Platonic idealism in mind, I don't think that attitude survives long in practice, except to be gestured at on occasion in appellate court opinions. Most practicing attorneys and judges, I think, understand the nature of the powers they serve with Kissingerian precision. [B] I've never learned if this was due to losing a lawsuit, receipt of a dubious opinion by its own corporate counsel, or rumblings from major firms like IBM and departments of the U.S. government with huge purchase orders loaded and ready to fire, who insisted upon the availability of a second source or were legally bound to have one under federal law. Intel and AMD later clashed a few times in court, but the question of copyrightable assembly language mnemonics remained dead as far as I know. [C] https://creativecommons.org/publicdomain/zero/1.0/
signature.asc
Description: PGP signature
