Thanks for all those precisions. Should we complete the Savannah wiki, or add a rationale in maintain.texi?
Note: when you take a file from a project to another, usually you don't copy the history along - another reason to keep the information in the file rather than relying on the VCS :) -- Sylvain On Thu, Jan 22, 2009 at 02:23:27PM -0700, Bob Proulx wrote: > 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.
