Re: posible bug in daemontools

> How else would you suggest I state the copyright status and
> redistribution terms?

 Do what you want: it's your software. But I'd advise to KISS, even for
the non-technical parts. Just have a LICENSE file or something, that
states factually, coldly, the copyright status and redistribution terms,
in words a nosy lawyer couldn't find anything to mumble about.


> How, exactly, have I been disrespectful?

 Disrespectful is a strong word. But the message I sent on the list
when you started happily patching djbdns could be a starting point
for what I think Chris means.

 Let me repeat what I already said: djbware is not only good code,
it's also a different way of designing software, a kind of comprehensive,
coherent (and, to me, Right) approach to Unix.
 I'll even go as far as to say that DJB's code is not essential. From
a C-nazi viewpoint, several people here have written better code than
DJB has. What is essential, though, is the thought process that leads
to creation of such code. *Why* does DJB design things the way he does,
which often seems unbelievably quirky, borderline alien, and sometimes
even outright demented, to people who are used to mainstream Unix
software?

 You're interested enough in djbdns to maintain software that is based
on it; I'm going to assume it's because you found that djbdns worked
and you liked the code at least a bit. And you began addressing what
you perceived as flaws by patching it.
 *But* I firmly believe that what makes djbdns' quality is not the
codebase, it's the philosophy behind it. You want flaws in the djbdns
codebase, I'll give you flaws (for instance, why use a global structure
to pass information in dns_resolve()? bleh.) However, what you perceive
as flaws in the design probably aren't, they're likely a part of the
philosophy.

 Your autoconfifying zinq-djbdns shows that you didn't try to understand
why DJB chose to not use autoconf. (Or you tried and disagreed, which
is another thing, but if you're interested in quality code, I can't see
how you could disagree. XD)
 Now you're saying "I'm not a fan of slashpackage". Well, fine.
slashpackage is quirky and unusual, and very unlikely to be adopted by
mainstream Unix vendors. But it's not a gratuitous idiosyncrasy, either.
Forget about "standards" for a while, and think about technical benefits.
Really, slashpackage does have benefits: cross-platform portability is
HUGE. And that's something the FHS does not offer - the FHS offers other
guarantees, which are also good (it's useful when you have several
disk partitions, for instance), but not the be-all end-all of filesystem
organization. Both approaches aren't even incompatible: you can have a
slashpackage symlink forrest on top of a physical FHS hierarchy.
 So, *why* don't you like slashpackage? Because it's not "standard"?
Sure, but existing standards fail to address a problem that slashpackage
does address. Part of the DJB philosophy is: if the existing standards
don't meet your technical requirements, don't follow them. Do not settle
for mediocrity, but design the APIs you need, for a technically better
product. And that very philosophy gave you dns_tranmit_start() over
gethostbyname().

 Now do you understand how going ahead and forking djbware (and I
mean *distributing* software, I don't care what people do at home, of
course) without the utmost prudence can be seen as disrespectful?

-- 
 Laurent