qmail inclusion in official release of FC4?

Jeff Kinz jkinz at kinz.org
Fri Jan 7 23:57:23 UTC 2005


On Fri, Jan 07, 2005 at 04:29:20PM -0700, Aly Dharshi wrote:
> The more and more that I think about it I feel that it should be put in a repo 
.........

Addressing the general idea of putting any software which uses DJB's
license into a Linux distro:

No.  And - No no.

DJB's License is not an Open Source license, nor is it GPL nor is
it FOSS.

Quoting Rick Moen on the subject:
from: 
http://www.linuxmafia.com/~rick/faq/index.php?page=warez#djb
###################################################################################
      Prof. Bernstein's software is, first of all, pervaded by a
bloody-minded disregard for the rest of the world, e.g., qmail's trait
(in earlier versions) of attempting to cram as much SMTP mail as
possible down recipient systems' throats, which was notorious for
crashing destination mail systems (and thus pioneered the art of mail
delivery as a Denial of Service attack), and his publicfile and anonftpd
ftp servers' demented EPLF text output.

      Second, it is characterised by bizarrely wrong design, e.g.,
qmail's insistence that binary packages must install all files including
libraries, binaries, and configuration files within /var/qmail, and the
default alias database being scattered among myriad tiny text files
inside /var/qmail/aliases, all with names starting with the string
".qmail-". (Nope, DJB-acolytes, I do know all about fastforward. As
usual, you are missing the point, that one must hunt down and add this
as a modification and add-on to qmail proper.) This gaggle of tiny files
and their naming convention, alone, will drive any sysadmin to drink, in
short order. Now, it might be argued that lots of small alias files are
somehow more efficient than /etc/aliases, but why should all their names
start with ".qmail-"?

      But the clincher is his licensing. You will find that Bernstein
software typically contains a copyright statement but no licence text
whatsoever. Bernstein cannot possibly be unaware that this creates
problems for free / open-source software users, preventing them from
determining by inspection the nature of their right to use, modify, and
redistribute the code, as is generally the case. Fortunately, those
rights can be determined from statutory and case law -- here in the USA,
at least -- and Bernstein himself has actually created a Web page to
outline the provisions of USA Federal copyright law: Absent a licence,
if you have legally acquired a piece of software (e.g., by downloading
it from Bernstein's Web site), you are legally entitled to use, and
compile the software, and you may distribute patches to that software.
(Bernstein's further assertion that copyright law also entitles you to
modify code has been convincingly disputed by John Cowan.) But you have
no implied legal right to redistribute the software itself or works
derived from it. (Thus, if you become dependent on Bernstein software,
you run the risk that he might cease development and withdraw it from
the Net. Neither you nor anyone else would then have the legal right to
take over development and distribute even the old versions, let alone
new ones -- except in the form of source-code patches. And other legal
jurisdictions might give rise to different rights, or none at all.)

      (Yes, DJB-acolytes, I do know that Bernstein allows -- for now --
very limited verbatim or language-translated mirroring of some of his
"documents", but he makes clear on his "distributors" page that the term
refers to his HTML, not his software.)

      Exactly those conditions apply to every Bernstein package I know
of. Exception: Unmodified specific versions of qmail and djbdns/tinydns
(formerly dnscache) may be redistributed -- or at least so claimed
Bernstein's Web pages, recently. Will those continue to be there, to
point to? Remember, if he removes those pages, he says you may no longer
mirror or distribute them. Nor are you even allowed to modify
Bernstein's packages for redistribution even to the extent of appending
copies of those Web pages. Essentially, you're betting that Bernstein
never changes his mind, if you rely on such software. (Additional
exception: A couple of Bernstein's smallest projects, e.g., CDB =
Constant DataBase and libtai, have had looser licensing, but not
lately.)

      I suppose you could stash away private copies of the current
contents of these packages' "permission" pages that you're permitted
neither to mirror/distribute nor add to the tarballs, documenting their
terms and your compliance, but really -- is this any way to run a
railroad?

      They are thus definitively proprietary software -- with limited
rights of gratis use if you acquire the package from Bernstein or
someone he's specifically authorised to distribute it. Therefore, if you
repair his bizarre design decisions, you may not share your work (except
as patches, add-ons, or reconfiguration recommendations), and must re-do
that repair work with each new version. You also may not put up even
unmodified versions for public access (of many of his packages) without
special permission. Further, if you attempt to discuss patches he
doesn't approve of on his mailing lists, Bernstein has been known to
threaten to kick you out.

      (Please note that Bernstein has expressed to me in e-mail his view
that this FAQ item contains "libel" and is "against the law". I referred
him to my attorney, and Bernstein has thus far not pursued the matter
further.)

      Prof. Bernstein personally deserves lasting gratitude and praise
for the truly heroic role he played in protecting computer users' and
programmers' rights in the EFF's Bernstein v. US Department of Justice
lawsuit, and his software is beyond doubt of uniformly high coding
quality and careful (if eccentric) design. However, I see no reason to
put up with the other baggage his software comes with (detailed above).
Life is too short to deal with Bernstein-isms, and there are always
other decent software choices: Instead of qmail and ezmlm, use Postfix
(or Exim) and Mailman. Instead of publicfile's (or anonftpd's) ftp
server functions, use Marcus Ranum's aftpd (if you're on *BSD), Shane
Kerr's oftpd, Peter Eriksson's pftpd, iMatix Corporation's Xitami,
Andrew Kuchling's medusa, Frank Denis's Pure-FTPd, Matthew William
Lefkowitz's Twisted, or Chris Evans's vs-ftpd. (I also maintain a list
of all known ftp servers for Linux and other Unixes.)

      If you need an http (Web) server, in place of publicfile you
should consider Jef Poskanzer's thttpd / micro-httpd / mini-httpd
series, Thomas M. Ogrisegg's Cthulhu, Alex Belits's fhttpd, Ingo
Molnar's TUX = Threaded linUX web server (a kernel-based static-page
accelerator, now being promoted by its author's employer as "Red Hat
Content Accelerator"), or Zach Brown's phhttpd/ matofali or the similar
proprietary offering Zeus Web Server, Matthew William Lefkowitz's
Twisted, Caudium WebServer, iMatix Corporation's proprietary Xitami,
Andrew Kuchling's medusa, Felix von Leitner's fnord (requires the
proprietary tcpserver daemon), Richard R.W. Jones's rws, Doug Neal's
DNHTTPD, Gerd Knorr's webfs, Matthew R. Green's bozohttpd, Marc Pompl's
ghttpd, Muhammad A. Muquit's MHTTPD, Greg Olszewski's chttpd, Doug
Hoyte's Anti-Web httpd, Paul Vlaar's neepHttpd, Sven Berkvens's
xs-httpd, Peter Eriksson's Phttpd, Fabian Wauthier's navajo, David A.
Bartold's dhttpd, Larry Doolittle, Jon Nelson, and Paul Philips's Boa,
Yann Ramin's ATPhttpd, Nikos Mavroyanopoulos's Hydra, GoAhead Software,
Inc's GoAhead WebServer, Vincent Negrier's Nanoweb, Mark Grosberg's
Seminole, Vlajko's BaukHTTPD, Jonas Reese and Torsten Köster's JServer,
Eduardo Silva's Monkey HTTP Daemon, Anders Karlsson's PS-HTTPD, the
Pegasi LUG's Pegasi Web Server, Matthew Parry's sedhttpd, Neil Conway's
Tornado HTTP Server, Claes Wikstrom's Yaws, John Franks's WN, or Michiel
Boland's Mathopd.

      Instead of Bernstein's ucspi-tcp and daemontools, use the much
more conventional inetd / tcpwrappers combination, or xinetd.

      Instead of djbdns/tinydns (Bernstein's DNS nameserver suite): Many
of us are migrating to Paul Vixie's (the Internet Software Consortium's)
newer, written-from-scratch BIND v. 9 codebase, because the old,
traditional BIND v. 8 package is too crufty and security-bug-filled (and
has therefore been abandoned). Johannes Erdfelt's dents server remains
promising, but development appears to be stalled. Suitable alternatives
for some deployments include Thomas Moestl's permanent-caching server
pdnsd, Sam Trenholme's MaraDNS, Michael Wolf's moodns, Don Moore's
MyDNS, Alexis Yushin / Stichting NLnet Labs's NSD, Brad Garcia's DNRD -
Domain Name Relay Daemon, Meilof Veeningen and Jama Poulsen's Posadis,
Hubert Tonneau's Pliant, Salvatore Sanfilippo's Yaku-NS (formerly ENS),
Eric Kidd's CustomDNS (formerly LiveDNS), Simon Kelley's Dnsmasq, Mrs.
Brisby's ldapdns, Creighton Macdonnell and Mike Machado's GnuDIP, Roland
Schemer and Rob Riepel's lbnamed, Eddieware's Eddie Enhanced DNS Server
(formerly lbdns), and PowerDNS.com BV's PowerDNS. (Consider running your
choice of name-server software chrooted, especially if still using BIND
v. 8.)

      djbdns should not be assumed automatically to be an
all-around-usage DNS server, either. Some of the areas in which
Bernstein has elected not to follow IETF draft standards in djbdns's
functioning are outlined in Scott Morizot's letter to Linux Weekly News
(seventh letter down). (Note that there are third-party ways to fix
djbdns to add support for the IETF NOTIFY protocol, for sending and
receiving NOTIFYs, but the point is Bernstein decided not to implement
that and many other core DNS protocols: He recommends, for example, that
you eschew the standards-track NOTIFY and IXFR protocols, and use rsync
instead.) A comprehensive list of IETF DNS protocols omitted from djbdns
can be found in Paul Vixie's linuxsecurity.com interview.

      It can be argued that the omitted DNS protocols are merely
standards-track (proposed) IETF protocols as of Nov. 2001 -- whose
adoption Bernstein opposes on various grounds. (Relevant RFCs are 1995,
1996, 2136, 2535, 2536, 2537, 2538, 2539, 2845, 2930, 2931, 3007, 3008,
3090, and 3110.) But shunning common zone-transfer mechanisms (NOTIFY,
IXFR, outgoing AXFR) is just unreasonable if you want to want to
interoperate with the rest of the world.

    * Are you saying that DJB can revoke the licence to his software by
changing or removing his Web pages?

      No, of course not. The prior essay nowhere states or implies that,
nor does anything else I've said, Prof. Bernstein's assertions
notwithstanding.

      The fact that the tarballs of qmail and djbdns/tinydns for which
Bernstein permits redistribution may not include copies of his generous
(if proprietary) licence terms, together with his restrictions on
mirroring of those licence terms, make it very awkward to independently
and lastingly document his licence terms and your compliance with them.
Not entirely impossible, just very, very awkward -- one of the many
hassles with Bernstein software that, in my view, make it not worth the
trouble. That and absence of any right to fork (which means the projects
effectively cease when/if Bernstein loses interest or dies) were, as I
thought entirely obvious, what I meant in saying "Essentially, you're
betting that Bernstein never changes his mind, if you rely on such
software", especially in conjunction with the remainder of the
accompanying licence analysis.

      The covered software itself may -- by those licence terms, be
redistributed, in unmodified form, to anyone. In perpetuity.

      Some of the other hassles inherent in Bernstein's software are
eloquently listed by my friend J. Paul Reed in a user group post (though
his point "c" about licensing was in error on points detailed above,
concerning which I publicly corrected Reed's erroneous claim (on that
mailing list as well as here), and also in private mail.

      Unfortunately, the prior essay continues to be misrepresented by
Prof. Bernstein's roving fanclub around the Internet, leading to my
making further comments refocussing their attention on what I actually
said and their failure to address it.

Last modified: 2004-11-17
rick at linuxmafia.com

Copyright (C) 1995-2004 by Rick Moen. Verbatim copying, distribution,
and display of this entire article are permitted in any medium, provided
this notice is preserved. Alternatively, you may create derivative works
of any sort for any purpose, provided your versions contain no
attribution to me, and that you assert your own authorship (and not
mine) in every practical medium.u


> such as that of Dag or ATrpms. I think that there are better modern smtp servers 
> out there that do a lot more stuff than Qmail and prolly more efficiently with 
> things built in, Exim comes to mind for one. Exiscan patch is being integrated 
> into main stream Exim so it should be ninja cool.
> 
> Rahul Sundaram wrote:
> > On Fri, 07 Jan 2005 15:41:03 -0700, Aly Dharshi <aly.dharshi at telus.net> wrote:
> > 
> >>Qmail has been fairly stationary in its development. I wonder if these shouldn't
> >>just be part of a repo as opposed to be included in a FC3/4. I am sure that I
> >>could be wrong about this but this is my take on it.
> > 
> > 
> > the last release was in 1998. 
> > 
> > the thing wouldnt build on any modern system and be usable without an
> > assortment of patches from qmail.org.
> > 
> > rpms with these patches wouldnt be possible since binary
> > redistribution with modifications are not allowed under the qmail
> > license.
> > 
> > someone could create a good spec file if they wanted to i guess
> > 
> 
> -- 
> Aly Dharshi
> aly.dharshi at telus.net
> 
> 	 "A good speech is like a good dress
> 	  that's short enough to be interesting
> 	  and long enough to cover the subject"
> 
> -- 
> fedora-list mailing list
> fedora-list at redhat.com
> To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
> 

-- 
Linux/Open Source:  Your infrastructure belongs to you, free, forever.
Idealism:  "Realism applied over a longer time period"
http://www.scaled.com/projects/tierone/
http://kinz.org
http://www.fedoratracker.org http://www.fedorafaq.org
http://www.fedoranews.org
Jeff Kinz, Emergent Research, Hudson, MA.
~
~
~
~




More information about the fedora-list mailing list