Bug#158533: project: qmail is installed on murphy
> Package: project
> Version: N/A; reported 2002-08-27
> Severity: serious
> Justification: violates Social Contract 1, 4, and 5 (maybe others)
On Tue, Aug 27, 2002 at 08:00:10PM +0000, Brian M. Carlson wrote:
> The subject says it all. qmail is installed on murphy.debian.org. qmail
> is non-free. Debian should not be using non-free software on its own
> systems. I will quote from the Social Contract to show why this is so.
 The social contract is about our distribution, not about support
machines such as murphy.
 qmail is always redistributed at no or very-low cost and almost
always in source form. Source can be retained indefinitely, and can be
 qmail is the best option available -- no one has cared enough to
write a free replacement that provides qmail's security, performance,
stability and features.
> "Debian Will Remain 100% Free Software" is very clear, I think. "[W]e
> will never make the system depend on an item of non-free software." Your
> systems are depending on items of non-free software. The default
> mail-transport-agent for installation is exim, and that is what most
> other machines run, but not murphy.
Would you have us stop using routers, parent dns nodes, etc. because those
would make our system depend on non-free software? If so, and you're not
a hypocrite, I suggest you start tackling the more egregarious violations.
In any event, I think the severity of this bug should be dropped to
I agree that we treat this is something we want to correct if and when
we can, but it's not the kind of bug you're representing it to be.
* * * * *
Personally, I'm considering proposing a constitutional amendment which
provides specific exceptions to clauses 3 and 4 of the DFSG, and related
guidelines (such as FHS) for Dan Bernstein's software. We've not been
able to adequately answer Dan's objections about why these standards
need to apply to his software, and maybe proposing an amendment will
kick up the issue enough to get it addressed properly.
Also, Dan is competent enough, and is doing enough for the free
software community, that I'd be willing to grant him the same sort
of jurisdictional control over his packages as we grant to any debian
developer -- I think his points about how we manage our system are good
enough that it's worth at least considering modifying Debian to fit Dan.
Either that, or I'm going to get off my duff and write a work-alike
replacement for those packages he's written which I consistently find
useful. But every time I sit down to do this, or to release a binary
package which satisfies Dan's criteria, I start running into the very
issues which Dan raised when we've asked him to relicense his software.
[Note: I'm not going to do any of the above until after I can set myself
up a machine which I trust to run gpg. And maybe not even then.]