Update or remove copyright year

[rmartin16]

Describe the bug

The copyright for Briefcase is currently 2019 in the docs and 2015 in the LICENSE. I believe the copyright year should reflect the most recent year copyright should to be asserted.

However, I have become convinced, for my own projects anyway, that a copyright year is unnecessary. Several large tech firms (presumably with overpaid lawyers) have dropped their copyright dates as well.

Steps to reproduce

See docs/conf.py or LICENSE.

Expected behavior

The copyright year should be accurate or absent.

Screenshots

No response

Environment

n/a

Logs

No response

Additional context

No response

[freakboy3742]

Mostly +1.

IANAL, but I've done a lot of work with the DSF (and others) around copyrights, trademarks, and more; and this is my current understanding.

The date in a copyright notice establishes the base date on which you're making your copyright claim under the Berne Convention. There's two ways this matters:

1. Establishing whether copyrights have expired. Has the content moved into the public domain because it's old?
2. Establishing whether your work serves as prior art.

In case 1, you want the date to be as current as it can be, so that the window of expiry is as late as possible. Absent of a specific date, any evidence of changes (like a git changelog) automatically acts as the date. This will almost never matter for software, because almost no software is going to last the 70+ years needed for copyright to expire (and if it does, you're into "original Unix sources" territory, where it's mostly academic interest rather than "still making money off Snow White" territory).

In case 2, you want the date to be as old as it can be, because it's part of your claim that "I did this first".

In both cases, the actual date - and even the (C) statement itself - isn't that rigorous as a protection. Berne Convention automatically gives any author some natural rights regardless of any specific claim. Some jurisdictions (cough US cough) have some loose interpretations of those rights, but others, like Europe, are exceedingly strict. Ultimately, including a (C), or going through a formal registration process don't do that much to improve your situation; they're mostly about making it easier to establish a claim if it ever comes to litigation.

FLOSS adds an interesting extra layer, because we have our full working in public, with signed individual contributions associated with exact timestamps. So - the "date of authorship" can be narrowed down to the second, on a per-line basis, in a verifiable archive.

On that basis, the best approach I've seen is:

• The primary copyright notice for a project uses the earliest date that has any meaning (so - date of first commit)
• Any text/documentation/publication that is associated with the project omits the date.

Omitting the date from most published versions is done because having "current" dates isn't actually a protection for software; the root copyright document has a clear "we did this in 2015" because it's a helpful anchor if someone wants to claim your project is violating their copyright. Again, this is a very weak protection - but it might be enough to discourage drive-by lawyers from having ideas.