Years in copyright notices

Years in copyright notices

[Richard Stallman]

The latest legal advice I got is that we should not drop the 19 or 20
from year numbers in copyright notices.  There is no need to change
all the existing notices, but the year numbers we add should be
written in 4 digits.

Re: Years in copyright notices

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> The latest legal advice I got is that we should not drop the 19 or 20
> from year numbers in copyright notices.  There is no need to change
> all the existing notices, but the year numbers we add should be
> written in 4 digits.

Why not do it properly if we are going to fix 04 -> 2004 anyway?


This function seems to do the job (could be added to copyright.el):

(require 'copyright)

;;;###autoload
(defun copyright-fix-years (&optional arg)
  "Convert 2 digit years to 4 digit years in copyright.
With prefix arg, also update copyright.
Uses heuristic: year >= 50 means 19xx, < 50 means 20xx."
  (interactive "P")
  (widen)
  (goto-char (point-min))
  (if (re-search-forward copyright-regexp (+ (point) copyright-limit) t)
      (let ((s (match-beginning 2)) (e (make-marker))
	    last)
	(set-marker e (1+ (match-end 2)))
	(goto-char s)
	(while (and (< (point) (marker-position e))
		    (re-search-forward "\\([^0-9]\\)\\([0-9]+\\)[^0-9]"
				       (marker-position e) t))
	  (let ((p (point))
		(sep (match-string 1))
		(year (string-to-number (match-string 2))))
	    (goto-char (1+ (match-beginning 0)))
	    (unless (= (char-syntax (string-to-char sep)) ?\s)
	      (insert " "))
	    (if (< year 100)
		(insert (if (>= year 50) "19" "20")))
	    (goto-char p)
	    (setq last p)))
	(when last
	  (goto-char last)
	  (fill-region s last)
	  )
	(set-marker e nil)
        (if arg
	    (copyright-update nil t)))
    (message "No copyright message")
    (goto-char (point-min))))


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Years in copyright notices

[Miles Bader]

On Thu, Jun 17, 2004 at 03:13:47PM +0200, Kim F. Storm wrote:
> > The latest legal advice I got is that we should not drop the 19 or 20
> > from year numbers in copyright notices.  There is no need to change
> > all the existing notices, but the year numbers we add should be
> > written in 4 digits.
> 
> Why not do it properly if we are going to fix 04 -> 2004 anyway?

_Please_ do not do random `cleanups' if they're not really necessary; it
simply makes for more merge conflicts.

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: Years in copyright notices

[Richard Stallman]

    This function seems to do the job (could be added to copyright.el):

If nobody sees a problem in it, please install it.

Re: Years in copyright notices

[Luc Teirlinck]

Richard Stallman wrote:

   The latest legal advice I got is that we should not drop the 19 or 20
   from year numbers in copyright notices.  There is no need to change
   all the existing notices, but the year numbers we add should be
   written in 4 digits.

What is the exact policy concerning copyright years?  I see that some
people update the copyright years when they make changes, but
apparently most people do not.  Are copyright years automatically
updated from CVS data when a release is made?

Sincerely,

Luc.

Re: Years in copyright notices

[Eli Zaretskii]

> Date: Mon, 21 Jun 2004 15:46:45 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> 
> I see that some people update the copyright years when they make
> changes, but apparently most people do not.

The rule is that the copyright years should include any year during
which changes were done to a file that are still present when the
package is released.

That means, theoretically, that if a file mumble.el was modified in
the year 2003, but that change was taken out before the file was
released with the next Emacs version, the year 2003 does not need to
appear.  But in practice, the only good way is to make sure, when you
modify a file, that the current year is in the list.

> Are copyright years automatically updated from CVS data when a
> release is made?

No, maintainers are supposed to do that when they install changes.

Re: Years in copyright notices

[Richard Stallman]

    What is the exact policy concerning copyright years?  I see that some
    people update the copyright years when they make changes, but
    apparently most people do not.  Are copyright years automatically
    updated from CVS data when a release is made?

We need to update the copyright years for all the files.

One reason we don't always add a year when making a change is that we
don't add a year when only small changes are made during that year.
That means that people making small changes in a file often don't
check to see whether the changes in the current year are enough to
justify adding the year.

Does anyone want to help in this process of adding the years
that should be added?

Re: Years in copyright notices

[Jan D.]

> One reason we don't always add a year when making a change is that we
> don't add a year when only small changes are made during that year.
> That means that people making small changes in a file often don't
> check to see whether the changes in the current year are enough to
> justify adding the year.

What is a "small change", 3-4 lines changed?  And do many small changes
eventually become a big change that needs to change the year?

> Does anyone want to help in this process of adding the years
> that should be added?

Is it enough to compare the file now with the version for the previous
year and count changed and added lines, or is a more manual comparison
needed?

	Jan D.

Re: Years in copyright notices

[Richard Stallman]

    What is a "small change", 3-4 lines changed?  And do many small changes
    eventually become a big change that needs to change the year?

I think the threshold should be 10 lines of new code, the same as the
threshold for needing legal papers.  If over 10 to 15 lines of new
code have been introduced in a file during a year, that year should be
mentioned.

This is the situation now that we have an accessible CVS repository,
so that every version of every file is always released.  In the past,
the situation was different; years in which there was no release did
not count, and the changes in those years all counted towards the year
of the following release.

    Is it enough to compare the file now with the version for the previous
    year and count changed and added lines,

It would do no harm to handle it this way.

Re: Years in copyright notices

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     What is the exact policy concerning copyright years?  I see that some
>     people update the copyright years when they make changes, but
>     apparently most people do not.  Are copyright years automatically
>     updated from CVS data when a release is made?
> 
> We need to update the copyright years for all the files.
> 
> One reason we don't always add a year when making a change is that we
> don't add a year when only small changes are made during that year.
> That means that people making small changes in a file often don't
> check to see whether the changes in the current year are enough to
> justify adding the year.
> 
> Does anyone want to help in this process of adding the years
> that should be added?

If we just want to document the years that have any changes at all
(i.e. not differentiate between small and big changes), it is a fairly
easy task to accomplish (and automate) --

For each file do:

1) cvs update FILE
2) cvs log FILE
3) find the YEAR of each log entry and put it into a list
   (if not already there)
4) sort the list
5) update the copyright in FILE using that list
6) cvs commit -m"Updated copyright years" FILE

In the process, all 2-digit years would be converted into 4-digit
years.

Of course, step 5 and 6 should be avoided if the current list of
years in FILE is already correct.

A Miles pointed out, this will lead to some merge conflicts, but since
this is legal stuff, we have to accept that inconvenience.

I can do this if you approve.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Years in copyright notices

[Miles Bader]

On Wed, Jun 23, 2004 at 10:08:41AM +0200, Kim F. Storm wrote:
> A Miles pointed out, this will lead to some merge conflicts, but since
> this is legal stuff, we have to accept that inconvenience.

Richard's post indicated that we do _not_ have to `accept that
inconvenience', that it isn't a critical point.

> I can do this if you approve.

Making sure the copyright notices include the appropriate years is reasonable
-- and probably won't result in all that many problems because many files are
already up-to-date -- but changing the date format is apparently not
necessary (according to Richard's post), and will result in many more
conflicts.

-Miles
-- 
Any man who is a triangle, has thee right, when in Cartesian Space, to
have angles, which when summed, come to know more, nor no less, than
nine score degrees, should he so wish.  [TEMPLE OV THEE LEMUR]

Re: Years in copyright notices

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> On Wed, Jun 23, 2004 at 10:08:41AM +0200, Kim F. Storm wrote:
> > A Miles pointed out, this will lead to some merge conflicts, but since
> > this is legal stuff, we have to accept that inconvenience.
> 
> Richard's post indicated that we do _not_ have to `accept that
> inconvenience', that it isn't a critical point.

Right, but if we make an effort to bring this fully up-to-date,
I suggest that we can just as well use the proper format.

> Making sure the copyright notices include the appropriate years is reasonable
> -- and probably won't result in all that many problems because many files are
> already up-to-date -- but changing the date format is apparently not
> necessary (according to Richard's post), and will result in many more
> conflicts.

Still, it will only result in conflicts in the files where you actually
did update the copyright notice on the branch.  If you didn't do that,
there will be no conflicts.

To me it doesn't make much sense to update the copyright on a "feature"
branch, as it is likely to conflict with updates on the trunk.  

Some users have copyright-update in the save-buffer-hook, so maybe
copyright-update should query vc to know if it's working on a branch
and not do any update in that situation (or at least query the user).

Of course, we also have release branches for maintenance releases,
and we should update copyrights on those branches -- but then we
normally don't merge to/from such branches.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Years in copyright notices

[Richard Stallman]

    already up-to-date -- but changing the date format is apparently not
    necessary (according to Richard's post), and will result in many more
    conflicts.

When we are changing a copyright notice, we should take the opportunity
to add the centuries where those are missing.

Re: Years in copyright notices

[Miles Bader]

On Thu, Jun 24, 2004 at 07:48:10PM -0400, Richard Stallman wrote:
>     already up-to-date -- but changing the date format is apparently not
>     necessary (according to Richard's post), and will result in many more
>     conflicts.
> 
> When we are changing a copyright notice, we should take the opportunity
> to add the centuries where those are missing.

Of course, but Kim's proposal seemed to include adding the centuries even to
those copyright notices that _don't_ otherwise need changing (which is many).

-Miles
-- 
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.

Re: Years in copyright notices

[Kevin Ryde]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

storm@cua.dk (Kim F. Storm) writes:
>
> (and automate)

In the past I used the script below on the gmp cvs, grepping the
output of cvs log.  It's probably bit rotted somewhat, but may give
some ideas.  The output from cvs log is normally big so you either
need to be on the repo machine or somewhere close.

I never wanted it to actually change files, just report apparently
missing years, to be checked manually.  Because eg. something later
reverted doesn't need to appear, an initial checkin from an external
source isn't a change, a complete rewrite restarts the years, etc.


[-- Attachment #2: copyrightyears --]
[-- Type: text/plain, Size: 2734 bytes --]

#!/bin/sh
#
# Look for cvs log entries with years not in the file's copyright notice.
#
# Run this in a cvs working directory.
#
# Bug: All log entries are examined, not just those belonging to the
# branch of the working directory.

years() {
  # years in the log file, one only of each
  cvs log "$1" 2>/dev/null | awk '

# Ignore the change to LGPL 2.1.
/^date: 2000\/07\/24 17:04:[0-9][0-9];  author: tege;  state: Exp;  lines: \+4 -4/ {
  next
}

/^date: / {
  sub(/date: /,"")
  sub(/\/.*$/,"")

  if (getline s) {

    # stop at a rewrite or replacement
    # FIXME: Not sure if these pick up too much
    if (s ~ /Rewrite[.,]/ ||
        s ~ /New file/) {
      exit
    }

    # skip log messages consisting solely of any of these
    if (s == "Add a copyright year." ||
        s == "Update copyright year." ||
        s == "Add missing copyright headers." ||
        s == "Add copyright." ||
	s == "Fix a typo in a comment." ||
	s == "Copyright (C) -> Copyright.") {
      if (getline s) {
	if (s == "----------------------------")
	  next
      }
    }
  }

  if ($0 == 1996)
    seen1996++
  else
    print
}

END {
  # 2 entries for 1996 are taken to be the initial cvs checkin, and not
  # reported
  if (seen1996 > 2)
    print 1996
}' | sort -u

  # years in the file, duplicated
  awk '
/Copyright/,/^(#|dnl)?$/ {
  for (i=1;i<=NF;i++) {
    if ($i ~ /^[0-9]/) {
      s = $i
      sub(/,/,"",s)
      print s
      print s
    }
  }
}' "$1"
}


one() {
  # files which by convention don't have copyright notices in them
  case `basename "$1"` in
  stamp-vti		\
  | unix2mac		\
  | version.texi	\
  ) return ;;
  esac

  # files which aren't distributed, so don't matter
  case `basename "$1"` in
  .cvsignore		\
  ) return ;;
  esac

  # files that come from elsewhere and don't have to match the gmp cvs entries
  case `basename "$1"` in
  COPYING		\
  | COPYING.LIB		\
  | ansi2knr.c		\
  | ansi2knr.1		\
  | config.guess        \
  | config.sub          \
  | depcomp		\
  | INSTALL.autoconf    \
  | install-sh		\
  | ltconfig		\
  | ltmain.sh		\
  | mdate-sh		\
  | missing		\
  | mkinstalldirs	\
  | texinfo.tex		\
  ) return ;;
  esac

  # generated files that lose their copyright notices
  case `basename "$1"` in
  calc.c		\
  | calc.h		\
  ) return ;;
  esac

  # With the cvs years printed once but the file years printed twice,
  # the effect of uniq -u here is to print years that are in the cvs
  # but not in the file.
  #
  M=`years "$1" | sort | uniq -u`
  if [ -n "$M" ]
  then
    echo "$1: $M"
  fi   
}

files() {
  find -type f | awk '
!/\/CVS\// { print }'
}

if [ $# = 0 ]
then
  set .
fi

echo "Processing $*"

for d in "$@"
do
  for i in `find "$d" -type f`
  do
    one "$i"
  done
done

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel