Package: debian-policy Severity: important X-debbugs-cc: apo@debian.org 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: debian-policy@packages.debian.org Usertags: normative discussion Hello debian-policy@l.d.o, 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
Attachment:
signature.asc
Description: PGP signature