From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH RFC] Update/correct copyright notices Date: Wed, 28 Feb 2001 09:20:00 -0000 Message-id: <1010228172041.ZM17593@ocotillo.lan> References: X-SW-Source: 2001-02/msg00518.html On Feb 28, 1:15pm, Eli Zaretskii wrote: > On Wed, 28 Feb 2001, Kevin Buettner wrote: > > > The changes below were automatically generated. See > > > > http://sources.redhat.com/ml/gdb/2001-02/msg00429.html > > > > for additional information regarding this patch. > > I think the following change for go32-nat.c (and probably for many other > files) is not right: > > diff -upr gdb.orig/go32-nat.c gdb/go32-nat.c > --- gdb.orig/go32-nat.c Tue Feb 20 12:31:27 2001 > +++ gdb/go32-nat.c Wed Feb 28 01:17:14 2001 > @@ -1,5 +1,5 @@ > /* Native debugging support for Intel x86 running DJGPP. > - Copyright 1997, 1999, 2001 Free Software Foundation, Inc. > + Copyright 1992, 1999, 2000, 2001 Free Software Foundation, Inc. > > go32-nat.c was not part of any GDB distribution is year 2001, so I don't > think we need, or even should, copyright it for this year yet. What if > the go32-nat.c changes checked into the GDB CVS until now will be > reverted at a later date, before any release is ever made? > > (I'm quite sure I saw some message from Richard Stallman which said only > released versions need to be copyrighted, but I cannot find it in the > references I kept. So maybe I was dreaming.) I saw that message too. Here's the relevant portion: If I add one now, should I only start at the year 2001, or the year the first version of the file was written? You should use the list of years in which released versions were finished, just as for any other file. I don't know what to make of this. Don't snapshots qualify as a type of a release? What about mere availability via CVS? If our snapshot activities do qualify as a type of release, then it seems to me that it is not entirely inappropriate to include the current year in the copyright notices regardless of the form that the code will eventually take. (This assumes, of course, that the file in question has been modified in the current year.) > In any case, I suggest that Kevin's script's effect be limited to past > years. Adjusting the copyright notice is the responsibility of the > file's maintainers, so it isn't right IMHO for a script to interfere > like that with files I'm working on while I work on them. The script's > use should IMHO be limited to fixing past blunders, or files for which we > don't have active maintainers. Perhaps it should just send email to > the responsible persons where it detects anomalies in copyright notices, > but not actually change anything. I see your point. But I also think that, for many maintainers, the care and feeding of the copyright notices is the least appealing part of the job. Most would, I think, welcome any help given in correcting/updating them. However, since that's clearly not the case for all maintainers, so I'll modify my script with a list of file names to exclude from consideration. I assume that you'd like the following files to go on this list? go32-nat.c config/i386/go32.mh config/djgpp/fnchange.lst (not that this one has a copyright notice, but adding it to the list will squelch the warnings about it not having a notice) config/djgpp/djconfig.sh ser-go32.c Any others?