bug-gzip
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] maint: fix copyright dates that were munged by a maintenance


From: Paul Eggert
Subject: Re: [PATCH] maint: fix copyright dates that were munged by a maintenance script
Date: Mon, 08 Nov 2010 11:06:55 -0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10

On 11/08/10 08:48, Jim Meyering wrote:
> I'm inclined to update those scripts, putting $year in place of
> the single year number there now.

Hmm, that will run into a problem, discussed below.  I'll CC:
address@hidden since there's a copyright-notice issue in this thread
<http://lists.gnu.org/archive/html/bug-gzip/2010-11/msg00004.html>.

> You can use a range (@samp{2008-2010}) instead of listing individual
> years (@samp{2008, 2009, 2010}) if and only if: 1)@tie{}every year in
> the range, inclusive, really is a ``copyrightable'' year that would be
> listed individually;

That is a problem here, for these little scripts.  For example, for
gunzip.in, only 2007 is a copyrightable year.  The changes made to
gunzip.in since 2007 are not copyrightable (all they do is change the
form or the year of the copyright notice itself).

The above-quoted advice in maintain.texi seems to be designed for a
package comprised of lots of little files that are assembled into a
big executable, where the little files themselves are useless on their
own.  A later part of maintain.texi says the advice does not apply to
files imported from gnulib, which makes sense, since the gnulib files
are useful on their own.

gzip's little shell scripts are another example where that advice does
not apply, because they also are useful on their own.  Let's take
gunzip as an example: it is a standalone program, which operates by
itself and do not require the other components of gzip: it is a simple
wrapper around GNU gzip and it can be used just as easily with a gzip
clone.

Since gunzip is a visually perceptible copy of an individual work (in
the sense of U.S. copyright law), its copyright notice is supposed to
reflect the last copyrightable change to that individual work, not the
last change made to anything in the gzip package (the collective work
that it is part of).  Since the last copyrightable change to gunzip
was made in 2007, if we change its copyright notice to say "Copyright
2010", that's a defective copyright notice, which (legally speaking)
is the same as having no copyright notice at all.

I can understand why we don't want the hassle of maintaining
individual copyright years on each little file in every package, but I
don't see how we can avoid it, the way that gunzip and friends are
written now.

One possible way to address this problem would be to reword the
notices in gunzip so that they are not defective.  Perhaps, for
example, we could replace this:

   #!/bin/sh
   # Uncompress files.  This is the inverse of gzip. 

   # Copyright (C) 2007 Free Software Foundation

   ...

   version="gunzip (gzip) @VERSION@
   Copyright (C) 2007 Free Software Foundation, Inc.
   This is free software.  You may redistribute copies of it under the terms of
   the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
   There is NO WARRANTY, to the extent permitted by law.

   Written by Paul Eggert."

with this:

   #!/bin/sh
   # Uncompress files.  This is the inverse of gzip. 

   # This program is distributed as part of gzip, which is
   # Copyright (C) 2010 Free Software Foundation

   ...

   version="gunzip (gzip) @VERSION@
   gzip is Copyright (C) 2010 Free Software Foundation, Inc.
   This is free software.  You may redistribute copies of it under the terms of
   the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
   There is NO WARRANTY, to the extent permitted by law.

   Written by Paul Eggert."

If that's OK legally, then we could do that and update maintain.texi
accordingly.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]