Subject: Update and document criteria for inclusion in /usr/share/common-licenses

From: Sean Whitton <[email-masked]>
Date: Fri, 29 Dec 2017 09:49:44 +0000

Package: debian-policy
Severity: important
X-debbugs-cc: [email-masked]
Control: block 795402 by -1
Control: block 883966 by -1
Control: block 884223 by -1
Control: block 884226 by -1
Control: block 884227 by -1
Control: block 884228 by -1
User: [email-masked]
Usertags: normative discussion

Hello [email-masked],

Our current criteria for including licenses, as Markus Koschany smartly
puts it in #884228, is "[a]pparently something between gut feeling and
the popularity of our least preferred license in common-licenses."  We
can and should do better than this.

In the air is also the idea that we include licenses in common-licenses
to save disk space on low disk space systems: the license should be
popular enough such that the reduced size of d/copyright files will
outweigh the increased size of base-files.

We should write down our criteria in Policy, in section 12.5 (or
possibly in the Policy Changes Process appendix).  We should probably
say too that the application of the criteria is at the discretion of the
Policy Editors.  Before we can do that, however, we need to consider
whether the criteria need to be updated.

The only point of clear consensus -- at least among the Policy Editors
-- is that short licenses which have more than one popular variant
should never be included because of the risk that packages licensed
under one variant incorrectly refer to a different variant in
common-licenses.  This problem actually exists in the archive because a
BSD variant was included in common-licenses at some point.  We should
include this point the Policy Manual.

Otherwise, here are some of the arguments on the table:

(1) In a related d-devel thread, someone working with embedded systems
suggested that these days, either a system has enough disk space that
common-licenses isn't relevant, or it has so little disk space that all
of /usr/share/doc must be deleted.  If this is right, disk space
concerns should not decide what goes into common-licenses.  Is it right?

(2) Some people want more licenses in common-licenses because they find
it more convenient.  Convenient processes save our volunteers' time.  We
frequently get requests to expand common-licenses and I suspect that
many of them are motivated by the belief that it would make the
requestor's work more convenient.  If disk space issues aren't relevant
anymore, an increase in convenience might become a dominating criterion
for inclusion.  However, this point has been disputed: better tools
could provide license text formatted suitably for d/copyright, which
would be just as convenient (e.g., in Emacs: `C-u M-!
get-formatted-license GPL-3` would be about as convenient as it gets).
And there surely exist those who find common-licenses makes editing
d/copyright less convenient...

I'm not sure how to proceed.  It would be nice to verify (1) with other
people working with embedded systems.  Possibly we should ask on one of
our more specialised mailing lists.  And there are surely other
arguments besides (1) and (2).  We should gather those in this bug.

#884228 has further points of discussion, but I'd ask that we restrict
ourselves in this bug to discussing what the criteria for inclusion
should be.  In particular, let's not discuss the proposal to add all
known DFSG-free licenses to common-licenses.  Whether that proposal is
valid depends on our criteria for inclusion, so let's stick to hashing
our those criteria in this bug.

-- 
Sean Whitton