The most recent version of these essays can be found at http://linuxmafia.com/~rick/faq/.

Rick's Rants

("That's what you get for swimming in the shallow end of the gene pool.")

-Virus-    -Linux Tire-Kicking-    -Proprietary Warez-    -Hardware-    -Netiquette-    -Crybaby-    -Modems-    -MacLinux-    -Miscellany-   

Economy of expression is a good thing. So, rather than have to repeat myself continually, I'm posting my top rants here, for ready reference. Many of you (readers) will be visiting today because I pointedly referred you to the "#"-tagged URL of some particular item, below.

Proprietary Warez Department

• What's wrong with Pine?

  Pine is dead. Long live Alpine.

  Longtime Pine users, wake up: Your favourite MUA is unmaintained. A from-scratch replacement, that for once is genuine open source aka free software, took its place. The rest of this entry is for history's sake.

  University of Washington's "Pine" mail reader (with the associated "Pico" text editor and "Pilot" file-picker) always had fans: it was solidly constructed, easy to understand, and familiar to many long-time Unix users. It was, however, somewhat slow, not very extensible, and spottily maintained. The latter probably resulted directly from my main objection: UofW took it proprietary starting 1996, after which it languished, fell behind, and was abandoned. Coincidence? You be the judge.

  Through version 3.91, Pine's licence stated the following: "Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee to the University of Washington is hereby granted...." Starting v. 3.92 (1996), Pine changed to a more-restrictive licence. Since that change, UofW has alleged, retroactively, that even the old licence never allowed distribution of modified versions. In other words, they say you may distribute the software, and may modify it, but may not modify it and then distribute the result. (UofW threatened to sue the Free Software Foundation for distributing modified Pine ("MANA"). This is not a trivial matter, but rather a key right.

  Apparently, UofW feel interpreting the word "and" in their phrase "modify and distribute" as an ordinary conjunction is, per their Web site, a "perversion" of their original licensing intent. Sounds to me like an intellectually dishonest rationale for legalistic thuggery — and a brazen bluff, at that — but what do I know?

  For nine+ years, Pine users basically, well, lost. Other MUAs took Pine's mindshare. Several clones got started; none caught on:

  • MANA (Mail And News Agent) was a Pine 3.91 fork. UofW brandished legal sabres; MANA was dropped.
  • Supposedly Jean-Paul Chirac, ex-Cobalt Networks guy, started writing a clone in elisp, but I never found it.
  • Hydrant was going to be a clone built from GNU Mailutils; it died young.
  • oserp (OpenSource Emailer Replaces Pine) was a similar idea in Perl; it didn't happen.
  • Cone (COnsole Newsreader And Emailer) actually works but never caught on.
  • nano perfectly emulates Pico and has been quite successful: Just symlink /usr/local/bin/pico to it, and pico users are delighted.
  • A wrapper script named "pine" that runs "/usr/bin/mutt -F /usr/doc/mutt/examples/Pine.rc" was one way to give Pine users half a loaf; it makes the (vastly superior) "Mutt" reader respond to Pine key commands -- but sadly without Pine's menus, newsgroup functions, or Pilot.

  In late 2005, UofW finally gracefully bowed to public opinion: Although the Pine mailer itself will not be [re-]open-sourced, and was discontinued, UofW released a modern, from-scratch Pine reimplementation under Apache Public License v. 2.0: Alpine (Apache-Licensed Pine). It is far and away the best option for Pine fanciers.

• Daniel J. Bernstein's qmail / ezmlm / djbdns / tinydns / publicfile / ucspi-tcp / daemontools / etc. package is the best of its kind, and is free / open-source software.

  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 other coding quirks summarised nicely by Timo Sirainen and Matthias Andree), 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 [2007 update: was (see below)] 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.)

  2009-08-21 update: in late 2007, Dan asserted qmail 1.03, after nine years of no maintenance, to be public domain software, and likewise (over time) some other packages: djbdns 1.05, ezmlm 0.53, daemontools 0.76, djbfft 0.76, dot-forward 0.71, fastforward 0.51, libtai 0.60, primegen 0.97, ucspi-tcp 0.88, and cdb 0.75. (qmailanalog, checkpassword, clockspeed, focus, ftpparse, hash127, mess822, nistp224, Psibound, publicfile, serialmail, sigs, smallfactors, sortedsums, threecubes, Zmodexp, and Zmult remain proprietary.)

  (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 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 the former hasn't 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 [2007 update: were] 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.

  Starting 2004, a group of talented qmail developers have released netqmail — Bernstein's 1998 qmail v. 1.03 source code release (effectively abandonware, after these many years) with a huge omnibus patch and build system: It was an impressive achievement, but underlined the licensing-based limitations: Neither they nor anyone else may fork the codebase in any regular, reasonable way, nor ever lawfully distribute any sort of binary. (Update: This changed with the Nov. 30, 2007 public domain declaration, and further netqmail development has now commenced. It's a pity Dan has saddled those developers with the inherently ambiguous legal status of such declarations, when a simple "Copyright (C) 2007 Daniel J. Bernstein. Do whatever you want with this work" would have achieved Dan's objective without those drawbacks.)

  (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), Frank Denis's Pure-FTPd, 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 Jan Kneschke's Lighttpd, Jef Poskanzer's thttpd, Ingo Molnar's TUX = Threaded linUX web server (a kernel-based static-page accelerator, similar to the proprietary Zeus Web Server), Caudium WebServer, Andrew Kuchling's medusa, Maxim Dounin's freenginx, Felix von Leitner's fnord (requires the tcpserver daemon), Neale Pickett's Eris, Doug Neal's DNHTTPD, Gerd Knorr's webfs, Matthew R. Green's bozohttpd, Muhammad A. Muquit's MHTTPD, Sven Berkvens's xs-httpd, Larry Doolittle / Jon Nelson / Paul Philips's Boa, Nikos Mavroyanopoulos's Hydra, Vincent Negrier's Nanoweb, Vlajko's Bauk HTTP server, Eduardo Silva's Monkey HTTP Daemon, Claes Wikstrom's Yaws, or Michiel Boland's Mathopd.

  Instead of Bernstein's ucspi-tcp and daemontools, use the much more conventional supervisord, monit, perp, runit, finit, minit, restartd, s6, or maybe even very-old-school inetd / tcpwrappers combination, or xinetd.

  Instead of djbdns (Bernstein's DNS nameserver suite): Many of us long ago migrated to Paul Vixie's (the Internet Software Consortium's) newer, written-from-scratch BIND9 codebase. Suitable alternatives for some deployments include Paul A. Rombouts and Thomas Moestl's permanent-caching server pdnsd, Sam Trenholme's MaraDNS, Alexis Yushin / Stichting NLnet Labs's NSD and Unbound, Simon Kelley's Dnsmasq, Mrs. Brisby's ldapdns, and PowerDNS.com BV's PowerDNS. I maintain a list of all known DNS daemons for Linux and other Unixes.

  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, to respect RFC2038 "NCACHE" negative TTLs, etc., 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 list of most (not all) IETF DNS protocols omitted from stock djbdns can be found in Paul Vixie's linuxsecurity.com interview.

  It is sometimes 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, 2307, 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. Moreover, the excuse that standards-track RFCs are merely "proposals" is transparent nonsense: See reasons why.

• 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.

  Once again, what I said was:

  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.

  My point? Leaving aside the fact that Prof. Bernstein's ad-hominem-laced swipe completely ignores the substance of my licence critique, and diverts readers onto a side-issue, it also rather flagrantly misrepresents what I said on that side issue. However, in case anyone actually was mislead by the cited text, I'll elaborate:

  The fact that the tarballs of qmail and djbdns for which Bernstein permits redistribution may not include copies of his generous (if proprietary [2007 update: no longer 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: 2024-10-10

rick@linuxmafia.com

Copyright (C) 1995-2024 by Rick Moen. Verbatim copying, distribution, and display of this entire article (page) 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.

---

Top of page