Required works to put existing GPLv3 source code on GitHub, with respect to modification dates

Question

I was looking at the GPLv3 License.

It states that when I modify the Program and distribute it, I need to meet the condition of:

a) The work must carry prominent notices stating that you modified
it, and giving a relevant date.

Now let's say I found a GPLv3 source code on the web and want to put it on the GitHub and start making modifications on it.

Question:

• What would be the required works to be done against this source code? Do I need to write down the cloned date? What about the subsequent changes I make to the repository? Do they also have to be written down somewhere on source code each time I make modification?

Answer 1

Copyright notices

The reply I received from licensing@fsf.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 (themachine@sub.nyc)

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.

https://www.gnu.org/licenses/gpl-howto.html

Comments

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
(confirmed via licensing@fsf.org).

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.

ChangeLog

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.

Answer 2

I think that adding your own copyright statement for the portions that you modify, alongside the existing copyright statements, should be sufficient: it identifies the portions you've modified, with a date, and is as prominent as the license grant which indicates that the GPL applies in the first place. If the program you're modifying follows the usual GPL practice (as recommended in the license itself), this will involve

• copyright statements in the various source files you modify;
• whatever copyright statement is made visible when the program is run;
• copyright statements in other files in the source distribution (README potentially).

In a typical GNU-style piece of software you would also add yourself to AUTHORS, and as you make changes, document them in ChangeLog, and add user-visible changes to NEWS. But that's just maintenance of the documentation, not (as I understand it) a licensing requirement.