In the background a person plays with a kid in the pool. The person is labeled “Companies updating their website”. The kid is labeled “The company logo”.
In the foreground a kid seems to be drowning. It is labeled “Useful information”.
In a second panel a skeleton sits at the bottom of the pool. It is labeled “The copyright year”
There’s some good info out there from the good people that know how things should work that created the reuse tool - https://reuse.software/ - and basically the conclusion is that nobody should be updating the years on the copyright line just because it’s a new year. The only useful info and what should be done is put the year when the file is created and that’s it.
The one thing that consistently gets caught in code reviews in my shop is a failure to update a copyright date. I have been tempted to submit clearly crap code just to see if anyone actually is paying attention.
We add the current year to the copyright dates, the current updates are protected from the time of authorship. So if the copyright says, 2012, 2014, 2022; I would add a 2024. The commit records can be used to determine what was changed each instance, but the update provides notice of when changes were made.
Discerning what is protectable creative expression versus functional and therfore unprotected is an issue for the courts.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
document.querySelector('span#copyright_year').innerText = new Date().getFullYear()<span>© <?php echo date("Y"); echo $companyName ?></span>No need to specify the tag name in the selector if you’re going to use an ID anyway.
Right - it should have been:
document.querySelectorAll('span#copyright_year').forEach((el) => { el.innerText = new Date().getFullYear() })so that we update all spans with that ID!
So true and yet so hurtful.
There’s some good info out there from the good people that know how things should work that created the reuse tool - https://reuse.software/ - and basically the conclusion is that nobody should be updating the years on the copyright line just because it’s a new year. The only useful info and what should be done is put the year when the file is created and that’s it.
Edit: took me a while to find the proper thing I wanted to link - https://matija.suklje.name/how-and-why-to-properly-write-copyright-statements-in-your-code
Had to go first to the recent curl blog where the author wants to go the weird way of not having useful info at all on the files.
Thank you for those two links!! I don’t necessarily have the time right now, but from first glance, those seem super interesting!
The one thing that consistently gets caught in code reviews in my shop is a failure to update a copyright date. I have been tempted to submit clearly crap code just to see if anyone actually is paying attention.
Unless you’re renewing your copywrite every year, changing the date every year is wrong. You list the date it was copywrited, not the current year.
We add the current year to the copyright dates, the current updates are protected from the time of authorship. So if the copyright says, 2012, 2014, 2022; I would add a 2024. The commit records can be used to determine what was changed each instance, but the update provides notice of when changes were made.
Discerning what is protectable creative expression versus functional and therfore unprotected is an issue for the courts.