This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Fri, Feb 28, 2014 at 06:22:08PM +0000, Joseph S. Myers wrote: > On Fri, 28 Feb 2014, Joel Brobecker wrote: > > > > Joseph, do you know why implicitly adding years to the claimed > > > copyright years is a problem? I'm guessing the file needs to be > > > published somewhere for each year claimed. > > > > IANAL, but from 2 discussions with copyright-clerk: > > > > 1. We start claiming copyright the year the file as committed > > to a medium (hard drive), not the year it was published. > > I don't think it counts unless the version in question got published at > some point. The question is about versions that weren't published at the > time, but were published later when the version control history was > released. > > There was a discussion on bug-standards starting Jan 2012. Karl's revised > wording from 11 May 2012 seems to indicate that if a version was committed > to a version control history that was later released, the dates from that > history count as copyrightable years (so reducing the number of cases > where it may not be possible to fill in gaps) - but that revised wording > doesn't seem to have been committed. Thanks for pointing me at that discussion Joseph. I've read through all of those posts and the current http://www.gnu.org/prep/maintain/maintain.html It's clear that we are allowed, and even encouraged, to add the current year to the copyright notice in each file when activity on the package *as a whole* makes that year a "copyrightable" year. ie. It is not necessary that a given file had changes itself in the current year, which was the practice we followed in the binutils project previously. Extending that reasoning to previous years allows us to fill in missing years in many files. The only condition is that each year added be a "copyrightable" year. You explained upthread, based on the bug-standards discussion, exactly what constituted a "copyrightable" year so I won't repeat it here. I'm certain that every year since the inception of the binutils project was in fact a "copyrightable" year, but the funny thing is that we don't even need to know what makes a year a "copyrightable" year. If one file in the project correctly claims copyright in a given year, then all files extant at that time in the project can also have that year filled in. For example, gas/read.h is "Copyright 1986, 1990, .." and gas/read.c before Nick changed that file to a year range was "Copyright 1986, 1987, 1990,..". That allows us to add 1987 to the years in gas/read.h. opcodes/m88k-dis.c is "Copyright 1986, 1987, 1988, 1989, 1990, 1991,.." so there we have every year since the start of the binutils project, until binutils had a public CVS repository. Multiple other files also call out each of these years, as can easily be verified with grep. The only fly in the ointment is a file like binutils/filemode.c, added to binutils in 1991 carrying a copyright of "1985, 1990, 1991,..". For that file we have to look at the emacs project where it originated, and ask whether the missing years are "copyrightable". I think they are, using the same reasoning as above for the emacs project. Attached is the diff I'd like to commit. Generated by /usr/bin/python ./update-copyright.py --this-year chmod a+x bfd/mep-relocs.pl binutils/ranlib.sh binutils/sanity.sh binutils/testsuite/binutils-all/windres/msupdate gas/testsuite/gas/rx/make-d gold/testsuite/*.sh gprof/bbconv.pl ld/genscripts.sh git checkout -- `for z in include/*; do test -f ../gcc-current/$z && echo $z; done` I'll post update-copyright.py separately. -- Alan Modra Australia Development Lab, IBM
Attachment:
copyright.diff.gz
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |