Hi Ingo, At 2025-10-23T17:10:21+0200, Ingo Schwarze wrote: > G. Branden Robinson wrote on Wed, Oct 22, 2025 at 07:38:44PM -0500: > > I'm not yet ready to pitch a reform to GNU copyright policy (apart > > from dropping the superfluous '(C)' trigraph). I'm still exploring > > the parameters and consequences of the existing, documented policy. > > If that policy seems to militate for difficult, unworkable, or > > absurd outcomes, then that's a feature, not a bug--for > > evidence-gathering purposes. > > Indeed, you mentioned before that such evidence-gathering is the point > of your current work in that respect. While personally, i would not > have chosen to do such an experiment on a living, real-world > software package (for fear of being accused of animal cruelty),
Who's the animal subject? Me? Just call me Leonid Rogozov... From a research perspective, performing this informal study on a living, real-world software package is, I think, the only way to gather information about the practicality and efficacy of the GNU Maintainers' Guide's copyright policy without any findings being hastily dismissed as hypothetical or unrealistic. I've been in a lot of Internet arguments. People play that card swiftly and often to avoid conceding the presence of defects in existing practice, or disclosing their unsavory reasons for opposing reform. > i do not object to your approach because when i ignore the evidence- > gathering aspect, my impression is that every commit you are doing in > this context is an improvement, so i'm happy to not whine about the > cruel motivation. :-D I'm glad you're liking the results! > > But, in the meantime, a simpler, alternative approach occurs to me. > > Since, as you note, for natural persons, the clock on copyright > > expiry doesn't start running until death anyway, > > Waitwaitwait, while i *think* that is true in *most* countries > as far as computer program code is concerned, now the fact that > IANAL becomes even more relevant. I'm *not* convinced it is > strictly true for all countries. I certainly would not claim that it is without a great deal of research that I'm unwilling to do, and the advice of a competent attorney that I'm unwilling to pay for. > Besides, a free software package may include files where the Copyright > does expire some number of years after creation or publication in many > countries, for example audiovisual or photographic works, and some > kinds of ASCII art (or similar) might perhaps qualify as "applied > art", too. Heck, some source code may be so obfucated that some might > call it "applied art" (though i have my doubts whether or not a judge > in, say, Vanuatu might concur). Fortunately, the groff source has few exhibits of the aforementioned kinds. The only ones I can think of are the image files of Tux the penguin[1] and the line-drawn gnu/wildebeest,[2] and as far as I know the copyrights on those are uncontroversially established. More importantly for the sake of this research project, those files are utterly static--they never change, and so the question never arises of someone else contributing original work to them that might impact the copyright notices we need to incorporate into or accompany them. > Oh wait. The (for serious work) notoriously unreliable Wikipedia > utters the opinion that in Bahrain, the Copyright duration for > computer software might be "40 years from publication or 50 years > from completion, whichever is shorter", whatever "completion" may > mean with respect to software. Are you really planning to make > life miserable for the poor people of Bahrain? Well, (a) no, and (b) my understanding is that international treaties often supersede domestic law. So while the foregoing might be true in Bahrain statutorily, that provision may be subordinated to Bahrain's accession to GATT--if in fact Bahrain did so. I don't know much about Bahrain except that it's a Persian Gulf petrostate. I expect it to have a ridiculously low Gini coefficient and for copyright law to be largely irrelevant there, because any given sheikh can pay whatever they like for copyright licenses, including zero, and almost everyone else in the country is corvée migrant labor without legal rights and without meaningful assets or disposable income to be seized as money damages for copyright infringement. I could be wrong. Maybe I'm thinking of the UAE. > > we could just quit attaching years to their copyright notices in the > > first place. The fact of, and to only a slightly lesser extent, the > > calendar year of a person's death is in almost every case better > > documented and more easily decided than when slowly aggregating > > small-scale changes become "original". Further, since the timer on > > natural persons' copyrights runs for _decades_ following death, > > there is plenty of time to locate an obituary or other documentation > > and to decide the boundaries of their copyrightable work. > > While this argument sounds reasonable on first sight, i'm not > fully convinced even when disregarding Bahrain. Sometimes, a lawsuit > may require proof that a specific natural person did indeed write > specific parts of the code, and in such cases, having at least a > rough first impression who changed the code when may help to speed up > the ensuing detective work. "git log" is better for that, at least back to the point where, in projects like groff, a commit history was synthesized from some other storage format. (In our case, I think, CVS, and before that, a sequence of distribution archive releases.) > Admittedly, not a very strong argument; but still, i think the years > add a bit of flesh to the indicative nature of the notices. They do add "flesh", but also management overhead (and points of DRY failure), hence my suggestion that FLOSS projects could adopt a practice of omitting the years for natural persons. > Besides, there is also the purely moral aspect of giving credit where > it is due, even if there should be no legal consideration. I think having a person's _name_ on a copyright notice completely satisfies a project's moral responsibility to credit its authors. A list of years in the Gregorian calendar, I submit, does not augment the degree of moral satisfaction--especially when combined with the (in my opinion) dubious practice of "bumping" this list to include the current year even when no change at all to a file under copyright has take place. It's not honest, morally or otherwise, to suggest that a person made original contributions to a project in years when they didn't. Further, if they labor under an employment agreement whereby a corporate entity "owns" everything they intellectually produce during the term of their employment, the robotic copyright notice update practices that many projects adopt, within GNU and elsewhere, could lead to grief and wasted time--or worse--for the people one claims to be morally honoring. Granted, the pre-2011 or so GNU practice of demanding copyright assignment from all contributors unwilling to engage in protracted negotiation with Richard Stallman escapes the "jeopardized employee" scenario. (One of the things I learned while doing copyright compliance work for a huge volume of FLOSS projects sucked into the corporate maw was that the FSF's intransigence on copyright assignment was almost always overstated. For evidence, all one had to do was actually read the copyright notices in GNU projects' source code. One can profitably start with glibc.) > I think knowing who changed the code when is often interesting in its > own right. Interesting, sure. And better than nothing--_when you have no alternative record of contributions_. > Sure, that usually doesn't require particularly high precision, but > for example, i think this excerpt from the LICENSE file of the latest > mandoc release gives a much better impression of what was really going > on than removing the dates would: > > Copyright (c) 2010-2022 Ingo Schwarze > Copyright (c) 2008-2012, 2014 Kristaps Dzonsons > Copyright (c) 1999, 2004, 2017 Marc Espie > Copyright (c) 2009, 2010, 2011, 2012 Joerg Sonnenberger > Copyright (c) 2013 Franco Fichtner > Copyright (c) 2014 Baptiste Daroussin > Copyright (c) 2016 Ed Maste > Copyright (c) 2017 Michael Stapelberg > Copyright (c) 2017 Anthony Bentley > Copyright (c) 2022 Anna Vyalkova > Copyright (c) 1998, 2004, 2010, 2015 Todd C. Miller > Copyright (c) 2008, 2017 Otto Moerbeek > Copyright (c) 2004 Ted Unangst > Copyright (c) 1994 Christos Zoulas > Copyright (c) 2003, 2007, 2008, 2014 Jason McIntyre > > For example, the gradual transfer of maintainership from Kristaps > to myself around 2010-2012 immediately stands out, you immediately > see that Joerg Sonnenberger was a regular contributor in the early > years, that Jason McIntyre has contributed in low intensity, but > over a very long time, that Anna Vyalkova contributed one single > major patch, and that the contibution of Christos Zoulas > resulted from reuse of generic code he published much earlier. > > All that seems interesting to me. Like groff, mandoc(1) has something better--its CVS logs. If that's too much detail, then perhaps your project is old and successful enough to have a bit of _narrative_ history written down somewhere that characterizes _what_ each of these copyright holders contributed, not just _when_ they contributed "something". > Also pay attention to the license. If the license requires preserving > the Copyright notice, then i think correcting factual errors in the > Copyright notice is still OK (and, actually, desirable), but whether > removing accurate information from a Copyright notice that you are > bound to preserve is permissible might be a tricky legal question. > I don't rightly know how to judge that particular point... > Maybe better safe than sorry? This is a good point. The U.S. Copyright Office's "circular 3", which I've been citing in my commit messages, lists "the year of first publication of the work" as an essential element of the copyright notice. So my proposal might not fly anyway, depending on what one characterizes as "the work". If it's the whole project, then groff, for instance, could truncate the year sequence in all its copyright notices down to just "1989", and have a simple _list_ of all known copyright holders. If one decomposes "the work" into modules, be they individual files or something coarser--one could make a case for "each directory in contrib/" and "everything else"--some complexity returns. But I see nothing in circular 3 to motivate the robotic "bumping" practice of which I complained above. > > The foregoing is no help for the FSF, which under current law needs > > to start worrying about currently copyrighted bits of GNU Emacs > > falling into the public domain in about 2078. > > By that time, those parts may also fall below the rising surface > of the oceans, i fear. That prospect doesn't prevent corporate-backed "charities", when arriving on boats to evacuate climate refugees, from demanding assignment of all one's "intellectual property" rights, among other concessions, as the cost of passage. You know the expression "it's an ill wind that blows that no one any good"? The genius of capitalism is to find those battered by the winds, and charge them as large a fee as possible for temporary and inadequate respite. Every celebrity entrepreneur follows the example of Marcus Licinius Crassus's Roman fire brigade. "Competition" in the "free market" is a myth programmed into the proles to keep them striving in wage slavery and accepting their miserable lot under the heels of the petit bourgeoisie.[3] > Again, it depends on the legal system of the particular state, but i > fear it's almost certainly true in Vanuatu - and maybe even in some > parts of Massachusetts, where, IIUC, the FSF is located. The FSF doesn't have a physical office anymore.[4] My guess is, the rent rose much faster than the seas. Regards, Branden [1] https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/contrib/mom/examples/penguin.ps https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/contrib/mom/examples/penguin.pdf [2] https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/doc/gnu.xpm [3] Don't take _my_ word for it. In 1954, Kenneth Arrow and Gérard Debreu established the conditions under which a market could find a price equilibrium. The conditions are extremely strict, and foreclose practically every avenue for any market participant to exercise a "competitive edge". Any such competitive edge is a shock to the equilibrium; if it can't be rapidly replicated among all relevant market actors, the model no longer applies; if it can, the edge ceases to exist. https://en.wikipedia.org/wiki/Arrow%E2%80%93Debreu_model [4] https://www.fsf.org/blogs/community/fsf-office-closing-party
signature.asc
Description: PGP signature
