From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31963 invoked by alias); 4 Jan 2012 17:38:08 -0000 Received: (qmail 31766 invoked by uid 22791); 4 Jan 2012 17:38:06 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Jan 2012 17:37:54 +0000 Received: from ams by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RiUmf-0001rI-2E; Wed, 04 Jan 2012 12:37:53 -0500 Date: Wed, 04 Jan 2012 17:38:00 -0000 Message-Id: From: ams@gnu.org (Alfred M. Szmidt) To: "Joseph S. Myers" CC: alves.ped@gmail.com, stanshebs@earthlink.net, gdb-patches@sourceware.org In-reply-to: (joseph@codesourcery.com) Subject: Re: RFC: one more question about year ranges in copyright notices... Reply-to: ams@gnu.org References: <20120104094649.GV2730@adacore.com> <4F047C06.8030000@earthlink.net> <4F048475.8090303@gmail.com> 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/msg00159.txt.bz2 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 -2012 is correct in that case, and for what 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.