Robert Ernst <[email protected]> writes: > Also I kindly remark my still open questions regarding:
> - Is there enough manpower in the debian policy team? No, not really. > - Who is part of the debian policy team besides of the two delegates > - Russ Allbery (rra) > - Sean Whitton (spwhitton) Currently, that is the entirety of the Policy team, although anyone can do any of the steps of driving policy changes except for the final merge and uploads (and Sean has been doing a great job getting those uploaded). I personally have been absolutely swamped with non-Debian stuff for quite some time and have managed only very rare bursts of activity. I had at one point planned out next steps for resolving all the requests to add new licenses to base-files. The root problem is that it's not clear what the rest of the project expects in terms of license inclusion in base-files, and we need to pin that down so that we have a somewhat objective criteria. That should likely be a debian-devel conversation that's actively guided to reach some sort of consensus, and I suspect some sort of straw polling would be useful since there are a lot of opinions and it's the sort of topic where we may not be able to judge the consensus of the project purely from the discussion. Things that I think need to be resolved: * What criteria should be used to decide on inclusion? Pure number of packages that use a license (plus it needing to be DFSG of course)? Or something else instead or in addition, and if so, what, and how do we judge it? If we're using number of packages, is that number of source packages or number of binary packages? * Should we include or exclude "short" licenses (by some definition of short)? At one point (if any) is a license so brief that the indirection to common-licenses is more trouble than it's worth? * What do we do about "templated" licenses whose exact wording changes from package to package? We already include one of those in base-files (BSD), which contains language specific to the Regents of the University of California, and therefore technically the BSD common-license file is arguably unusable by any package where the sole copyright holder is not the Regents of the University of California even if it has the same licensing terms. Do we rule out templated licenses entirely and not include them (except maybe grandfathering the BSD license because removing them is hard)? Is it a bug to reference the current BSD license file because of this? * If we are basing inclusion on number of packages, what's the number of packages threshold we should use? If we get consensus on those, I think we can plow through the dozen or so open bug reports about common-licenses inclusion pretty quickly, but I don't like making these decisions ad hoc about each individual license. We're long-overdue for making a project-wide decision about what does and doesn't go into common-licenses. It would probably be helpful to start that discussion with a straw-man proposal that asserts possible answers to each of those questions. That tends to make the discussion more concrete and drive more quickly to the points of disagreement. (I personally would exclude both short and templated licenses and otherwise decide purely on the number of binary packages that use a given license. I'd need to do some research on the best threshold, but my guess is that something between 200 and 500 packages would be a conservative choice.) I personally do not currently have the bandwidth to try to guide that consensus discussion. Anyone who does should feel free to use or repeat anything in this message if it's helpful. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
