Bug#975250: clarify gathering together of copyright information

2020-12-14 Thread Sean Whitton
Hello Sam,

On Tue 01 Dec 2020 at 08:07AM -05, Sam Hartman wrote:

> * 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.

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

On Sat 21 Nov 2020 at 12:30PM -08, Russ Allbery wrote:

> 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.

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).

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#975250: clarify gathering together of copyright information

2020-12-07 Thread Marc Haber
On Tue, Dec 01, 2020 at 08:07:34AM -0500, Sam Hartman wrote:
> * Holder, you and I would prefer that you be able to collapse years.

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

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



Bug#975250: clarify gathering together of copyright information

2020-12-01 Thread Holger Levsen
On Tue, Dec 01, 2020 at 02:03:59PM -0500, Sam Hartman wrote:
> 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.

that. and what Bill said.

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


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

If secure encryption is outlawed, only criminals will have it.


signature.asc
Description: PGP signature


Bug#975250: clarify gathering together of copyright information

2020-12-01 Thread Sam Hartman
> "Bill" == Bill Allombert  writes:

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.



Bug#975250: clarify gathering together of copyright information

2020-12-01 Thread Bill Allombert
On Tue, Dec 01, 2020 at 02:03:59PM -0500, Sam Hartman wrote: > > "Russ" == 
Russ Allbery  writes:
> 
> 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.
> 
> On the compromise front, how would people feel about leaving the gap
> years question ambiguous in policy?

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. 

Imagine a large red swirl here. 



Bug#975250: clarify gathering together of copyright information

2020-12-01 Thread Sam Hartman
> "Russ" == Russ Allbery  writes:

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?



Bug#975250: clarify gathering together of copyright information

2020-12-01 Thread Russ Allbery
Guillem Jover  writes:

> Personally I see a big distinction between someone doing it for their
> own copyright claims, and doing that for someone else's.

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.

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

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 Allbery (r...@debian.org)  



Bug#975250: clarify gathering together of copyright information

2020-12-01 Thread Guillem Jover
On Thu, 2020-11-26 at 08:55:21 +, Holger Levsen wrote:
> 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.

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

> So if I have contributed to something in 2018 and 2020 I find it ok to claim
> 'Copyright 2018-2020 Holger Levsen'.

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.

> (Also because I might not have commited
> something in 2019 but you have no idea how much I prepared my 2020 commits
> in 2019...)

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

Thanks,
Guillem



Bug#975250: clarify gathering together of copyright information

2020-12-01 Thread Sam Hartman
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.

--Sam



Bug#975250: clarify gathering together of copyright information

2020-11-26 Thread Holger Levsen
On Wed, Nov 25, 2020 at 03:32:04PM -0500, Sam Hartman wrote:
> I'd like to see people chime in who have not participated in the
> discussion yet.
 
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.)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

Never waste a crisis.


signature.asc
Description: PGP signature


Bug#975250: clarify gathering together of copyright information

2020-11-25 Thread Sam Hartman
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.

--Sam



Bug#975250: clarify gathering together of copyright information

2020-11-25 Thread Marc Haber
On Sat, Nov 21, 2020 at 12:30:07PM -0800, Russ Allbery wrote:
> Marc Haber  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:
> 
> >> > +Copyright 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.

... 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.

> The years are an annoying bit of pedantry.  The short version is that US
> copyright law requires a year in the notice,

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:
 Copyright 2008 John Smith
-Copyright 2009 Angela Watts
+Copyright 2003,2009 Angela Watts
 and file B has:
-Copyright 2010 Angela Watts
+Copyright 2005-2015 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
+Copyright 2003,2005-2015 Angela Watts
+  
+  
+   It is important that all copyright years mentioned in the 
+   copyright notice are covered in the coalesced
+Copyright 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).
   
   
 The Copyright field may contain the original

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



Bug#975250: clarify gathering together of copyright information

2020-11-21 Thread Russ Allbery
Sam Hartman  writes:

> 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.

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.  :)

-- 
Russ Allbery (r...@debian.org)  



Bug#975250: clarify gathering together of copyright information

2020-11-21 Thread Sam Hartman
> "Russ" == Russ Allbery  writes:

Russ> Marc Haber  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.


signature.asc
Description: PGP signature


Bug#975250: clarify gathering together of copyright information

2020-11-21 Thread Russ Allbery
Marc Haber  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:

>> > +Copyright 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 (r...@debian.org)  



Bug#975250: clarify gathering together of copyright information

2020-11-20 Thread Marc Haber
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:
> 
> > +Copyright 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.

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 | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



Bug#975250: clarify gathering together of copyright information

2020-11-20 Thread Sean Whitton
Hello,

Thanks for the patch.

On Fri 20 Nov 2020 at 03:23PM +01, Marc Haber wrote:

> +Copyright 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.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#975250: clarify gathering together of copyright information

2020-11-20 Thread Marc Haber
On Thu, Nov 19, 2020 at 12:02:48PM -0700, Sean Whitton wrote:
> The former.  If you'd like to propose a patch making this clearer we
> could get it applied.

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
 Copyright 2008 John Smith
 Copyright 2009 Angela Watts
 and file B has:
-Copyright 2010 Angela Watts
+Copyright 2005-2015 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
+Copyright 2005-2015 Angela Watts
+  
+  
+   It is important that all copyright years mentioned in the 
+   copyright notice are covered in the coalesced
+Copyright 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.
   
   
 The Copyright field may contain the original

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



Bug#975250: clarify gathering together of copyright information

2020-11-19 Thread Russ Allbery
Marc Haber  writes:

> 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

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 - 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.

-- 
Russ Allbery (r...@debian.org)  



Bug#975250: clarify gathering together of copyright information

2020-11-19 Thread Sean Whitton
Hello,

On Thu 19 Nov 2020 at 05:07PM +01, Marc Haber wrote:

> /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
>
> ?

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

-- 
Sean Whitton



Bug#975250: clarify gathering together of copyright information

2020-11-19 Thread Marc Haber
Package: debian-policy
Version: 4.5.0.3
Severity: minor

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