Debian debates software for proprietary services
Back in February, Jonas Smedegaard filed a bug against the "certspotter" package, complaining that the package's description advertises the proprietary SSLMate service. On August 4, the maintainer of that package, Faidon Liambotis, got around to answering the bug, saying that the description is helpful for users searching for the package and will not be removed. At that point, Smedegaard took the discussion to the debian-project mailing list in an attempt to rally the Debian developer community against the offending package description.
The ensuing discussion, though, quickly got away from the question of the description and into the area of whether Debian should host software that interfaces with proprietary services in its "main" repository, or whether such software should be relegated to "contrib" instead. The answer to this question carries some consequences. If a package moves to contrib, any package that depends on it (or even recommends it) must also move to contrib. The contrib repository is not enabled by default in a new Debian installation, and packages in contrib do not normally get security updates. So a move to contrib signals a clear second-class-citizen status that would almost certainly result in a significant reduction in the number of users who even know that the package exists, much less use it.
We are talking about Debian here, so one can expect to find a written
policy addressing the issue. In this case, though, the policy manual is
mostly silent, with one exception. Section 2.2,
which describes the repository areas, says: "None of the packages in
the main archive area require software outside of that area to
function
". Some Debian developers interpret this sentence as saying
that the packages in main cannot link to proprietary software; others say
that use of a proprietary web service is enough to disqualify a package
from main.
If the latter view holds, there are quite a few ongoing policy violations in need of attention. The classic example, raised by a number of participants in the discussion, is the venerable ICQ messaging service. This service is proprietary, but a number of ICQ clients exist in the Debian main repository. In this case, the fact that the client itself is free software has generally been deemed good enough for inclusion in main.
If that is no longer the case, then a number of other packages need review as well. Vincent Bernat raised s3cmd, a tool for managing Amazon S3 services. But perhaps s3cmd is different because there are now a couple of free tools that emulate the S3 API. Another one, also pointed out by Bernat, is rclone, which specializes in synchronizing files between local systems and cloud-storage services, which are generally commercial. This tool is not just useful for ongoing use of those services; it can also be used as a means for escape from a cloud service — which is generally considered beneficial.
On August 9, Smedegaard carried the discussion to the debian-devel list, in the apparent hope of finding more support there. The result was perhaps less than he had hoped for. There were some developers, such as Bas Wijnen, who argued for expelling all such software from main:
Others disagreed, making the point that, if one looks closely enough, there
is little software indeed that doesn't require proprietary software — in
the CPU's microcode if not elsewhere — to function. Russ Allbery argued strongly against pushing out such
software, saying: "I believe this would be hugely counter-productive
for free software. It would hurt us way more than it would hurt
proprietary services
". He added
that "writing a library specifically to interact with a non-free
service is *good software engineering*
" and that such libraries
should be allowed in Debian. After that, the discussion slowed
considerably.
Once again, this is Debian, so the possibility of this disagreement
snowballing into a huge general-resolution fight is real. But a reading of
the discussion does not appear to reveal an appetite for that kind of
battle. A more likely outcome is that the issue will slowly fade from view
with no significant changes to existing practice. But, this being Debian,
one can probably predict with reasonable certainty that the topic will
return to the lists in the not-too-distant future.