Bug#975250: clarify gathering together of copyright information

[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

[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

[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

[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

[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

[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#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian

[Ansgar]

On Tue, 2020-12-01 at 08:00 -0500, Sam Hartman wrote:
> > > > > "Ansgar" == Ansgar   writes:

    Ansgar> using other choices of "Rules-Requires-Root" than "no" and
    Ansgar> "binary-targets".  The query [1] found two uses:

Can you help me understand how options other than binary-targets or no
were supposed to work/what they make possible?
I have found the policy text in this area a bit opaque.
I'd like to understand what we'd be giving up if we adopt your
proposal.

Is this facility not used simply because everyone reads it and like me
goes "huh what does that really mean," and never gets around to
thinking it through? Or is it an extension point we actually don't
need?

It looks like it is designed to allow even smaller parts than the
"binary" targets as a whole to run without fakeroot, but (IMHO) the
goal should be to move away from having d/rules require root for
anything at all. So to me it looks like an extension point that is not
needed.

That the *only*[1] user in the archive after several years is libcap2
seems to support this hypothesis.  Also libcap2 uses it for tests that
explicitly require real root, yet Rules-Requires-Root says:

+---
| This field intentionally does not enable a package to request a true 
| root over fakeroot.
+---[ Policy 5.6.31.1 ]

To run tests as root, we have autopkgtest. This doesn't happen at build
time, but buildds don't offer real root anyway, so not much of a
difference.

Also, how much of the complexity cost you are concerned about has
already been paid and how much of it is ongoing? Ignore for the moment
> maintenance in packages like dpkg-dev and sbuild.
I'm basically asking how many new tools over time are likely to need to
care about this complexity if we keep it.

You don't only need to implement it and maintain the implementation,
but when you teach people about Debian packaging (or they read Policy
to learn about it), you need to teach people about this. That's an
ongoing cost.

The R³ parts currently require two sections (5.6.31 and 4.9.2) with
several subsections (5.6.31.1 to 5.6.31.3).  That is a lot for
something only a single package uses (and for a usecase that R³ is
explicitly not supposed to cover).

There are other problems like any package trying to use a non-standard
or new keyword will regress to the old "binary-defaults" default until
all tools are updated to support the new keyword.  That the list of
keywords is intentionally incomplete also makes it hard to implement in
tools.

I appreciate that you probably do care about the maintenance costs in
dpkg-dev, but our value functions probably diverge a bit there.

dpkg-dev can continue to main the support if wanted; there are other
functions dpkg support, but that aren't used in the Debian archive like
I believe vendor patch series.

Ansgar

Bug#975250: clarify gathering together of copyright information

[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#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian

[Sam Hartman]

> "Ansgar" == Ansgar   writes:

Ansgar> using other choices of "Rules-Requires-Root" than "no" and
Ansgar> "binary-targets".  The query [1] found two uses:

Can you help me understand how options other than binary-targets or no
were supposed to work/what they make possible?
I have found the policy text in this area a bit opaque.
I'd like to understand what we'd be giving up if we adopt your proposal.

Is this facility not used simply because everyone reads it and like me
goes "huh what does that really mean," and never gets around to thinking
it through?
Or is it an extension point we actually don't need?

Also, how much of the complexity cost you are concerned about has
already been paid and how much of it is ongoing?
Ignore for the moment maintenance in packages like dpkg-dev and sbuild.
I'm basically asking how many new tools over time are likely to need to
care about this complexity if we keep it.
I appreciate that you probably do care about the maintenance costs in
dpkg-dev, but our value functions probably diverge a bit there.