Re: Clarifying the mandatory contents of the Debian copyright file.
On Tue, 2012-01-17 at 20:01 -0800, Russ Allbery wrote:
> Peter Miller <pmiller@opensource.org.au> writes:
>
> > My understanding is that all project files are covered, although
> > wildcards are permitted.
>
> > Each different copyright x license combination needs its own separate
> > entry.
>
> I don't think this is the case. [...]
> I am absolutely certain that this is not the intention of DEP-5, and I
> would be in favor of modifying it to make that clear if you could identify
> the places where you got that mistaken impression.
http://dep.debian.net/deps/dep5/
"Files paragraph (Repeatable)
"The declaration of copyright and license for files is done in
one or more paragraphs. In the simplest case, a single paragraph
can be used which applies to all files and lists all applicable
copyrights and licenses."
It says "all applicable copyrights and licenses". Note the "and". To
me, in a standards context, this means conjunction (logical and) not
disjunction (logical or).
If there was some other intent, the words don't say it. Note there are
*three* potentially ambiguous lists in that definition, they *all* need
to be disambiguated in the language of DEP-5.
Look at it from the other perspective:
(a) given filename X, what license(s) apply? Does DEP-5, by conflating
copyrights and licenses, risk returning too many licenses? inapplicable
licenses?
(b) given filename X, what copyright(s) apply? Does DEP-5, by
conflating copyrights and licenses, risk returning too many copyrights?
inapplicable copyrights?
One solution may be to separate it into two paragraphs, one for
applicable copyrights, and one for applicable licenses. That is, you
can have "Files:" && "Copyright:" || "Files:" && "License:", but you
can't have "Files:" && "Copyright:" && "License:"
While I'm banging on about semantics, when you are looking up a file by
name, is it the first file name pattern match that applies, or the last,
or do all of them? It doesn't say.
English is sloppy be default. Standards language should try very had
not to be, even optional standards.
--
Peter Miller <pmiller@opensource.org.au>
Reply to: