At 2025-05-08T23:06:12-0500, Richard Laager wrote: > On 2025-05-07 07:05, Simon Josefsson wrote: > > Another example is the practice to drop copyright years from > > copyright notices. Some commercial players do this because they > > save developer time, and believe that the likelyhood that a > > copyright claim will have commercial effects depending on the > > presence or lack of the copyright year is low. > > Basically zero, right? Because (in at least 181 countries), copyright > attaches automatically, regardless of whether a notice is present at > all. > https://en.wikipedia.org/wiki/Berne_Convention As I understand it, the U.S. did not ratify the Berne Convention until 1989, and its provisions were not retroactive (revisions to U.S. _statutory_ law, however, such as the Sonny Bono Copyright Term Extension Act of 1998, have frequently applied retrospectively, perhaps creating the illusion that treaty ratification did so). For example, works that had already fallen into the public domain, or failed to acquire copyrighted status in the first place due to a defective or absent copyright notice, were not recaptured by the copyright regime through either the Berne ratification or the Bono CTEA. To my knowledge, defective or absent copyright notices no longer prevent the attachment of copyright in the U.S., but they could prior to the Copyright Act of 1976, which took effect on 1 January 1978. At least some of the original Bell Labs Unix source code (kernel plus userland programs), some of which dated back to 1971 (in PDP-11 assembly language or B, since the C language did not yet exist--but particulars are hard to know since much of this data has been irretrievably lost), was affected by this provision because, as I understand it, AT&T dithered over its legal strategy, and decided at some point that the Unix source code was a trade secret, and therefore--the reasoning may have been fallacious here, and/or there were conflicting or shifting directives in AT&T leadership--copyright notices were not attached to some files, or in some cases might have been deliberately removed. (The question "can something be both a trade secret and copyrightable?" did not have as clear an answer in the 1970s as it does today; as far as I know the issue wasn't settled in the U.S. until _Salinger v. Random House_ in 1987.[0]) The later infamous _USL v. BSDI_ lawsuit turned on this fact, as well as AT&T's practice of "unclean hands", placing false notice of its own copyright on materials that originated wholly within UC Berkeley. In summary, it is possible for some (very old) source code to be in the public domain in the United States even when not deliberately given that status by its author. What _has_ never happened, as far as I know, is that no computer source code in any form has ever _aged_ into the public domain. What protected "Steamboat Willie" until 1 January 2024 also protected everything from Alonzo Church and Alan Turing forward. Admittedly, even that summary is too simple. For a time, whether program source code could enjoy copyright protection at all was debated by legal scholars and courts in the United States. As I understand it, The 1976 Copyright Act settled that question, and was one of the premises upon which Bill Gates rested his "Open Letter to Hobbyists"[1] and established the foundational principle of copyright rentierism in software upon which he built his multi-billion dollar empire. > > The copyright absolutist approach would be to look at laws and prior > > cases and recommend what is the safest and most conservative > > approach. As far as I know, that is still to do increment copyright > > years. > > Can we all at least agree that annually incrementing the year in > _every_ copyright statement in the project is wrong? You don't get a > new copyright every year. I agree, but it's a popular practice nevertheless, including in several GNU projects. The GNU Maintainers' Guide articulates a sound and legally correct premise but then waves its hands such that some people end up robotically "bumping" all copyright notices in a code base to include the current year on or about 1 January, every year, before and irrespective of whether any "nontrivial" change is made in that year. "To update the list of year numbers, add each year in which you have made nontrivial changes to the package. (Here we assume you’re using a publicly accessible revision control server, so that every revision installed is also immediately and automatically published.) When you add the new year, it is not required to keep track of which files have seen significant changes in the new year and which have not. It is recommended and simpler to add the new year to all files in the package, and be done with it for the rest of the year."[2] I find that practice unseemly and offer different, and in my view more scrupulous, advice in the project I maintain.[3] Regards, Branden [0] https://en.wikipedia.org/wiki/Salinger_v._Random_House,_Inc. [1] https://en.wikipedia.org/wiki/An_Open_Letter_to_Hobbyists [2] https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html [3] https://git.savannah.gnu.org/cgit/groff.git/tree/HACKING?id=0cd44362696c9d65ab59f6014f15221ac53b57f3#n101
Attachment:
signature.asc
Description: PGP signature