Contents

  1. Suggestions for guidelines by the developer community for accepting packages into Debian
    1. Licensing
      1. Examples for non-rejects
        1. r-bioc-basilisk
        2. r-rcan-urlchecker
        3. foo
    2. Copyright
      1. Examples for non-rejects
        1. Creative Commons "Public Domain Dedication" license (CC0-1.0)
        2. foo
    3. Changes of binary names
    4. Splitting new processing into technical and copyright part
    5. Make packages in NEW available for apt
    6. Processing sequence of packages in the new queue
    7. Helpful hints by ftpmaster for package maintainers
      1. Provide coded information
      2. Please CC WNPP bug

Suggestions for guidelines by the developer community for accepting packages into Debian

This page is work in progress. Its created in the hope that we can finally fix the criticism raised in someLWN article that a long discussion on debian-devel list "did not result in anything resembling a policy change". It should serve as a place to adjust the rules we want to apply as a community to match the requirements for accepting packages into the Debian distribution. Currently those rules are split over several places like some aging E-mails like this or this or this, a REJECT-FAQ and a lot of "learning by failure experiences". The rules are currently fixed by the FTPMaster team.

The idea of this Wiki page is to coordinate the work of FTPMaster and packaging developers to match the requirements of the whole Debian community. We are all dedicated to technical excellence and our goal is to provide the best possible code to our users. This works best if we show respect for the upstream authors to fully respect their copyright and follow the license they have written in their released codes. However, it has turned out that striving for excellence in writing debian/copyright files might lead to some friction which might delay the process to bring free code to our users. To find some agreement what is acceptable for inclusion into Debian and what not as well as providing alternatives for the rejection lets collect some ideas here and vote about something we consider a consensus for our community.

We have regular longish discussions on debian-devel list which are time consuming but to not really lead into some change. There are several interesting ideas hidden in our mailing list archives. One specifically interesting one is the idea to involve lawyers to do some risk estimation. Others considered using Debian funds to pay lawyers in this branch of the discussion. While this are definitely interesting aspects of the discussion it is not covered explicitly on this wiki page (yet).

The complexity of finding some consensus lays in the nature of multiple roles of d/copyright and we possibly even need to adjust policy to implement the suggestions made here.

Licensing

The REJECT-FAQ says about licenses: We often find packages having a GPL COPYING file in the source, but if one goes and looks at every file, there are a few here and there having different licenses in them, ... So we should definitely check for files that are not compliant with DFSG or might feature two different free licenses that are not compatible with each other (like GPL-2 and Apache-2.0).

Moreover REJECT-FAQ says in License III: You need to list all copyright information with all licenses in the copyright file itself. That one has to be the single point of information. This was Revised Dec 2008. May be its time to revise it again?

Sometimes a package is rejected due to missing license statements of a few files which are not in conflict with DFSG. As it is mentioned in a thread on debian-devel list our assumption that a debian/copyright file has to be complete is possibly not up to date. It might make sense that we are reviewing the procedure to accept only those packages inside Debian who are featuring a 100% complete copyright file and just require a DFSG free code. It could be helpful if the FTPMaster team member who is inspecting a package simply could file a bug report "Missing license statement in copyright file" and accepts the package anyway. The advantage of this procedure would be that FTPMaster work on this package is done and reduces the time for this package on all sides.

Examples for non-rejects

r-bioc-basilisk

FTPMaster was asking to mention the MIT license of the test-dummy package since upstream decided that this test package should have a different license than the rest of his software and said so in the corresponding setup.py. The statement of FTPMaster is based on line 9 of a 12 line of code example file. It contains the string license='MIT' while all other code of the package is GPL-3.

r-rcan-urlchecker

FTPMaster was asking to mention GPL-2+ while all other code was covered by GPL-3. This somehow ignores the "or later" clause in GPL-2+ and thus should be no reason for a reject.

foo

If you know other examples that should be accepted please add here

One main reason for specifying copyright inside debian/copyright file is to be legally safe and another good reason is to reward the owner of the code we package the necessary respect. However, there are cases when code has been put into public-domain which means the author(s) of the code are explicitly not claiming any copyright. In cases like this the rejection of a package where the copyright information about non-copyrighted code does not seem to be appropriate.

Examples for non-rejects

Creative Commons "Public Domain Dedication" license (CC0-1.0)

Several Python packages are containing the 2kB file (versioneer.py like in propka which was rejected). A missing Files stanza for CC0-1.0 should not be a reason to reject the package as that increases the overall turn-around time substantially. Rather, it is a candidate for accepting and filing a bug report with appropriate severity to make sure it is tracked.

foo

If you know other examples that should be accepted please add here

Changes of binary names

Packages that are inside Debian but change the name of binary packages for some reasons are ending up in the new queue. This is due to some limitation of dak. However, in several statements FTPMaster team members are claiming that this is no bug but a feature to review the package again. Scott Kitterman gave his personal view on this topic in his mail:

  1. When the SO name changes and the binary package name is adjusted accordingly, it is not super rare for the maintainer to mess something up in the renaming and end up with an empty binary package, which does no one any good. I note that for debhelper compat 15 there appears to be some related work in progress. Perhaps this is, or can be extended to be, sufficient to eventually make this kind of error a thing of the past.
  2. New binary package "steals" binary from another source. This is sometimes OK. Sometimes it's accidental. It could also be malicious (I don't remember if I've every actually seen this done for an intentional "steal" or not, I might have).
  3. New package added for reasons that make sense to the maintainer, but not for the archive as a whole. I've seen this come up multiple times, usually in the context of the binary being too trivial (which is a judgment call).

So FTPMaster is not only inspecting copyright information it is in fact helpful to check for technical issues in libraries that might have been renamed due to a SONAME bump. However, it was stressed several times that the copyright review is needed since there are countless examples that debian/copyright of new versions is not correct any more according to the rules FTPMaster team applies to new packages.

While a technical review (kind of a second pair of eyeballs) as Scott explained in his personal opinion is frequently helpful the issues mentioned there might be uncovered by automated tools later on in most cases. On the other hand reality has shown that this not up to date copyright information is true for packages inside Debian that do not need any new processing. In the light of this the strategy to do a licensing re-check of packages in new sounds quite arbitrarily. To do a consistent re-checking an archive wide licensing check would make more sense - may be a random pick from packages that were updated more than a (to be decided) number N from new upstream versions. Also an archive wide automatic scan was suggested.

In those cases where some license issue is detected for a package that exists inside Debian a rejection of the package is in many cases only the second best option since the issue most probably exists in the package that is available in the package inside the archive. Thus the combination of an accept in connection with a RC bug about the copyright issue seems to be the preferred curse of action for FTPMaster.

In some discussion on debian-devel mailing list there was a suggestion of de-coupling the copyright review (eventually of NEW entirely? but for now, just bin NEW) from "the other checks and balances". Ultimately, a mistake in debian/copyright can be just considered a bug with priority determined just like any other, so long as it is still legal for Debian to distribute.

Make packages in NEW available for apt

Another question that was raised is whether it is really necessary from a legal point of view to hide source and binary packages that are uploaded to new queue. For sure team members of a package in new can all setup their individual local mirror to develop against this package. However, it might seem more convenient to add the new queue as apt source. The original reasons for hiding packages in new are repeated in the thread but the question whether these reasons are valid today have not been answered yet.

There are a lot of arguments for making packages in NEW available via apt, these specifically are some convincing ones.

Processing sequence of packages in the new queue

Since we are all volunteers in Debian members of the FTPMaster team are free to pick packages from the NEW queue (= its not really a new queue but some kind of "ordered pool"). However, it would be great if the following packages would be preferable picks from that pool which could be fast-tracked:

  1. Packages fixing RC bugs (either in the package itself or its dependencies)
  2. Packages that might block a transition
  3. Rejected packages that were fixed

Hints about those packages are usually given on #debian-ftp.

Helpful hints by ftpmaster for package maintainers

Provide coded information

Since we are all technically competent, it would help package maintainers a lot to get hints in form of code instead of pure text information. This could be a grep statement which finds the the licensing / copyright of the files in the source package a bit more easily and might help the package maintainer to not only implement the code easily with their workflow, but also provide a useful example how to properly seek for licensing information in future packages.

Please CC WNPP bug

Developers are asked to file a WNPP bug for new packages. In case the developer was following this recommendation properly it would be great if communication between FTPMaster team member and package maintainer would be recorded here to have a full record of the status of packaging in this bug log.