Collapsing copyright year lists to ranges

[Joseph S. Myers]

It was recently confirmed for GDB
<http://sourceware.org/ml/gdb-patches/2012-01/msg00936.html> that it's OK
to collapse a list of copyright years into a single range (given the
required README statement about ranges) even if there were gaps in the
original list.  This is inline with the principle described in
maintain.texi that you only need to track years when nontrivial changes
were made to the package as a whole, not which files were changed in each
year.

When I suggested doing this for glibc, the question was raised about
whether that ruling applied to all GNU packages and whether the ruling was
properly documented.  It seems like quite a common issue for packages
converting to ranges, so documenting in maintain.texi would seem like a
good idea.

In particular, the rule about adding all years when the whole package was
changed comes with the caveat "(Here we assume you're using a publicly
accessible revision control server, so that every revision installed is
also immediately and automatically published.)".  That's sufficient for
new years, but what about older ones when the package may not have had
public version control (or may have had version control that was private
at the time with the history later made public)?  Could a rule for
collapsing to ranges be documented that makes it clear when in such cases
it's OK to use a range even though the years previously listed in the file
had some intermediate years missing?

--
Joseph S. Myers
joseph@...

[Karl Berry]

Hi Joseph,

    It was recently confirmed for GDB
    <http://sourceware.org/ml/gdb-patches/2012-01/msg00936.html>
    that it's OK to collapse a list of copyright years into a single
    range

I saw that in passing.  The rules currently in maintain.texi came
directly from rms + lawyers, after Jim Meyering pushed the issue a
couple years ago.  They are not the same as what Donald told Joel in RT
#719834 (although what Donald said is also logical).

I guess I will start by asking Donald.  I'll keep you posted.

    that ruling applied to all GNU packages

Whatever the rule is certainly applies to all GNU packages.
Donald wasn't describing a special case for GDB.

Best,
karl

[Karl Berry]

Hi Joseph,

    It was recently confirmed for GDB
    <http://sourceware.org/ml/gdb-patches/2012-01/msg00936.html> that it's OK
    to collapse a list of copyright years into a single range

I discussed this with Donald.
He didn't intend to go beyond what is already stated in maintain.texi.

The crucial question is whether a package was published in a given
year.  Such publication could be done in any of several ways:
- an actual release of a new version, of course.  Either public or beta.
- being in a public VC repository; then publication is automatic and
  continuous.
- making an interim release intended for further redistribution.
  For example, if the package ended up in a Cygnus release in a given year.

Given that a package as a whole was published in a given year, it is ok
to include that year in the range for all files in the package.  It's
not necessary for the individual file to have been modified.

However ... if a package was not published in any form during a given
year, then it is not ok to include that year in the range.  And
unfortunately, I expect that is the case for some of the early years in
gcc/glibc/gdb/etc.

So ... the most expedient approach I can imagine would be to determine
the year that the sources were put into a public VC.  Say that was 1995.
Then keep all the years prior to 1995 as they are in the copyright line,
and end the list with 1995-2012, obviously just incrementing going
forward.  (Just an idea.)

I'll see if I can clarify the wording in maintain.texi, but the above
was always the intent.  The bottom line is that copyright law does not
let us include a year for which there was no publication at all.

Best,
karl

[Joseph S. Myers]

On Mon, 6 Feb 2012, Karl Berry wrote:

> The crucial question is whether a package was published in a given
> year.  Such publication could be done in any of several ways:

Is it now whether the package was published, as opposed to "each year in
which you finished preparing a version which was actually released, and
which was an ancestor of the current version" as was in maintain.texi
before revision 1.118?  (This affects the cases where previously private
version control was made public, so meaning old development versions were
thereby published.)

--
Joseph S. Myers
joseph@...

[Karl Berry]

    Is it now whether the package was published,

As far as I know, that was always the determining factor wrt actual
copyright law.
   
    as opposed to "each year in which you finished preparing a version
    which was actually released, and which was an ancestor of the
    current version"

Yes, I remember/see that text.  I do not know on what basis rms wrote
it.  But since he himself changed it, I can only conclude that it does
not apply now.  For years now, whenever I have talked about it with rms
(or Donald or anyone else), it is publication years that count.

    This affects the cases where previously private version control was
    made public, so meaning old development versions were thereby
    published.

Well, I can see your idea that if it is "completed years" that count,
rather than "publication years", so that what amounts to retroactive
publication is effective, that older years could get included.

I don't know.  If I ask Donald, I feel pretty sure that he'll just say
"I don't know" -- he wasn't around back then, and anyway, he was just
basing his previous answers on what was written in maintain.texi and his
general knowledge of copyright law, much like you and me.

If I ask rms, I feel even more sure he will say "I have no idea about
something done years ago", and it will take still more effort and lawyer
time to research the issue or even figure out what was meant.

I'll do it if you want, but honestly, it does not seem worthwhile
to me simply for the sake of optimizing the list of old-old years.

Best,
k

[Karl Berry]

    it's OK to use a range even though the years previously listed in the file
    had some intermediate years missing?

Hi Joseph -- back in January, you asked about when it's ok to collapse
copyright years into ranges.  I answered at the time, but it's only now
that I've put together a revised text for maintain.texi.  I hope this is
clearer.  The goal here is not to change the rules in any way, of
course, but to clarify what has been the intent all along, despite the
rather convoluted description.

I haven't committed it yet.  If any questions or suggestions, let me
know.

k


-------------------------------------------------------------------------
The year list should include each @dfn{copyrightable year}.  When the
package sources are maintained in publicly accessible revision control
server, by definition every revision installed is immediately and
automatically published.  In this case, any year in which a nontrivial
change was made to the package counts as a copyrightable year.

If you're not using a public revision control server, then a
copyrightable year is one in which you @emph{completed} (not
necessarily released) a version.  So if you finished a version on
December@tie{}31, 1994 and released it on January@tie{}1, 1995, this
version requires the inclusion of 1994, but doesn't require the
inclusion of 1995.

In either case, when you add a 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; 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.

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; @emph{and} 2)@tie{}you make an explicit statement
in a @file{README} file about this usage.
-------------------------------------------------------------------------