Presumably there's nothing stopping anyone truly committed to GPL'ing
qmail from buying the copyright to it from Dan...other than Dan
setting too high a price. (No, I'm not planning to do this myself,
just pointing out that it is, presumably, possible.)
Having developed GPL'ed software myself, despite being generally
close to feeling that's the best way, I can see much validity to
Dan's reasons for protecting qmail as he does, given the nature
of that particular product.
I'm not sure I'd come to the same decision myself, though, since
I'd probably be in much more need of cooperative, "bazaar-style"
development to produce something like qmail than was Dan. But if
I did develop a product whose architecture, design, and implementation
I considered to be of a nature that permitted little outside
interference, and I believed it was the kind of product that would
appear to *invite* such interference from others, I might consider
using Dan's approach to ensure that, while it is somewhat free, it
isn't so free that people could corrupt it via changes that made
it seem "better" and thus were highly popular, but were, in fact,
wrong-headed. GPL'ing it later wouldn't be out of the question --
I might do it after the product had demonstrated a history of meeting
real needs effectively without being corrupted by others, so that,
after such corruption, it would be more clear where the problems
began (and therefore what caused them).
I do think, though, that some of these problems of corruption stem
from our not having a popular language in which to express certain
types of specification, and therefore no easy way to write, share,
and have automated tools check against top-level specifications for
components. E.g. just as "int foo(int, int);" is, in its own primitive
way, a top-level specification that distinctly disallows some hacker
adding "foo (0);" to some code as well as changing the definition of
foo to "float foo(float x, float y) {...}" without having to also
change the top-level specification -- an action that can be seen more
clearly as changing a public interface than the other two types of
change -- it would be helpful to have a common language in which we
could express requirements about timing, security, and so on. (I don't
mean an imperative language, of course; more of a specification language.)
With such a language in common use and widely appreciated, I think
some of the problems I, at least, worry about (and see happen) in
bazaar-style development (Linux, GCC, etc.) would be significantly
reduced, or at least eliminated. Heck, lots of email discussions
(and confusion over terminology that often occurs in them) would be
replaced by code containing, or even patches to, what I'm thinking
of as top-level specifications.
At that point -- when an author (designer) of a program can fairly
easily encapsulate critical specifications in a form that can be
automatically checked against the corresponding implementations --
there might be less resistance to letting random people participate
in improving certain types of products (e.g. OSS development of mission-
critical systems like mail transport agents). That is,
the author can more easily spot changes to the specifications
themselves, and the automated checking can help catch changes to
the implementations that violate the specifications. (Ideally,
automatic generation of implementation from specifications could
someday occur, but first things first.)
tq vm, (burley)
