I started an open source project in 2013, with the LGPL license. I've been regularly working on it for the last four years. Each file includes the standard copyright notice that include the copyright year. Obviously not all files were modified every year so some of them reports "Copyright 2013" some "Copyright 2014" or "Copyright 2015" and only a few "Copyright 2016". The project is a library so it has no welcome or splash-up screen where to report the current copyright date.

What is the correct practice in this case? Should I update yearly every file updating the notice to the current year, even if this is the only midification to the file. Is it even better the whole range of years (Copyright 2013-2016)? Or should I leave the copyright year untouched, with the meaning of the year of the file creation?


1 Answer 1


Since you're using the LGPL, I suggest you follow the GNU project's recommendations: your copyright notices should look like

Copyright © 2013, 2014, 2015, 2016 cannatag

and you should simply update them all at the start of every year, assuming you're publishing every year (if your source code is publicly available during development, that could be construed as counting as publication). The GPL howto clarifies this:

Whichever license you plan to use, the process involves adding two elements to each source file of your program: a copyright notice (such as “Copyright 1999 Terry Jones”), and a statement of copying permission, saying that the program is distributed under the terms of the GNU General Public License (or the Lesser GPL).

The copyright notice should include the year in which you finished preparing the release (so if you finished it in 1998 but didn't post it until 1999, use 1998). You should add the proper year for each release; for example, “Copyright 1998, 1999 Terry Jones” if some versions were finished in 1998 and some were finished in 1999. If several people helped write the code, use all their names.

If you want to play it safe and avoid any accusation of over-reaching in your copyright notices (I have no idea how much of a risk that is), you might instead want to update the years only when you make non-trivial changes to the relevant files; so you'd end up with a variety of copyright notices depending on when each file was edited:

Copyright © 2013, 2015 cannatag

Copyright © 2014, 2016 cannatag

Copyright © 2014, 2015, 2016 cannatag

Other projects have different recommendations; thus the Eclipse Foundation recommends mentioning the first and last year of publication in each file:

Copyright © 2013, 2016 cannatag

Even that is subject to interpretation, and for example in OpenDaylight we use the Eclipse form, per-file: each file has a copyright notice with the year it was created in and the last year it was updated in.

You should avoid ranges though, they don't have a definition in US copyright law at least.

Given the variety of practices out there I can't see the details actually having an impact beyond documentation; when it comes to courts, it seems to me that actual copyright is decided based on more than the notices themselves (see for example Conservancy's analysis of Christoph Hellwig's contributions to the kernel). (Of course I am not a lawyer and you should consult one if this is troubling you.)

  • 1
    Despite what the linked page says about it, my understanding is that you can only claim copyright for years in which you have made non-trivial changes to the file. Just changing the Copyright notice and nothing else may actually invalidate the Copyright claim. But, AFAIK, there is no case law to say either way.
    – MAP
    Commented Aug 10, 2016 at 4:43
  • Copyright law (in the US and elsewhere) defines copyright notices in terms of publications of whole works; it doesn't care about individual source files. The recommendations above are based on the idea that making changes to a single file causes a publication of the work (publicly available source at all times during development). See opensource.stackexchange.com/a/2875/118 for more detail... Commented Aug 10, 2016 at 7:18
  • Yes, it might turn out either way, but has never come up in a court. It could be ruled that the "whole work" is the repository, or that each source file is a "whole work" in and of itself. Until there are cases where this question is argued, either interpretation can be taken. It's even possible for the courts to decide that it applies one way or the other depending on how you distribute. If you can only get my source by FTP as a single tarball that's a whole work. But, if it's in, say, a git repository where you get the individual files, then maybe they are separate works.
    – MAP
    Commented Aug 10, 2016 at 8:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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