Hi,

/usr/share/doc/debian-policy/copyright-format-1.0.txt.gz says

|    The Copyright field collects all relevant copyright notices for the files
|    of this paragraph. Not all copyright notices may apply to every individual
|    file, and years of publication for one copyright holder may be gathered
|    together. For example, if file A has:
|
|  Copyright 2008 John Smith
|  Copyright 2009 Angela Watts
|
|    and file B has:
|
|  Copyright 2010 Angela Watts
|
|    a single paragraph may still be used for both files. The Copyright field
|    for that paragraph would contain:
|
|  Copyright 2008 John Smith
|  Copyright 2009, 2010 Angela Watts

But what if file A says

|  Copyright 2008 John Smith
|  Copyright 2005-2015 Angela Watts

    and file B has:

|  Copyright 2010 Angela Watts

Can this be gathered together to:

|  Copyright 2008 John Smith
|  Copyright 2005-2015 Angela Watts

or does it have to be

|  Copyright 2008 John Smith
|  Copyright 2009, 2005-2015 Angela Watts

?

Greetings
Marc

Hello,

The former.  If you'd like to propose a patch making this clearer we
could get it applied.

Marc Haber <mh+debian-packages@zugschlus.de> writes:

I'm fairly sure the answer in practice is yes.  I've been uploading
packages like this for some time without any issues, and I would be very
surprised if ftp-master would object.

I think we may need to be a bit more verbose in explaining how copyright
statements can be coalesced to make this clear.  Some GNU projects use
wording like this:

   For any copyright year range specified as YYYY-ZZZZ in this file, the
   range specifies every single year in that closed interval.

and maybe we should import something like that into our specification as
well as say explicitly that you're allowed to coalesce copyright
statements from multiple files into a single copyright notice as long as
all of the listed authors and years are covered.

How about this:

diff --git a/copyright-format-1.0.xml b/copyright-format-1.0.xml
index b8df359..71d7c1c 100644
--- a/copyright-format-1.0.xml
+++ b/copyright-format-1.0.xml
@@ -559,12 +559,21 @@ License: MPL-1.1
 <programlisting>Copyright 2008 John Smith
 Copyright 2009 Angela Watts</programlisting>
         and file B has:
-<programlisting>Copyright 2010 Angela Watts</programlisting>
+<programlisting>Copyright 2005-2015 Angela Watts</programlisting>
         a single paragraph may still be used for both files.  The
         <varname>Copyright</varname> field for that paragraph would
         contain:
 <programlisting>Copyright 2008 John Smith
-Copyright 2009, 2010 Angela Watts</programlisting>
+Copyright 2005-2015 Angela Watts</programlisting>
+      </para>
+      <para>
+       It is important that all copyright years mentioned in the
+       copyright notice are covered in the coalesced
+        <varname>Copyright</varname> field. It is ok to have years
+        covered that are not listed in the original notices. You are
+        allowed to coalesce copyright statements from multiple files
+        into a single copyright notice as long as all of the listed
+        authors and years are covered.
       </para>
       <para>
         The <varname>Copyright</varname> field may contain the original

Greetings
Marc

Hello,

Thanks for the patch.

I don't think we can assume it is okay to do this.  You can combine
2009--2015 and 2020 into just 2009--2015, but I don't think we should
encourage combining 2009--2011 and 2013 into 2009--2013.

That is what I assumed from the GNU wording quoted by Russ.

What is the relevance of the years in leftpondian copyright law anyway?
Over here, copyright expires a certain time after the copyright holder's
death.

Greetings
Marc

Marc Haber <mh+debian-bugs@zugschlus.de> writes:

The wording was used by upstream so the implication is that upstream is
asserting copyright changes in each of those years.  If we broaden that
range, we're effectively adding copyright claims of additional years that
aren't necessarily true.  I have a hard time imagining that it would ever
matter, but pedantically one cannot say 2009-2013 if no copyrightable
changes happened in 2012.

In reality, this only matters because we have licenses that say it
matters.  For example, the BSD license saying:

1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer.

We're already arguably not *quite* following that rule by allowing
coalescing of notices.  I think that's fine because (at least in US law)
the copyright notice is soemthing with a legal definition and the
coalesced form is legally equivalent, so we're preserving the notice in
the way that matters.  But in order to rely on that argument, it feels
like we should keep the notice legally equivalent, which would mean not
adding years.

The years are an annoying bit of pedantry.  The short version is that US
copyright law requires a year in the notice, and that year is supposed to
represent a year in which a copyrightable change was "published."  The FSF
a long time back got legal counsel here and published guidance in the GNU
Maintainer Guidelines, and since I've never wanted to reproduce that work,
I tend to just follow them.  They say:

    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.

    You can use a range (‘2008-2010’) instead of listing individual years
    (‘2008, 2009, 2010’) if and only if: 1) every year in the range,
    inclusive, really is a “copyrightable” year that would be listed
    individually; and 2) you make an explicit statement in a README file
    about this usage.

Is this more pedantic than is necessary to comply with the law?  Probably,
plus copyright notices only matter in the law for damage claims and it's
really hard to imagine a scenario in which any of this will matter.  Do
upstreams in general pay attention to this and have correct notices?
Almost certainly not.  But it's one of those topics where if one asks,
this is the answer that people have gotten, even though it's kind of
silly.

Therefore, where I personally land is that we should try to make the
Policy guidance correct (but as simple as possible), and then we should
not care if people don't exactly follow it because in truth it's not going
to matter.

    Russ> Marc Haber <mh+debian-bugs@zugschlus.de> writes:
    Russ> The years are an annoying bit of pedantry.  The short version
    Russ> is that US copyright law requires a year in the notice, and
    Russ> that year is supposed to represent a year in which a
    Russ> copyrightable change was "published."  The FSF a long time
    Russ> back got legal counsel here and published guidance in the GNU
    Russ> Maintainer Guidelines, and since I've never wanted to
    Russ> reproduce that work, I tend to just follow them.  They say:

The years matter because at least under  US law, the most recent year in
which a change happened affects how long copyright potentially lasts.

fsf>     Don’t delete old year numbers, though; they are
fsf> significant since they indicate when older versions might
fsf> theoretically go into the public domain, if the movie
fsf> companies don’t continue buying laws to further extend
fsf> copyright. If you copy a file into the package from some other
fsf> program, keep the copyright years that come with the file.

I appreciate that the FSF cares about old years and things going into
public domain.  I think that we should value being able to coalesce
years more than we value that pedantry.  I think the FSF has adequately
explained the legal rationale for their view, I think their legal
reasoning is sound (so we can rely on it), and I think it doesn't apply
to our needs (so we can do something else).

I don't think we should go so far as to only list the most recent year,
but I do think we should collapse things down to a range in
debian/copyright.

I always assumed from the current wording we could do so
and it's a significant surprise to me that you are arguing we cannot.

Obviously we should leave the notices in source files alone.

Sam Hartman <hartmans@debian.org> writes:

I personally don't particularly care, so if that's the consensus, I'm
happy to go with that.  Perhaps I'm being too pedantic.

For whatever it's worth, I've never assumed we can coalesce years in a way
that drops gaps, and never have done so myself, so it's obvious that we
should write something down since two people who have both worked in
Debian for a very long time had different understandings of what was
allowed.  :)

... and the new copyright format was devised to trigger pedantery. I must add
that I absolutely hate the idea of spending more time with the copyright file
than with actual packaging (happened to me twice in the last month alone), but
technically that was alwas expected from us as DDs and if the project wants to
have us doing busy work, then so be it.

ok, that's a clear point.

Here is a new suggestion:

diff --git a/copyright-format-1.0.xml b/copyright-format-1.0.xml
index b8df359..12a84de 100644
--- a/copyright-format-1.0.xml
+++ b/copyright-format-1.0.xml
@@ -557,14 +557,24 @@ License: MPL-1.1
         publication for one copyright holder may be gathered together.  For
         example, if file A has:
 <programlisting>Copyright 2008 John Smith
-Copyright 2009 Angela Watts</programlisting>
+Copyright 2003,2009 Angela Watts</programlisting>
         and file B has:
-<programlisting>Copyright 2010 Angela Watts</programlisting>
+<programlisting>Copyright 2005-2015 Angela Watts</programlisting>
         a single paragraph may still be used for both files.  The
         <varname>Copyright</varname> field for that paragraph would
         contain:
 <programlisting>Copyright 2008 John Smith
-Copyright 2009, 2010 Angela Watts</programlisting>
+Copyright 2003,2005-2015 Angela Watts</programlisting>
+      </para>
+      <para>
+       It is important that all copyright years mentioned in the
+       copyright notice are covered in the coalesced
+        <varname>Copyright</varname> field. It is ok to have years
+        covered that are not listed in the original notices. You are
+        allowed to coalesce copyright statements from multiple files
+        into a single copyright notice as long as all of the listed
+       authors and years are covered (and no not listed years are
+       accidentaly included).
       </para>
       <para>
         The <varname>Copyright</varname> field may contain the original

Greetings
Marc

I'd like to see people chime in who have not participated in the
discussion yet.
I prefer your original text but we'd need to get support for it.
It sounds like we're fairly evenly split among the current participants
in the issue.

AIUI the first year of contributions and the last year of contributions are
important data points for each contributor for a project, and mostly only
the last year as that might be used to calculate when a project becomes
public domain after the dead of an author.

So if I have contributed to something in 2018 and 2020 I find it ok to claim
'Copyright 2018-2020 Holger Levsen'. (Also because I might not have commited
something in 2019 but you have no idea how much I prepared my 2020 commits
in 2019...)

IANAL :) (and please correct me where I'm wrong, half right or whatever.)

Here's my take on the discussion so far.
And I want to stress that I am not a policy editor, and to the extent
that they read the discusssion differently than I do, their reading
controls.

* Russ and I would be willing to accept either outcome--either you can
  collapse years or you cannot.

* Holder, you and I would prefer that you be able to collapse years.

* Sean would prefer that you not be able to collapse years.  He hasn't
  said whether his objection is strong enough to try and block
  consensus.

* I think there is a strong consensus that we want to make a change
  along the lines of one of your patches.

* I don't think anyone in the discussion so far would object to your
  second patch.  However, a majority of the participants might prefer
  your first patch.  Sean might object to that, and Russ might
  potentially think we haven't yet gotten enough showing of support to
  go that direction.

This is one of those awkward situations in consensus decision making
where you have to decide whether you're going to take the option
everyone can live with or do a bit more work and possibly get  an answer
that the community overall supports (even though some people do not).
What we should definitely avoid doing is losing energy and making no
change at all.

The first year might also be relevant in infringement cases where
provenance might be disputed, but probably less so with a VCS at hand.

Personally I see a big distinction between someone doing it for their
own copyright claims, and doing that for someone else's. For example
as was pointed out in the thread, GNU projects tend to do a global
copyright year bump commit at the beginning of the year updating all
the FSF notices, even for things that might otherwise end up not being
changed that year (but which I don't practice as it makes me a bit
uncomfortable).

While I've had no qualms whatsoever on coalescing claimed copyright
years into ranges, for a long time now, even for licenses that state
the copyright notice needs to be preserved (such as BSD), I've always
understood that to preserve the intent of the license, and I've
considered this pretty much accepted practice in the project. But I'd
be very uncomfortable claiming (unclaimed) copyright years on someone
else's behalf (say «© 2008, 20010-2015» into «© 2008-2015»), and
that's something I'd not consider doing.

AFAIUI when and what you have done before publication does not count when
it comes to copyright, only the publication date does.

Thanks,
Guillem

Guillem Jover <guillem@debian.org> writes:

Yeah, this is where I'm at too.  It feels weird, and I'm not sure it's
technically compliant with the license requirement to preserve the
copyright notice for those licenses that have it.

That said, I tend to be hyper-conservative and nit-picky about things like
this, accurately representing copyright years isn't in my top thousand
things I want people to work on in Debian, and I'm highly dubious that it
will ever matter or anyone will ever care.  So I'm very open to being told
I'm being much too cautious.

Yes, this is also my understanding, with the caveat that I only have read
the US law in any detail and I don't know to what extent it varies.  (I
know Berne mostly standardizes copyright, but mostly isn't entirely and
there are countries with fairly significant differences, such as moral
rights.  I have no idea how universal the exact semantics of copyright
notices are under Berne.)

Here's the circular from the US Copyright Office on notices, for whatever
it's worth:

https://www.copyright.gov/circs/circ03.pdf

    Russ> That said, I tend to be hyper-conservative and nit-picky about
    Russ> things like this, accurately representing copyright years
    Russ> isn't in my top thousand things I want people to work on in
    Russ> Debian, and I'm highly dubious that it will ever matter or
    Russ> anyone will ever care.  So I'm very open to being told I'm
    Russ> being much too cautious.

My rationale is that debian/copyright is a summary, it's not the license
text in the files.
I absolutely agree we shouldn't go change people's actual copyright
notices in the files.

And, I'm fairly convinced that it can never hurt us.  I mean if someone
came along and actually bothered to send us a legal letter, or even a
strongly worded bug report as a copyright holder, we'd go  use their
preferred notice.
What sort of damage are they going to be able to show because we listed
2009-2020 instead of 2009, 2012, 2019-2020.

As a copyright holder I'd probably be more annoyed at the hyphen instead
of the n-dash rather than the notice.  But that's  just me.

But I totally understand we're well into bikeshedding here.

On the compromise front, how would people feel about leaving the gap
years question ambiguous in policy?
That is, we clearly agree you can combine years across files, our
question is whether you can insert years that appear in no file.
Could we just sidestep the issue and leave that ambiguous?

On Tue, Dec 01, 2020 at 02:03:59PM -0500, Sam Hartman wrote: > >>>>> "Russ" == Russ Allbery <rra@debian.org> writes:

Let us be honest with ourselves: what matter for most purpose
is the position of the ftp-master team that processes the NEW queue.
What policy says is secondary.

Cheers,

    Bill> Let us be honest with ourselves: what matter for most purpose
    Bill> is the position of the ftp-master team that processes the NEW
    Bill> queue.  What policy says is secondary.

I absolutely agree we should coordinate appropriately with the ftp team.

that. and what Bill said.

oh dear, you've send me into a small rabbit hole researching the distinctions
between hyphen, dash, hyphen-minus and the minus sign... :) thanks! :)

Basically, I want to reduce the horrible busy-work of creating and
maintaining debian/copyright files to the barely acceptable minimum. I
literally spent days in the last weeks just to collect copyright stuff
that I would rather have spent with technical work.

Greetings
Marc

Hello Sam,

My initial comments were motivated by the very same concerns as Russ:

If there is a consensus within the FTP Team that collapsing years does
not violate this sort of condition in the text of licenses, then (qua
Policy Editor) I would be happy to permit collapsing years.  I have made
some enquiries to try to determine whether the FTP Team has a consensus
view on this.

If the FTP Team is not really sure whether this sort of thing is okay,
we could permit collapsing years just when the license does not have a
copyright notice reproduction requirement (see the changes in #955005
for another example of making Policy copyright notice requirements
conditional on particular licenses).