Sylvain Beucler wrote: > Sebastian Gerhardt wrote: > > a maintainer asked me about the reason we give the adive to write > > explicit copyright dates--not ranges. Why is it better to do this? > > That's what the FSF lawyers recommend > http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html > > "Do not abbreviate the year list using a range; for instance, do not > write '1996--1998'; instead, write '1996, 1997, 1998'." > > The document doesn't justify this recommendation. Maybe Karl knows, > otherwise we can ask [email protected], otherwise we can assume that,
As I recall from previous discussion this is so that searching for a specific year can locate the document more easily. For instance in the range 2005-2009 searching for "2007" won't locate that document. Specifying the list of dates facilitates this part from the Copyright-Notices document: Don't delete old year numbers, though; they are significant since they indicate when older versions might theoretically go into the public domain, if the movie companies don't continue buying laws to further extend copyright. If you copy a file into the package from some other program, keep the copyright years that come with the file. The Copyright-Notices document also says: Sometimes a program has an overall copyright notice that refers to the whole program. It might be in the README file, or it might be displayed when the program starts up. This copyright notice should mention the year of completion of the most recent major version; it can mention years of completion of previous major versions, but that is optional. Therefore an overall date such as in --version output may use just the latest year and does not need to display the long list of dates that are needed in a file's copyright notice. Of course many of these rules and guidelines are very general best practices and date from before projects *always* had version control meta-information available for them. (All projects today use a version control system, right? :-) Some of these I am certain are there to benefit a project that exists as distribution only without any way to look at the version control history. And having had to deal with lawyers on these matters I can say from first hand experience that most of them do not understand the concept of version control systems and so it is much better to have a clean paper trail plainly visible in the files and not need to fall back to using the meta-information of a version control system. So I think these are still good ideas today too. Bob
