Hello Branden,
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.
> 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.
[...]
> 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.)
[...]
> _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. ;-)
[...]
>> 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".
What else could it possibly mean?
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 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". 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. 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.
[...]
> 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. 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.
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 .
> 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".
Yes, i agree with all of that analysis.
> However, no one has, as
> yet, proposed one, 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.
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.
> 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
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.
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.
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.
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.
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.
So, all in all, a few points in HACKING aren't perfect, but i
see no major defects.
[...]
>> 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 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. 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 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 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.
[...]
>> 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 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.
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.
Yours,
Ingo
