Bug#975250: clarify gathering together of copyright information
Marc Haber <mh+debian-bugs@zugschlus.de> writes:
> On Fri, Nov 20, 2020 at 01:58:51PM -0700, Sean Whitton wrote:
>> On Fri 20 Nov 2020 at 03:23PM +01, Marc Haber wrote:
>> > + <varname>Copyright</varname> field. It is ok to have years
>> > + covered that are not listed in the original notices.
>> 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.
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.
> 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.
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 Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: