From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2874 invoked by alias); 4 Jan 2012 16:55:36 -0000 Received: (qmail 2866 invoked by uid 22791); 4 Jan 2012 16:55:34 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-we0-f169.google.com (HELO mail-we0-f169.google.com) (74.125.82.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Jan 2012 16:55:21 +0000 Received: by werf1 with SMTP id f1so11472467wer.0 for ; Wed, 04 Jan 2012 08:55:20 -0800 (PST) Received: by 10.216.131.141 with SMTP id m13mr37010956wei.30.1325696120323; Wed, 04 Jan 2012 08:55:20 -0800 (PST) Received: from [192.168.0.103] ([2.83.165.22]) by mx.google.com with ESMTPS id g11sm26342685wbo.6.2012.01.04.08.55.18 (version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 08:55:19 -0800 (PST) Message-ID: <4F048475.8090303@gmail.com> Date: Wed, 04 Jan 2012 16:55:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Stan Shebs CC: gdb-patches@sourceware.org Subject: Re: RFC: one more question about year ranges in copyright notices... References: <20120104094649.GV2730@adacore.com> <4F047C06.8030000@earthlink.net> In-Reply-To: <4F047C06.8030000@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00155.txt.bz2 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