Re: RFC: one more question about year ranges in copyright notices...

[Pedro Alves <alves dot ped at gmail dot com>]

On 01/04/2012 04:19 PM, Stan Shebs wrote:
> On 1/4/12 1:46 AM, Joel Brobecker wrote:
> > Hello,
> >
> > I thought I was giong to do my best to forget about this as soon as
> > the copyright notices would be updated, but what do you guys think
> > of Jan's remark:
> >
> > > > + 1986, 1988, 1989, 1991-1993, 1999, 2000, 2007, 2008, 2009, 2010, 2011
> > > > +
> > > > +... is abbreviated into:
> > > > +
> > > > + 1986, 1988-1989, 1991-1993, 1999-2000, 2007-2011
> > [...]
> > > IIUC this would allow us to write 1986-2011 everywhere as the GDB
> > > package was nontrivially modified each of these years. Just restating
> > > Joseph.
> > Not totally critical, but I am seduced. I found that the formatting
> > of many copyright headers look a bit ugly before the list of years
> > shown in the notice is long enough that "Free Software Foundation, Inc."
> > would not fit on the rest of the line.
>
> I agree with making it 1986-2012 everywhere uniformly.
>
> For files with new code, it would be nice if the first year in the pair could be
> the year of the file's creation - it's a little jarring to see something like
> tic6x-tdep.c with a 1986 date at the top of it. On the other hand, a copyright
> range like 2005-2012 makes it unclear if one is trying to say that that a particular
> file was modified each year in the range, or that it's "inheriting" the range from GDB as a whole.

Joel's list has holes in 1987, 1990-1991, 1994-1998, 2001-2006, inclusive.
If we had consistently through the years since 1986 been updating the
files' copyright years, even if the particular file that year list came from
wasn't updated in the hole years, then there would have been no year-holes!
From that, IMO, it follows that it should be okay to compress and get rid of
the holes.  But it does not follow that we could add back 1986 as earliest
year with copyright-able content to every file in the tree.  In my view, for files
with new code, then the year should indeed by the year of the file's creation.
However, if the new file with new code also includes copied code from other
files (that is, it is not strictly new code), and the copied code is considerable
copyright-able (e.g, more than a few obvious lines), then the copyright years
should reflect the copyright years of the code copied from, because copyright does not
apply to files as an atomic unit.  This happen particularly frequently with
new testsuite test files, where we most frequently just copy most of the test
from some other existing file.

That said, it may be worth asking the FSF.

--
Pedro Alves