Hi Branden, G. Branden Robinson wrote on Fri, Oct 24, 2025 at 03:21:19PM -0500: > At 2025-10-23T17:10:21+0200, Ingo Schwarze wrote:
>> 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... No, i was simply joking, i should have written "cruelty ;-)," i guess. The animal subject, of course, is Groff the BSD Goat, https://media.bsd.cafe/bsdmmedia01/accounts/headers/114/672/550/452/665/721/original/88f8347da1fbf91f.jpg https://mastodon.bsd.cafe/@GroffTheBSDGoat https://www.dragonflydigest.com/2014/05/26/groff-the-bsd-goat/ > 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. Yeah, i kind of see the point. The argument is a bit weakened in so far as we already know that "15 lines" is not particularly sane from a legal perspective, so having a definition that is already somewhat defective in theory and then trying to figure out how workable it is in practice is slightly dubious. But fair enough! [...] >> 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.) Indeed, git log is what supports the complete research (in cases where that is needed). What git log does not provide is a quick overview, neither for an individual file nor for a project as a whole. [...] >> 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. Admitted. Besides, i didn't mean "moral rights" in the sense of Copyright law but merely "moral" in the ordinary sense of "doing what is respectful, being nice to each other". > A list of years in the Gregorian calendar, I submit, does not augment > the degree of moral satisfaction-- Arguably - or maybe it does, very slightly. Copyright (c) 2008-2012, 2014 Kristaps Dzonsons communicates "likely did lots of work in the early years"; without the years it does not. Admittedly not a big difference. > 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. No argument about that. While i understand treating the Copyright notice as a project-wide feature and merely repeating it in some or all files is not illegal, i personally do not like that practice, but i don't pester people who do it that way either. The reason i occasionally talk to you about these matters is that you have explicitly indicated interest in adopting a better standard than "bump everything every year." [...] > 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". All true, and https://mandoc.bsd.lv/devhistory.html is terse and bulky at the same time. I think we agree that one global notice is the legal minimum and that a narrative history may be interesting. Per-file notices with complete lists of names and years are somewhere in the middle. Quite imprecise and only vaguely indicative of the history, but relatively easy to maintain - and particularly easy to read for a casual onlooker. >> 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 original public release of groff was a "work" - but i'm not sure any copy of that work has been preserved. Even the oldest groff version contained in Kirk's BSD archive - which is older than the groff git repo goes back - wasn't, i think, the oldest published version. If you re-publish that work without changes, then do use the year of original publication. What typically happens in software is that people prepare and publish "derived works". For example, when you publish a new release, it is certainly a derived work based on previous versions, modified by new patches. So you have to mention the year of publication of the new release, and since the license of the old releases requires retaining the Copyright notices of the original works your derived work is based on, i *think* you should also mention the years of publication of releases you are basing your derived work on. Public version control makes this even more fine grained. Arguably, a file in public version control is also a "work". At least in can be downloaded and used independently, and for Free Software, the license usually explicitly permits that. So after every (non-trivial) commit, the new version of the file is a newly published derived work, and it makes sense to me to mention the year of publication of that changed file. You could even go as far as calling each individual patch a "work" - at least public version control typically supports downloading patches, and licenses typically permit using text from patches. Sometimes, i have even read this point made explicit. For example, when you download a diff from cvsweb.netbsd.org, the website prefixes it with this notice: Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. To summarize, it doesn't look like you are planning to delete Copyright years from notices in the near future, which i think is good. If you decide to maybe do it later, i probably won't like it too much because i see some minor benefits when done diligently (first sight impression regarding authorship) for minor cost (keeping a few lines up to date at the top of a file where likely much larger and harder work has been done anyway). Essentially, all that is asked for is checking whether one trivial change is needed at the top whenever one does a non-trivial change in the body of the file, which is almost by definition negligible effort. Still, i don't blame people who don't do it as it's not legally required. At least, make sure it doesn't create any legal issues if you ever want to go into that direction - i feel somewhat suspicious because Copyright notices without years seem unusual, to put it mildly. Yours, Ingo
