[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#768292: debian-policy: please allow copyright file to refer to license text in separate files



On 06/11/14 12:17, Tobias Frost wrote:
> just maybe another datapoint, as recently there was a similar dicussion on
> d-devel, the thread started as
> https://lists.debian.org/debian-devel/2014/09/msg00704.html (difference: This
> was a question brought up by Markus if it is sufficient to referencfe to the
> common licenses)

My understanding is that Markus' question in that thread was orthogonal:
"is the exact license grant really required, or is the license itself
enough?" (for terminology see my reply at
<https://lists.debian.org/debian-devel/2014/09/msg00708.html>).

I would also appreciate a canonical answer on that, which I think would
also have to come from the ftp-masters. In both cases, if the
ftp-masters could clarify what they want and why, I would be happy to
propose Policy wording (here or on a separate bug as desired).

Sorry, but I'm not going to propose concrete Policy wording for this
without knowing the requirements (and preferably the reasoning behind
those requirements), because I think a highly specific Policy that does
not match the actual requirements for the archive, in either direction,
would be worse than the current vague Policy wording: I don't want to
make maintainers do work that the ftp-masters do not actually require
(because the more time I have to spend writing copyright files, the less
interesting packaging becomes), and I don't want to make maintainers
think they can skip things that the ftp-masters do in fact require
(because packages that don't pass NEW on the first attempt waste
everyone's time).

If there is a better way to get a canonical answer from the ftp-masters
(ftp.debian.org bug?) I'm happy to take these questions there.

I'm deliberately not pointing to specific packages that are not
necessarily policy-compliant as test-cases, because I don't really want
to point the "potential RC bug" shotgun at specific packages if those
packages are actually fine in practice. However, if the only way to
determine what is required is to point fingers, name names, and
reverse-engineer requirements from whether those packages attract RC
bugs or are removed from the archive, I could make a note to try that
post-jessie...

    S


Reply to: