The reply I received from
firstname.lastname@example.org (the compliance lab) suggested a copyright notice in the modified file is sufficient.
An example of a copyright notice:
Copyright (C) 2011, 2012, 2014 Ernest Thornhill (email@example.com)
Something to note about the dates:
For software with several releases over multiple years, it's okay to use a range (“2008-2010”) instead of listing individual years (“2008, 2009, 2010”) if and only if every year in the range, inclusive, really is a “copyrightable” year that would be listed individually; and you make an explicit statement in your documentation about this usage.
Something to consider is that you are not required to claim a copyright on your changes.
In this case it seems like you need some other prominent notice.
The Software Freedom Law Center states for GPLv2:
Section 2(a) requires that all modified versions be so marked, with basic indication of the modifications made, the date of modification, and some identification of the modifier. Compliance is achieved by any markings in source code that contain this information in a reasonable form. Not all the information available from a source code version control system need be provided, nor is the requirement a substitute of the project-level ChangeLog or similar file. Appropriate compliance assists a programmer using or reviewing any particular source file to know from what version of a project or program that source file comes, and to trace the history of recent substantive modification.
For GPLv3 that article states:
...with the additional requirement to provide notice of modification, date and some identification of modifier as under GPLv2 §2(a), above.
Therefore, it seems like they consider it the same for GPLv2 and GPLv3
Based on that description, I imagine something like a simplified ChangeLog entry:
// 12-22-1999 Ernest Thornhill (set_date): switched to 4-digit years
... directly below the warranty disclaimer.
The authors, date and note doxygen commands for a function you just edited
might also be considered prominent.
While it might not be a requirement, a GNU coding standard is to keep a ChangeLog.
This is for describing all the changes made to the source files.
The NEWS file contains a list of user-visible changes worth mentioning.
I've noticed that emacs contributors write the extended commit description
like it's the body of a ChangeLog entry.
Then they use a script to convert the git log to a ChangeLog.