Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

Update:

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.
share|improve this question
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
2  
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. –  David Thornley 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
    
+1, thanks for reminding! –  SK-logic Jan 11 '12 at 11:54

3 Answers 3

TL;DR

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.

EDIT:

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.

share|improve this answer
    
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. –  Goran Jovic 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

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

share|improve this answer

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.

share|improve this answer
    
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. –  Tamás Szelei 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
    
I meant blob in the general sense and I was not aware that it means something else in git. What I meant is, it does save the access control bits somewhere (since it shows up on git status if there were changes), doesn't it? –  Tamás Szelei Jan 11 '12 at 13:04

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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