As I write, we're 10 days into 2012. I bet many programmers are editing the copyright string at the top of their source files to something like:

// Copyright 2008, 2010-2012 Some Company Unlimited

Your version control system knows when files were modified so surely it can help write or rewrite these strings. So my question: is there a script that can examine git logs for each file and output (or better insert) a string like that about?

I'm using git so that's of primary interest but do let me know if such scripts exist for other systems.


We need a script that does this:

  • Walks all source files in our working copy
  • Locates existing copyright string and identifies years e.g. 2007,2009-2011 would be {2007, 2009, 2010, 2011}
  • For each year that is not mentioned, diff between 1 Jan and 31 Dec (or today if current year). Examine diff and decide if it's worthy of a mention in the copyright string
  • Insert new copyright string.
  • 1
    If I understand correctly, the date is optional anyway. Good question, though. +1.
    – Maxpm
    Jan 10 '12 at 13:00
  • I know date is not legally significant but it is interesting to see when files were touched. If there was a script I could run to set this line accurately and automatically across all source files then there is no need to think any more about this!
    – paperjam
    Jan 10 '12 at 13:50
  • 3
    I've been wondering about the legal significance of an automatically generated copyright notice. The updated notice itself is not copyrightable, so you're claiming a 1-year extension on the copyright without new creative work being added. Jan 10 '12 at 14:40
  • Good point @David. I guess any such tool would have to ignore any of its own commits. Perhaps also it could be configured to ignore commits that do not typify new content (e.g. text deletion, small changes, renamings, reformattings, etc.)
    – paperjam
    Jan 10 '12 at 20:26
  • The real question is will anyone care about your code 70/95/120 years from now?
    – Nick T
    Feb 4 '16 at 1:25


Don't worry! Your copyright over the project won't expire if you didn't update the year in time! You are safe - it doesn't work that way.

Long version:

I'm pretty sure that all year numbers in the copyright notice indicate the start of copyright not the range. If you add a year it means the continuation of the start, not end. You use it if you add new content (like new modules) to indicate the starting year for that new content only. It is optional but should be used for large changes, like whole new modules or a complete design makeover.

The copyright should expire after fixed number years (which depends on the laws in your country) after the last year in your notice.

So, I don't see a reason to busily update source headers at all.


The thing is that usually changes which are substantial enough involve completely new source files or a re-implementation of old ones. So, as long as you always use the current year in the headers of new source files you're fine. There is no need whatsoever to pass through every single file to make the update. Actually, the only thing that requires a manual change is if you have date range in the licence text itself or in readme file.

Disclaimer: I am a programmer, not a lawyer.

  • 1
    You should add a year / enlarge range whenever you do substantial change to a file, afaict. So the raason is there. Problem is, it should not be automatic - git cannot tell when the change is substantial.
    – herby
    Jan 10 '12 at 13:10
  • @herby: I edited in a clarification and a reply to your comment in my answer. Jan 10 '12 at 13:18
  • IANAL either, but AFAIK, the expiry date of copyright is based on the death date of the last surviving author. The date of creation is only of interest when someone claims prior art on your work.
    – tdammers
    Jan 10 '12 at 20:31
  • @tdammers: IANAL either, but IIRC in countries where legal persons can hold copyright a copyright held by legal person expires based on date of creation. Whether the copyright for software is held by the company or the actual employees who wrote it depends on particular jurisdiction (IIRC US law allows the copyright itself to be assigned while most European laws only allow exclusive rights while the copyright is still held by physical authors) and work agreement (the copyright does not have to be assigned when it can).
    – Jan Hudec
    Jan 11 '12 at 6:57
  • @JanHudec In the UK, if you develop software for a company, the company holds the copyright, but the copyright ends 70 years after the death of the human author. The same may be true in other European countries.
    – gnasher729
    Jun 5 '20 at 17:59

is there a script that can examine git logs for each file and output (or better insert) a string like that about?

It's not a script per se, but Git feature, which you can use for this task: smudge/clean filter pair


If you happen to be using gradle as your build tool, Spotless can do this (docs). There's a WIP for maven too.

spotless {
  cpp {
    target 'src/**/*.hpp', 'src/**/*.cpp'
    licenseHeader '// Copyright Acme Corp $YEAR'

No, git does not know when files were modified.

Git commit object simply define the content of all files at specific point. The same content may easily appear in another commit, even unrelated one. There is nothing to make one of them more important. So the answer might be ambiguous, though it often won't.

  • Hmmm... How does git know the date when I type git log?
    – paperjam
    Jan 10 '12 at 22:01
  • @paperjam: It knows when the commits were created. When you type git log, it walks the commits, so of course it knows their date. But it may not know which commit introduced particular version of file, because there may be more than one.
    – Jan Hudec
    Jan 11 '12 at 6:32
  • It does save the access control bits in the blob, so it might as well save the modicifation date at that point. But I'm not sure. Jan 11 '12 at 11:35
  • @TamásSzelei: No, blob is exactly the word "blob", a newline and the content. That's it. Not even a name. A tree has the name, type and executable bit for the blobs and subtrees it points to. But that's still totally ahistorical. This is intentional and by design.
    – Jan Hudec
    Jan 11 '12 at 12:48
  • 3
    I may be extrapolating the OP's answer here but I think the only thing that matters, from a release point of view, is when the commit was made and not exactly when the file was last touched. Simply put if it is not committed and merged then it doesn't get released. Hence why doing something as simple as git log --follow [filename] | grep -m 1 Date would suffice to get the latest date.
    – Spoike
    Jan 20 '12 at 10:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.