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

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

[Joel Brobecker]

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.

WDYT? If people agree, I can put it on my list to do a one-time
hack of update-copyright to compress the list into one single range.

-- 
Joel

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

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> I thought I was giong to do my best to forget about this as soon as
Joel> the copyright notices would be updated, but what do you guys think
Joel> of Jan's remark:
[...]
>> IIUC this would allow us to write 1986-2011 everywhere as the GDB
>> package was nontrivially modified each of these years.  Just restating
>> Joseph.

Joel> Not totally critical, but I am seduced. I found that the formatting
Joel> of many copyright headers look a bit ugly before the list of years
Joel> shown in the notice is long enough that "Free Software Foundation, Inc."
Joel> would not fit on the rest of the line.

Joel> WDYT? If people agree, I can put it on my list to do a one-time
Joel> hack of update-copyright to compress the list into one single range.

This change would be fine by me.

Tom

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

[Stan Shebs]

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.

Stan

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

[Tom Tromey]

>>>>> "Stan" == Stan Shebs <stanshebs@earthlink.net> writes:

Stan> For files with new code, it would be nice if the first year in the
Stan> pair could be the year of the file's creation - it's a little jarring
Stan> to see something like tic6x-tdep.c with a 1986 date at the top of it.

FWIW, I usually use the original dates if I copy-and-paste a file.
I'm not sure if this is really what we're supposed to do, though.

Tom

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

[Pedro Alves]

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

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

[Joseph S. Myers]

On Wed, 4 Jan 2012, Pedro Alves wrote:

> That said, it may be worth asking the FSF.

Yes, that may make sense.

The rule for including intermediate years (before the rule that you can 
just add the new year to every file) used to be that the years to list 
were when a version, later released, was completed.  It then changed to 
explain that you should add the new year - on the presumption that you 
have public version control so that every intermediate version is 
released, and with the rule that you only need to track when changes to 
the whole package were made, not individual files.

Since GDB's version control history does not include the real history for 
older years - just imported snapshots / releases - it should probably be 
checked that there were indeed released versions of GDB that were 
completed in each year before 1999 that we wish to include implicitly in 
the simplified ranges.  And it probably is worth checking with the FSF 
that using <first-year>-2012 is correct in that case, and for what 
<first-year> should be (my guess is that it's the first year in which a 
released version of GDB included any copyrightable content from which the 
file was derived, but maybe it will be OK just to put the first year for 
GDB everywhere).

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Alfred M. Szmidt]

   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.

The creation date of a file might not coresspond to the year when the
content of the file was written.  If tic6x-tdep.c was created based on
another files content, then it would be correct to add 1986 to the
list of copyright years.

   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.

AFAIK: The range is means that the copyright holder has asserted his
rights as a copyright holder each year during that period.  It has
nothing to do with if the particular file was modified during that
year.

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

[Alfred M. Szmidt]

   The rule for including intermediate years (before the rule that you can 
   just add the new year to every file) used to be that the years to list 
   were when a version, later released, was completed.  It then changed to 
   explain that you should add the new year - on the presumption that you 
   have public version control so that every intermediate version is 
   released, and with the rule that you only need to track when changes to 
   the whole package were made, not individual files.

   Since GDB's version control history does not include the real history for 
   older years - just imported snapshots / releases - it should probably be 
   checked that there were indeed released versions of GDB that were 
   completed in each year before 1999 that we wish to include implicitly in 
   the simplified ranges.  And it probably is worth checking with the FSF 
   that using <first-year>-2012 is correct in that case, and for what 
   <first-year> should be (my guess is that it's the first year in which a 
   released version of GDB included any copyrightable content from which the 
   file was derived, but maybe it will be OK just to put the first year for 
   GDB everywhere).

This might help, from the GNU maintainer guidelines:

|    To update the list of year numbers, add each year in which you have
| made nontrivial changes to the package.  (Here we assume you're using a
| publicly accessible revision control server, so that every revision
| installed is also immediately and automatically published.)  When you
| add the new year, it is not required to keep track of which files have
| seen significant changes in the new year and which have not.  It is
| recommended and simpler to add the new year to all files in the
| package, and be done with it for the rest of the year.
|
|    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.

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

[Joel Brobecker]

Hello again,

Thanks a lot to all of you who answered. Very helpful. As usual
when it comes to legal matters, I did not have a clear understanding
of the all the ramifications. I have therefore sent the question
to the FSF copyright clerk email address.

One small clarification: The proposed change will simply shrink
the copyright years into a single range, but it will not change
the initial year recorded in each file. If that initial year is
mistaken (in either direction), fixing that would need to be done
on an individual basis after review.

Now, wait and see...

-- 
Joel

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

[Joel Brobecker]

Hello again,

> Thanks a lot to all of you who answered. Very helpful. As usual
> when it comes to legal matters, I did not have a clear understanding
> of the all the ramifications. I have therefore sent the question
> to the FSF copyright clerk email address.
> 
> One small clarification: The proposed change will simply shrink
> the copyright years into a single range, but it will not change
> the initial year recorded in each file. If that initial year is
> mistaken (in either direction), fixing that would need to be done
> on an individual basis after review.

I just got an answer from the FSF (case [gnu.org #719834]), and
it is fine to shrink the copyright year list into a single range,
even if there are "holes" in the original year list.

I will put this on my list of things to do sometime next month
(which ironically is in a few days - where does time go?).

-- 
Joel