Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <alves.ped@gmail.com>
To: Stan Shebs <stanshebs@earthlink.net>
Cc: gdb-patches@sourceware.org
Subject: Re: RFC: one more question about year ranges in copyright notices...
Date: Wed, 04 Jan 2012 16:55:00 -0000	[thread overview]
Message-ID: <4F048475.8090303@gmail.com> (raw)
In-Reply-To: <4F047C06.8030000@earthlink.net>

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


  parent reply	other threads:[~2012-01-04 16:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-04  9:47 Joel Brobecker
2012-01-04 16:10 ` Tom Tromey
2012-01-04 16:19 ` Stan Shebs
2012-01-04 16:43   ` Tom Tromey
2012-01-04 16:55   ` Pedro Alves [this message]
2012-01-04 17:17     ` Joseph S. Myers
2012-01-04 17:38       ` Alfred M. Szmidt
2012-01-04 17:28   ` Alfred M. Szmidt
2012-01-06  6:23 ` Joel Brobecker
2012-01-27  9:23   ` Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F048475.8090303@gmail.com \
    --to=alves.ped@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=stanshebs@earthlink.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox